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.
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...
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).
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-tr...
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.
`<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: ", " / ""; } } }`
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.
I was interested about how it would change if I replaced those `span` with `p` and it still reads the entire block for me with VoiceOver.
- Parental guidance, group
- [arrow right]
- end of, Parental guidance, group
- [arrow right]
- 14+
- [arrow right]
- Production Year, group
- …
When I look at the Chrome Accessibility Tree it shows
heading "Tags"
paragraph "Parental guidance"
StaticText "14+"
paragraph "Production year"
StaticText "2016"
I do believe you're right that this shouldn't be a `aria-label` and I will replace it with `aria-description`, but I don't think that we can say that `aria-label` should only be used to fully replace the contents, as a landmark container would also be named by aria-label: https://www.w3.org/WAI/ARIA/apg/patterns/landmarks/examples/...
Edit: I just tested this but `aria-description` is not read at all. And https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... seems to indicate that aria-label should still be ok, but the div does have a `role="application"`
Accessible Name and Description Computation is complicated, some elements can get their name from their contents and some can't; frankly, I can't keep it all straight in my head.
https://www.w3.org/TR/accname-1.2/
Additionally, there's what the specs say and what browsers and screen readers actually do.
VoiceOver doesn't support the `aria-description` attribute yet. The `title` attribute is often computed as an element's description, when it's not computed as its name (it's not a good choice for naming elements, except <iframe>).
https://a11ysupport.io/tech/aria/aria-description_attribute
`role="application"` isn't a good role for static content and should only be used when letting a screen reader used its keyboard shortcuts would interfere with the user operating interactive controls (which should rarely be the case).
Ultimately in my case I’m leaning to either replacing the production year, parental guidance and IMDb rating with a dl or prepending sr-only titles to the individual tags.
I tested the page with VO on Safari and got the same results as on Chrome. So the good thing is that in practice the current setup appears to be accessible, but it’s frustrating that the theory seems to be different and just not clearly defined.
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.
Shameless plug: https://github.com/xi/aria-api
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.
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!