5 ms·

Show HN: Visualization of website accessibility tree

272 points by ziolko 2y ago

When COVID-19 started I needed something to get busy to not go crazy. I happened to work on our app WCAG compliance for a few months at the time and was frustrated by the state of of accessibility-related tools for developers. I've spend two months delivering a tool that is easy to understand and helps catching accessibility issues on my apps. A few years later it's pretty popular despite being mostly abandoned. I will be happy to work on this further but honestly lost my enthusiasm some time ago. I'd love to get in touch with some company in the accessibility testing space and discuss how to improve it.

ChrisMarshallNY 2y ago
Good stuff! I'm big on accessibility support. Web sites aren't really my deal, anymore, but I always used to make sure that my sites were very accessible, when it was my deal.
Leimi 2y ago
Super useful, great job.
vladde 2y ago
Looks neat, and way more clean than https://wave.webaim.org/ https://wave.webaim.org/
- ziolko 2y ago
  Thank you! I really think there's a lot of potential in ARIA DevTools. It's quite popular (at least for my standards) but I never had any connection with people that live and breathe web accessibility. And the devil is in the details here so to be fully fair, WAVE is most probably more accurate.
  - InvisGhost 2y ago
    Definitely more accurate however it's UX is awful and doesn't do a good job of prioritizing issues. It sucks that you basically have to install a screen reader app to get the most accurate idea of how screen readers see your site.
notjustanymike 2y ago
A very handy tool for spot checking, but also training. My benefit from this visualization will be demonstrating to non-technical how to people to think about accessibility (specifically screen readers). Half the challenge with WCAG is getting our stakeholders to think beyond ticking boxes for compliance.
- Muromec 2y ago
  "but it's already a text, can't screenreader read the text?"
  - notjustanymike 2y ago
    I've dealt with this one, fun trick is to turn off or cover their monitor.
- _bin_ 2y ago
  this kind of makes sense though? if 98% of your users can use a non-accessible site just fine - which, since heavy computer users are mostly young, is realistic - why would you go beyond checkboxes? it's a negative EV move.
  - notjustanymike 2y ago
    You have to be careful with that line of reasoning; I could rephrase it as "Why bother worrying about minorities?" People with disabilities cannot be treated like legacy browsers. They have no other option, and there are times when viewing the content is mandatory. Consider content for school, medical, financial, governmental; in those cases we have a responsibility to create an equal experience in both law (WCAG 2.2 compliance, ticking boxes) and spirit (ensuring they can access the information needed to live their life).
yreg 2y ago
Thank you, this looks great! Could you please run it inside iframes as well? Being able to use this in the Storybook/Playroom would be awesome. --- Firefox link: https://addons.mozilla.org/en-US/firefox/addon/aria-devtools/ https://addons.mozilla.org/en-US/firefox/addon/aria-devtools...
- ziolko 2y ago
  I am super glad you like it! The primary reason I haven't introduced support for iframes is that it requires much wider permissions (instead of just access to the current tab after clicking the "ARIA DevTools" icon you'd need to grant access to all data on every website you visit). I will research if things changed since I last checked, though.
- InvisGhost 2y ago
  I wonder if you're able to open the iframe in a new tab and then use the extension on it?
  - dimal 2y ago
    Yes, that’s possible with StoryBook. It’s one of the tiny buttons on the top right, I think.
    - yreg 2y ago
      Mhm, also works in Playroom: Preview -> Open
