Comment by dstaley | Hacker News Reader

Comment by dstaley | Hacker News Reader

Parent Full thread

I love that there's a call for more UX patterns to be built into native elements, but I really wish there was a massive push to develop better a11y tooling for developers. Chromium has the A11y Tree View, but it's so noisy that as someone who isn't intimately familiar with the interaction pattern of screen readers, I can't easily digest where the issues are.

I'd love to see a purpose-built browser that "renders" your site purely by the a11y tree, but in a layout similar to how a site might look. That'd make it super easy to see missing buttons, links, uninteractable elements, etc. I'm sure there's efforts within browser developers to do this, but it's frustrating that most of the work is being spent just telling developers their sites are inaccessible rather than giving them the tooling to help make their sites accessible.

You might like ARIA DevTools, which is my open-source Chrome plugin doing exactly that

Link: https://chrome.google.com/webstore/detail/aria-devtools/dnee...

Oh my goodness. It's wonderful. This needs to be part of browsers by default! The only suggestion I have so far is it'd be pretty nice for it to be a tab in the dev tools, potentially with element highlighting as I hover over the nodes.

Actually this is not the first time someone is asking specifically about this. I haven't worked on this extension much recently, but perhaps it's time to give it more love :)

This 100%. There's the tree view and tools to make sure tags are there. Some tools to check that the site is keyboard navigable. But I still find I have to go through with a janky screen reader plugin to make sure (the best I can) that the site really works for screen readers.

The main problem is that as a sighted user, I'm used to scanning a site and discarding tons of superfluous information. If all that is read to someone it is tedious and very hard to navigate with. In many ways, the developer needs to think of an entirely new UX for a user on a screen reader. Hiding repeated elements is one of the biggest things to be done. Do the items for the screen reader have context is another. On a graphical page a button with the word "GO" might make complete sense. It makes a lot less sense when being read to a non-sighted user after listening to a bunch of other elements.

Reply on news.ycombinator.com