Ironically your website doesn't meet the first criterion of the WAI design tips you linked (the nav links): https://www.w3.org/WAI/tips/designing/#provide-sufficient-co...

But I otherwise agree, you both could do with some work in that regard (as could the projects i am working on, no doubt).

What does my website which I updated 6 years ago (and created more than a decade ago) have anything to do with the validity of my comment? Trying to poison the well?

I do it from a position of support, which I had the chance of developing by observing the users of the apps I created, and I made a giant software suit (more than 1000 views) pass an accessibility audit in my current company.

This is not just a charting library, see the examples down the page. Also, see: https://www.highcharts.com/blog/tutorials/best-chart-accessi...

> If we are going to go this way: You previously commented that something doesn't work on Firefox, do all your project superior browser support?

It was in a thread specifically discussing browser support for the guys project where he stated he only has the ability to test on chrome/firefox on fedora: https://news.ycombinator.com/item?id=35448674

> a criteria that was set way later than I built that site

That criterion has been there since 1999.

> Also, see: https://www.highcharts.com/blog/tutorials/best-chart-accessi...

It is highcharts that I use extensively, and I completely disagree that a11y is a solved problem there. Ironically on the referenced page they make the same mistake as you regarding color shades.

I can do this all day. Stop being so hostile.

> That criterion has been there since 1999.

Apparently 2001. But well, I'm learning and improving am I not? I was a worse web developer a decade ago than I am now, and I am proud of that.

> Stop being so hostile.

You are the one who analyzed my personal website and reported a single color contrast issue to dismiss my complaint, why am I hostile? Regardless of that discussion, isn't my point coming across: Do we need to be authority on issues we report?

I tried to help, linked some resources, why is that wrong? I feel rather you being hostile.

> Ironically on the referenced page they make the same mistake as you regarding color shades.

Okay now you get to criticize open source libraries?

Anyway, few years ago I created an SVG based charting library for internal use, and we did (and still have) users with sight impairments, and yes it is hard to make it right. NVDA is a pain to bring under control, at least :) And a colleague of mine said something I really like: You cannot make software completely accessible, even for a perfectly capable person with above-human IQ, no, but you can make it always more accessible. It's great that they are trying!

> I can do this all day

What you are doing is something I sincerely don't understand.

>> That criterion has been there since 1999.

> Apparently 2001

Nope, May 1999: https://www.w3.org/standards/history/WAI-WEBCONTENT

> I do apologize

No problem.

> No problem.

So apparently I didn't have to second-guess myself :)

> Nope, May 1999

That's not what you think it is: https://www.w3.org/TR/1999/WAI-WEBCONTENT-19990324/wai-pagea...

The one which the previous version of my site failed to validate is apparently published in 2008: https://www.w3.org/standards/history/WCAG20 and when I wrote those styles back in who knows when [edit: found it, 2014 https://web.archive.org/web/20141219164444/https://egeozcan.... ], I wasn't aware of it. I first said 2001 because I looked at the first draft.

> That's not what you think it is:

Its exactly what I think it is: "Ensure that foreground and background color combinations provide sufficient contrast" (with reference to lighthouse.org for specifics about contrast).

They didn't specifically define that ratio in the doc until WCAG 2, but thats irrelevant really.

> They didn't specifically define "sufficient" until WCAG 2, but thats irrelevant really.

It is relevant. I didn't have any means to test it, and that's what I saw as sufficient back then. You never admit you were wrong, I assume?

edit: you edited your comment, so here is the lighthouse.org page: https://web.archive.org/web/20080211110529/http://www.lighth... There was no ratio, so it's just my gut feeling which WCAG 2 had apparently decided was not enough and I didn't know it back then - not that there were enough tooling.

They explain how to test it on the WCAG link you gave. I never said they mentioned a ratio on the lighthouse page. Pretty sure i have not been wrong about anything in this discussion so far... Shall we continue?

Oh you were (like your very last points even), you just keep changing focus. But I'll let it be because I have no more time for these. good luck with your further discussions :)

