Hacker News Reader

Comment by wittjeff | Hacker News Reader

Accessibility is a strong gating factor for some (including me). I don't see it in the docs. The whole thing seems to be missing any ARIA (see https://www.w3.org/TR/wai-aria-practices/examples/grid/dataG...) Let me know if you want help.

View on HN

Thanks for your feedback. It's true, I have not made any real efforts when it comes to accessibility (apart from choosing DOM over Canvas). I would very much like to make DataGridXL as accessible as I can, but right now it is not a priority. Thank you very much for sharing the link, that looks really helpful. Are you experienced in making data grids accessible?

I've done a lot of work on data grid accessibility. In fact, DataGridXL is one of the many grids I considered for our own needs a couple years ago. The reality here is unless you somehow export out a DOM structure which has an element per cell, for at least the cells that are on screen, you will never be able to get the screen reader to behave correctly. If you were using a canvas you could export a subdom on the canvas, but with the approach y'all take with the line-height + dom node per column I don't see how you get there.

The cell nodes need be browsable and selectable by the screen readers caret. You could do what many other DOM based grids do and add an "accessibility mode" but I believe accessibility should be the default and not a mode people turn on as a checkbox. Let me know if you want to chat, I'm always happy to share what I know. I'm by no means an expert but I've definitely picked up a thing or two.

Seems pretty much impossible to not have an accessibility mode yet have features such as fixed columns/rows. It would be very difficult to have a clean DOM structure while supporting that layout. If it is possible I'd be very interested in how that is done.

It can be done if you are using a Canvas to provide the rendering. The canvas can then be provided with a subdom that does not render but is visible/interactive to screen readers which matches exactly what the screen reader requires. Canvas's actually have the advantage here if they put the effort into being accessible.

You could do the same trick by hiding the visible DOM from the screen reader and creating an invisible DOM explicitly for the screen reader. If your DOM structure is wrong for the screen reader I would suggest doing this.

This is amazingly nice it works for mobile and that is great

Ah thanks, we'll be improving touch controls soon (adding a mobile contrxt menu)

Do you happen to know of best practices for simulating different disabilities, or some recording of somebody actually using some example well-designed accessible software? A video recording, to me as somebody who can see and hear and move just fine (for now), would help me understand what interaction methods don't work or are a struggle, which interaction methods are intuitive and effective, and which types of content are not recognized, not presented, or not important.

Lighthouse [1][2] Accessibility audit/ scores can be a good tool to check A11Y issues automatically, and it is fairly easy to integrate into your CI/CD Pipelines to get the report automatically to check for issues/ regression.

The web accessibility world is complex enough that simulating different methods of access like using screen readers or different font-sizes and doing manual tests for compliance is not particularly feasible if you want to make your content accessible to all.

[1] https://developers.google.com/web/tools/lighthouse [2] https://web.dev/accessibility-scoring/

I disagree. Automated results are not perfect and miss a lot of nuances, like element ordering, tab indexing, etc. Assuming you can’t find someone experienced with a screen reader to test I would invest in learning how to use one yourself. I’ve spent days without access to my screen in order to grow more comfortable navigating with audio. Of course, I won’t be as helpful or quick as someone who’s used a screen reader for years, but it’s better than blindly trusting lighthouse/web.dev

> but it’s better than blindly trusting lighthouse/web.dev

Interesting use of "blindly". Using lighthouse or other accessibility checkers is better than not considering accessibility at all, and has a much lower barrier for developers and development orgs than integrating screen readers into the development lifecycle.

I was in an org where our QA team actually used our sites with screen readers, and yet we still ran automated accessibility tests on our codebase. This is because we can catch issues earlier and more easily, and reduce the amount of issues making it to manual QA which is much more time consuming and expensive.

Manual QA testers using screenreaders are also not perfect and miss a lot of nuances :)

Some time ago I helped building https://ds.gpii.net which actually features a lot of ressources for developers regarding accessibility. It has a component search that links most of the automated testing tools ( scraped and curated from GitHub. ). I think actually videos of assistive tech use would have been a nice addition, but there is already a lot of so called quicksheets to get you started. One USP we wanted to have is a community of testers [1] unfortunately it did not really happen at the time (there is a form though for matchmaking): Anyone interested to continue the work on this kind of stuff should probably contact Gregg (Vanderheiden , who I guess wrote the first web a11y guideline back in the 90s and is a WCAG editor).

[1] https://ds.gpii.net/connect/testers

Reply on news.ycombinator.com