Someone 2y ago
How does this compare to Chrome’s built-in tooling (https://developer.chrome.com/docs/devtools/accessibility/reference https://developer.chrome.com/docs/devtools/accessibility/ref...)?
- ziolko 2y ago
  When I designed the tool I've tried to mirror the experience of screen readers users instead of only displaying ARIA roles and properties. For example you have to navigate the page with your keyboard only. If a dropdown isn't accessible - it's instantly clear for the user. Another example are tables. They present only one cell + their headers at the time. I think it's super close to the actual experience of screen reader users.
antriani_ 2y ago
Does it offer any additional features compared to the accessibility view in Chrome DevTools?
afloatboat 2y ago
Pretty clean, I like it. I tested it out on a page I'm developing that has some meta data on a TV show. One of the elements is a set of divs each containing span with an `aria-label` describing the contents. With MacOs' VO this gets called out correctly, and Chrome's Accessibility Tree also picks this up, but this tool doesn't show the `aria-label`, it just shows the separate values as strings one after another. It also picked up a `::before { content: ", " / ""; }` as `, value`, but that's not supported very well in general.
- ziolko 2y ago
  Is there a chance to get a link to the page? I'd love to try it out and fix.
  - afloatboat 2y ago
    I can't link the page, but this is a cleaned up DOM output (the extra spans/divs are components): `<div><div><span aria-label="IMDb rating" title="IMDb rating">IMDb 8.2</span></div><div><span aria-label="Parental guidance" title="Parental guidance">12+</span></div><div><span aria-label="Production year" title="Production year">2007</span></div><ul aria-label="Genre"><li><div><span>Romance</span></div><li><div><span>Comedy</span></div></ul></div><section><div><h2 id=":r1j:-cast">Cast:</h2><ul aria-labelledby=":r1j:-cast"><li><span>ABC</span><li><span>DEF</span><li><span>GHI</span></ul></div></section>` `section ul { margin: 0; padding: 0; list-style: none; li { display: inline; &:not(:first-child)::before { content: ", " / ""; } } }`
    - ziolko 2y ago
      That's super helpful. I will get this fixed soon :)
    - extra88 2y ago
      Adding a name to an element without a role, like span or div, is technically invalid; in this example, only the <ul> elements have valid names added to them, because they implicitly have the role of "list." Also, aria-label and aria-labelledby replace the contents of an element when the contents would otherwise be the name; if the <span> elements where <p> instead (which has an implicit role), screen readers would only read "IMDb rating" and not "IMDb 8.2." What might be happening is the aria-label attributes are ignored but the title attributes are used as a description after the contents. For some elements `title` can be used as an element description; I think descriptions are also invalid without a role but they may get used anyway. I think it's best for a visualizing tool to not display attribute information that won't be used by screen readers.
danng87 2y ago
Awesome tool! I've been diving more into accessibility lately, especially trying to improve the experience for screen reader users. For those with more experience, has anyone tested this tool on more complex scenarios like extensive forms or dynamic tables? I'd love to hear how it compares to other accessibility tools in those cases. Any tips or insights would be appreciated!
kilian 2y ago
Very cool. I recently implemented my own accessibility tree visualization [1] Yours is very interesting, getting away from the tree itself to a visualization more focused on grouping discrete units. My thinking was to show the entire structure and through that help people focus on a logical flow through the page. Flipping that around and thinking of the tree as a set of discrete blocks, where the cohesion inside each block is more important, is very interesting. Happy to chat if you want to compare notes! [1] https://polypane.app/blog/polypane-20-1-the-accessibility-tree/ https://polypane.app/blog/polypane-20-1-the-accessibility-tr...
evanpurkhiser 2y ago
I’ve been using this for years now thank you so much for building this!!
- ziolko 2y ago
  I am glad to see a happy user here! :)
Arnaudkot 2y ago
[flagged]
freetonik 2y ago
Great idea and implementation, thank you, I’ll definitely use it for my side project. Coincidentally, I just watched a talk by Mandy Michael [1] about HTML performance and accessibility, and was wondering if there is a tool nicer than browser’s built in accessibility tree viewer. 1. https://youtu.be/cghb0VpCJqM?si=5pWNrkPOyUsohyGJ https://youtu.be/cghb0VpCJqM?si=5pWNrkPOyUsohyGJ
ximm 2y ago
One thing we I wish we would do with these tools is separate all the aria logic from the UI. We should put all that complex aria stuff into a library and then build different UIs on top of a shared, well tested code base. Shameless plug: https://github.com/xi/aria-api https://github.com/xi/aria-api
deleted 2y ago
[deleted]

272 points by ziolko 2y ago

ChrisMarshallNY 2y ago

Good stuff! I'm big on accessibility support. Web sites aren't really my deal, anymore, but I always used to make sure that my sites were very accessible, when it was my deal.

Leimi 2y ago

Super useful, great job.

vladde 2y ago

Looks neat, and way more clean than https://wave.webaim.org/ https://wave.webaim.org/

ziolko 2y ago
Thank you! I really think there's a lot of potential in ARIA DevTools. It's quite popular (at least for my standards) but I never had any connection with people that live and breathe web accessibility. And the devil is in the details here so to be fully fair, WAVE is most probably more accurate.
- InvisGhost 2y ago
  Definitely more accurate however it's UX is awful and doesn't do a good job of prioritizing issues. It sucks that you basically have to install a screen reader app to get the most accurate idea of how screen readers see your site.

notjustanymike 2y ago

A very handy tool for spot checking, but also training. My benefit from this visualization will be demonstrating to non-technical how to people to think about accessibility (specifically screen readers). Half the challenge with WCAG is getting our stakeholders to think beyond ticking boxes for compliance.

Muromec 2y ago
"but it's already a text, can't screenreader read the text?"
- notjustanymike 2y ago
  I've dealt with this one, fun trick is to turn off or cover their monitor.
_bin_ 2y ago
this kind of makes sense though? if 98% of your users can use a non-accessible site just fine - which, since heavy computer users are mostly young, is realistic - why would you go beyond checkboxes? it's a negative EV move.
- notjustanymike 2y ago
  You have to be careful with that line of reasoning; I could rephrase it as "Why bother worrying about minorities?" People with disabilities cannot be treated like legacy browsers. They have no other option, and there are times when viewing the content is mandatory. Consider content for school, medical, financial, governmental; in those cases we have a responsibility to create an equal experience in both law (WCAG 2.2 compliance, ticking boxes) and spirit (ensuring they can access the information needed to live their life).

yreg 2y ago

Thank you, this looks great! Could you please run it inside iframes as well? Being able to use this in the Storybook/Playroom would be awesome. --- Firefox link: https://addons.mozilla.org/en-US/firefox/addon/aria-devtools/ https://addons.mozilla.org/en-US/firefox/addon/aria-devtools...