My focus has solely been on the contrast aspect, as per my original post. But at least we have cleared up your misunderstandings, so I guess we can leave it there. Have a good day!

Perhaps you need to re-read, it was never just the contrast, see my first reply to you, and try to understand my point, which you yourself proved later.

You were right from the start, I had created a site 9 years ago that gets only 65 points in an accessibility check today! So I can't suggest anyone to focus on accessibility?!

You too have a nice day!

It's an open source project. You could create an issue on their GitHub repo, or better yet, create a PR and reference this existing issue:

https://github.com/finos/perspective/issues/2133

I just commented about something I found lacking, it's not a hostile comment, and suggested improvements to the authors who seem to be hanging out here. I think if they have interest, they can add these as an issue, or not.

Menu aside, what is a a screen reader supposed to do with a table changing at 100 msg/s?

auctioneer voice plugin

What are your eyes going to do with such a table? People pause right? So it would be nice to have some help to navigate. aria-sort in that example would help a lot, also some menus usable with a keyboard, and not disabling outlines.

Not sure what specifically you are looking at - the data grid element e.g. is a well-formed, native HTML `<table>`, as recommended by the w3 [1] and renders fine AFAICT with the screen readers in Safari and Chrome (the browsers I have installed).

A specific report on the GitHub for issues you find would be much appreciated!

[1](https://www.w3.org/WAI/ARIA/apg/patterns/table/examples/tabl...)

I was looking at the datagrid. I can't use the menus with the keyboard. I can't select columns. I can't see the currently focused element. My screen reader does not inform me of the menus, nor can I interact with them. Inputs have outline: none. Labels are not connected to the inputs.

In this example: https://perspective.finos.org/block/?example=superstore

I can't use the tree with the keyboard. From the patterns page I linked, you can see an implementation example for an accessible tree element.

I mean, I can continue. I'm not saying this to devalue your work, and I wish I had the time to go in depth and analyze all the components and give you more feedback, but I don't. So I humbly suggest you do a bit research about the topic and improve the product some.

Perhaps my original comment sounded too dismissive and therefore got many negative feedback, but I'm sincerely concerned. I wanted to hint at this as this is a tool that may be used by businesses and some people cannot do their job because of inaccessible tooling.

I do like what you are doing and the components do look cool - nothing to take away from that. Please take my comment as constructive as you can take it to be because I was trying to go for that, and perhaps my frustration in the last few years with this topic made me also whine a little bit :)

Like I said - GitHub is the preferred method of reporting issues:

* Some of these (keyboard nav, focus) we test for and sounds like a specific issue with your browser/OS setup, which we'd very much like to fix. GitHub Issues allow us to ask these followup context questions.

* Some of these are vague, I'm not aware of any label+input in the component, e.g., nor how column selection is related to accessibility. The venue for this discovery is GitHub Issues - just because they are obvious to you does not make them obvious to us such that RTFM is a suitable correction, humbly or otherwise.

The project has relatively wide financial industry usage (and some of the code was originally developed at JPMC), and we're very interested in fixing real issues!

Well, I'm sorry, I can only help so much. I also try to open source many things as I can, and I'm active on Github in many projects but I have only so much time.

> Some of these (keyboard nav, focus) we test for and sounds like a specific issue with your browser/OS setup

It's probably not (tried on another computer and browser). Please open this page: https://perspective.finos.org/blocks/superstore/index.html Try to navigate with your keyboard. There are no outlines and the tree view is not possible to interact with.

> I'm not aware of any label+input in the component

The top and right toolbars here: https://perspective.finos.org/blocks/editable/index.html Are the not the part of the component? Perhaps I'm mistaken to think so. My apologies if they aren't.

> how column selection is related to accessibility

https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

The column headers aren't possible to interact with a keyboard anyway, and the screen reader doesn't announce anything to indicate that the table can be sorted.

In my current job, we paid a lot of money for an army of auditors to hunt these down for us, and I don't expect that you do something like that for an open-source product, but if you have corporate use (I mean if people are paying for this directly or indirectly, and I hope they do!), maybe it makes sense to go for one?