Live data from Hacker News

Show HN: Visualization of website accessibility tree

chromewebstore.google.com

31–35 of 35 posts

Re: Show HN: Visualization of website accessibility tree

#31
post #27

Earlier quoted context omitted.

Adding a name to an element without a role, like span or div, is technically invalid; in this example, only the 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 elements where instead (which has an implicit role), screen readers would only read "IMDb ra…

That's some good feedback and I honestly think this should have been an definition list from the start. 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 Accessi…

Be aware that the vast majority of people who rely on VoiceOver use Safari as their browser; on mobile devices, they have no choice. There are some ways in which Chrome for Mac does a better job of managing its accessibility tree than Safari but there are a bunch of other issues.

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 ).

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).

https://www.w3.org/TR/wai-aria-1.2/#application

Re: Show HN: Visualization of website accessibility tree

#32
post #31

Earlier quoted context omitted.

That's some good feedback and I honestly think this should have been an definition list from the start. 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 Accessi…

Be aware that the vast majority of people who rely on VoiceOver use Safari as their browser; on mobile devices, they have no choice. There are some ways in which Chrome for Mac does a better job of managing its accessibility tree than Safari but there are a bunch of other issues. Accessible Name and Description Computation is complicated, some elements can get their name from their contents and some can't; frankly, I…

Don’t get me wrong, I was just making an observation about a ‘role’ being specified. Not suggesting the role=“application” should be used here.

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.

Re: Show HN: Visualization of website accessibility tree

#34
post #23

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.

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.

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).

Re: Show HN: Visualization of website accessibility tree

#35
post #18

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.

"but it's already a text, can't screenreader read the text?"

I've dealt with this one, fun trick is to turn off or cover their monitor.
Post reply on HN