ziolko 2y ago
I am super glad you like it! The primary reason I haven't introduced support for iframes is that it requires much wider permissions (instead of just access to the current tab after clicking the "ARIA DevTools" icon you'd need to grant access to all data on every website you visit). I will research if things changed since I last checked, though.
InvisGhost 2y ago
I wonder if you're able to open the iframe in a new tab and then use the extension on it?
- dimal 2y ago
  Yes, that’s possible with StoryBook. It’s one of the tiny buttons on the top right, I think.
  - yreg 2y ago
    Mhm, also works in Playroom: Preview -> Open

Someone 2y ago

How does this compare to Chrome’s built-in tooling (https://developer.chrome.com/docs/devtools/accessibility/reference https://developer.chrome.com/docs/devtools/accessibility/ref...)?

ziolko 2y ago
When I designed the tool I've tried to mirror the experience of screen readers users instead of only displaying ARIA roles and properties. For example you have to navigate the page with your keyboard only. If a dropdown isn't accessible - it's instantly clear for the user. Another example are tables. They present only one cell + their headers at the time. I think it's super close to the actual experience of screen reader users.

antriani_ 2y ago

Does it offer any additional features compared to the accessibility view in Chrome DevTools?

afloatboat 2y ago

Pretty clean, I like it. I tested it out on a page I'm developing that has some meta data on a TV show. One of the elements is a set of divs each containing span with an `aria-label` describing the contents. With MacOs' VO this gets called out correctly, and Chrome's Accessibility Tree also picks this up, but this tool doesn't show the `aria-label`, it just shows the separate values as strings one after another. It also picked up a `::before { content: ", " / ""; }` as `, value`, but that's not supported very well in general.

ziolko 2y ago
Is there a chance to get a link to the page? I'd love to try it out and fix.
- afloatboat 2y ago
  I can't link the page, but this is a cleaned up DOM output (the extra spans/divs are components): `<div><div><span aria-label="IMDb rating" title="IMDb rating">IMDb 8.2</span></div><div><span aria-label="Parental guidance" title="Parental guidance">12+</span></div><div><span aria-label="Production year" title="Production year">2007</span></div><ul aria-label="Genre"><li><div><span>Romance</span></div><li><div><span>Comedy</span></div></ul></div><section><div><h2 id=":r1j:-cast">Cast:</h2><ul aria-labelledby=":r1j:-cast"><li><span>ABC</span><li><span>DEF</span><li><span>GHI</span></ul></div></section>` `section ul { margin: 0; padding: 0; list-style: none; li { display: inline; &:not(:first-child)::before { content: ", " / ""; } } }`
  - ziolko 2y ago
    That's super helpful. I will get this fixed soon :)
  - extra88 2y ago
    Adding a name to an element without a role, like span or div, is technically invalid; in this example, only the <ul> elements have valid names added to them, because they implicitly have the role of "list." Also, aria-label and aria-labelledby replace the contents of an element when the contents would otherwise be the name; if the <span> elements where <p> instead (which has an implicit role), screen readers would only read "IMDb rating" and not "IMDb 8.2." What might be happening is the aria-label attributes are ignored but the title attributes are used as a description after the contents. For some elements `title` can be used as an element description; I think descriptions are also invalid without a role but they may get used anyway. I think it's best for a visualizing tool to not display attribute information that won't be used by screen readers.

danng87 2y ago

Awesome tool! I've been diving more into accessibility lately, especially trying to improve the experience for screen reader users. For those with more experience, has anyone tested this tool on more complex scenarios like extensive forms or dynamic tables? I'd love to hear how it compares to other accessibility tools in those cases. Any tips or insights would be appreciated!

kilian 2y ago

Very cool. I recently implemented my own accessibility tree visualization [1] Yours is very interesting, getting away from the tree itself to a visualization more focused on grouping discrete units. My thinking was to show the entire structure and through that help people focus on a logical flow through the page. Flipping that around and thinking of the tree as a set of discrete blocks, where the cohesion inside each block is more important, is very interesting. Happy to chat if you want to compare notes! [1] https://polypane.app/blog/polypane-20-1-the-accessibility-tree/ https://polypane.app/blog/polypane-20-1-the-accessibility-tr...

evanpurkhiser 2y ago

I’ve been using this for years now thank you so much for building this!!

ziolko 2y ago
I am glad to see a happy user here! :)

Arnaudkot 2y ago

[flagged]

freetonik 2y ago

Great idea and implementation, thank you, I’ll definitely use it for my side project. Coincidentally, I just watched a talk by Mandy Michael [1] about HTML performance and accessibility, and was wondering if there is a tool nicer than browser’s built in accessibility tree viewer. 1. https://youtu.be/cghb0VpCJqM?si=5pWNrkPOyUsohyGJ https://youtu.be/cghb0VpCJqM?si=5pWNrkPOyUsohyGJ

ximm 2y ago

One thing we I wish we would do with these tools is separate all the aria logic from the UI. We should put all that complex aria stuff into a library and then build different UIs on top of a shared, well tested code base. Shameless plug: https://github.com/xi/aria-api https://github.com/xi/aria-api

deleted 2y ago

[deleted]