[HN Gopher] Show HN: Visualization of website accessibility tree
       ___________________________________________________________________
        
       Show HN: Visualization of website accessibility tree
        
       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.
        
       Author : ziolko
       Score  : 212 points
       Date   : 2024-10-07 10:38 UTC (12 hours ago)
        
 (HTM) web link (chromewebstore.google.com)
 (TXT) w3m dump (chromewebstore.google.com)
        
       | ChrisMarshallNY wrote:
       | 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 wrote:
       | Super useful, great job.
        
       | vladde wrote:
       | Looks neat, and way more clean than https://wave.webaim.org/
        
         | ziolko wrote:
         | 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 wrote:
           | 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 wrote:
       | 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 wrote:
         | "but it's already a text, can't screenreader read the text?"
        
       | yreg wrote:
       | 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...
        
         | ziolko wrote:
         | 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 wrote:
         | I wonder if you're able to open the iframe in a new tab and
         | then use the extension on it?
        
       | Someone wrote:
       | How does this compare to Chrome's built-in tooling (https://devel
       | oper.chrome.com/docs/devtools/accessibility/ref...)?
        
         | ziolko wrote:
         | 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_ wrote:
       | Does it offer any additional features compared to the
       | accessibility view in Chrome DevTools?
        
       | afloatboat wrote:
       | 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 wrote:
         | Is there a chance to get a link to the page? I'd love to try it
         | out and fix.
        
           | afloatboat wrote:
           | 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>Co
           | medy</span></div></ul></div><section><div><h2
           | id=":r1j:-cast">Cast:</h2><ul aria-labelledby=":r1j:-cast"><l
           | i><span>ABC</span><li><span>DEF</span><li><span>GHI</span></u
           | l></div></section>`
           | 
           | `section ul { margin: 0; padding: 0; list-style: none; li {
           | display: inline; &:not(:first-child)::before { content: ", "
           | / ""; } } }`
        
       | danng87 wrote:
       | 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 wrote:
       | 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-
       | tr...
        
       | Evan-Purkhiser wrote:
       | I've been using this for years now thank you so much for building
       | this!!
        
       ___________________________________________________________________
       (page generated 2024-10-07 23:01 UTC)