10 ms·

No ARIA is better than bad ARIA

126 points by robin_reala 11mo ago

simonw 11mo ago
Something I'm desperately keen to see is AI-assisted accessibility testing. I'm not convinced at all by most of the heuristic-driven ARIA scanning tools. I don't want to know if my app appears to have the right ARIA attributes set - I want to know if my features work for screenreader users. What I really want is for a Claude Code style agent to be able to drive my application in an automated fashion via a screenreader and record audio for me of successful or failed attempts to achieve goals. Think Playwright browser tests but for popular screenreaders instead. Every now and then I check to see if this is a solved problem yet. I think we are close. https://www.guidepup.dev/ https://www.guidepup.dev/ looks extremely promising - though I think it only supports VoiceOver on macOS or NVDA on Windows, which is a shame since asynchronous coding agent tools like Codex CLI and Claude Code for web only run Linux. What I haven't seen yet is someone closing the loop on ensuring agentic tools like Claude Code can successfully drive these mechanisms.
- simonw 11mo ago
  ... I just saw Guidepup has an official GitHub Actions setup action, so that's great news! https://github.com/guidepup/setup-action https://github.com/guidepup/setup-action On macOS it can record audio too.
- PebblesHD 11mo ago
  Rather than improving testing for fallible accessibility assists, why not leverage AI to eliminate the need for them? An agent on your device can interpret the same page a sighted or otherwise unimpaired person would giving you as a disabled user the same experience they would have. Why would that not be preferable? It also puts you in control of how you want that agent to interpret pages.
  - eru 11mo ago
    What you are describing is something the end user can do. What simonw was describing is something the author can do, and end user can benefit whether they use AI or not.
  - simonw 11mo ago
    I'm optimistic that modern AI will lead to future improvements in accessibility tech, but for the moment I want to meet existing screenreader users where they are and ensure the products I build are as widely accessible as possible.
  - K0nserv 11mo ago
    It adds loads of latency for one. If you watch someone who is a competent screen reader user you'll notice they have the speech rate set very high, to you it'll be hard to understand anything. Adding an LLM in the middle of this will add, at least, hundreds of milliseconds of latency to interactions.
  - 8organicbits 11mo ago
    The golden rule of LLMs is that they can make mistakes and you need to check their work. You're describing a situation where the intended user cannot check the LLM output for mistakes. That violates a safety constraint and is not a good use case for LLMs.
  - devinprater 11mo ago
    I, myself, as a singular blind person, would absolutely love this. But we ain't there yet. On-device AI isn't finetuned for this, and neither Apple nor Google have shown indications of working on this in release software, so I'm sure we're a good 3 years away from the first version of this.
- askew 11mo ago
  Guidepup also includes a Virtual Screenreader[1]. [1] https://www.guidepup.dev/docs/virtual https://www.guidepup.dev/docs/virtual
- edflsafoiewq 11mo ago
  Can screen readers emit their narration as text instead of / in addition to audio?
  - devinprater 11mo ago
    Yes, they can. NVDA has a Speech Viewer. VoiceOver (Mac) has the caption panel. NVDA Speech viewer: https://download.nvaccess.org/documentation/userGuide.html#SpeechViewer https://download.nvaccess.org/documentation/userGuide.html#S... Caption Panel: https://support.apple.com/guide/voiceover/use-the-caption-panel-unac078/mac https://support.apple.com/guide/voiceover/use-the-caption-pa...
  - askew 11mo ago
    Yes. Output can be sent to a Braille device too.
- devinprater 11mo ago
  There are thousands of blind people on the net. Can't you hire one of them to test for you? Please?
  - simonw 11mo ago
    Realistically I'm unlikely to do that for my dozens of non-income-generating personal projects. I still want them to be accessible! (The amount of accessibility testing I want to do would bankrupt me very quickly.)
  - m12k 11mo ago
    If you don't want this to break eventually, you need it tested every time your CI/CD test suite runs. Manual testing just doesn't cut it
    - cenamus 11mo ago
      AI in your CI pipeline won't help either then, if it randomly gives different answers
      - simonw 11mo ago
        An AI-generated automated testing script in your pipeline will do great though.
        debugnik 11mo ago
        And then we're back at your own: > I'm not convinced at all by most of the heuristic-driven ARIA scanning tools.
        simonw 11mo ago
        That's entirely different. ARIA scanning tools are things that throw an error if they see an element that's missing an attribute, without even attempting to invoke a real screenreader. I'm arguing for automated testing scripts that use tools like Guidepup to launch a real screenreader and assert things like the new content that was added by fetch() being read out to the user after the form submission has completed. I want LLMs and coding agents to help me write those scripts, so I can run them in CI along with the rest of my automated tests.
- throawayonthe 11mo ago
  can we just hire disabled people as testers please
  - simonw 11mo ago
    How about both?
- wouldbecouldbe 11mo ago
  Not a joke. If truly you want a properly functioning website for blind/bad sight/ Step 1 would probably be to put on a blindfold and go through your website with a screenreader (cmd + f5 on a mac).
  - simonw 11mo ago
    Here are notes from last time I tried that: https://tools.simonwillison.net/aria-live-regions https://tools.simonwillison.net/aria-live-regions It's not something I'm comfortable enough with to do on a regular basis though.
    - wouldbecouldbe 11mo ago
      yeah its a real challenge, but probably the only way to really understand it. It's a completely different way of using the web. GPT can really help understand it while doing it.
  - ErroneousBosh 11mo ago
    I would very much like to be better at building websites that handle assistive technologies like screen readers well. I don't have a lot of blind users to worry about because they don't let you be a firefighter if you're blind. But a lot of firefighters are people who simply did not do well in school, even the very senior ones, and that's because they are often very clever people who are of an age where things like dyslexia were just not diagnosed early or often. So now I deal with a lot of people who use assistive technologies to help with dyslexia and related comorbidities. I have dyscalculia that wasn't diagnosed until I was 19 and at uni, and even then it was diagnosed initially by my mate's Educational Psychology undergrad girlfriend in the pub one evening. That was in the early 90s and we're better at it now - but not by much.
    - wouldbecouldbe 11mo ago
      Yeah i don't think it's worth doing for every web app. But I do think it's fair that for instance government websites try to meet these criteria.
- api 11mo ago
  What about just AI assisted accessibility? Like stop requiring apps to do anything at all. The AI visually parses the app UI for the user, explains it, and interacts. Accessible is an also-have at best for the vast majority of software. This would open a lot more software to blind users than is currently available.
  - simonw 11mo ago
    That's expensive, slow (listen to a screenreader user some time to see how quickly they operate) and likely only works online. I'm also not going to shirk my responsibilities as a developer based on a hope that the assistive tech will improve.
    - api 11mo ago
      It’s expensive for now, slow for now, online for now, but it’s pretty clear that this is the future. If I were blind I’d want it to go here since it would just unlock so much more. Very little software or sites have good accessibility. Open source and indie stuff often has none. A custom local model trained only for this task seems like a possibility, and could be way smaller than some general purpose model being instructed for this task. I’m thinking screen reader and UI assist only. Could probably be like a 7B quantized model. Maybe smaller.
- jillesvangurp 11mo ago
  A more viable path might actually be agentic testing via agents that simply use a browser or screen reader that can work off high level test scenarios. I've done some UI testing via the agent mode in chat gpt and I got some pretty decent feedback out of that. I've been trying to do more of that. Accessibility testing might require a bit more additional tooling than comes with chat gpt by default. But otherwise, this could work.
- klysm 11mo ago
  There might be a great use case here, but the economics make me nervous. Don't the same problems apply here for why we don't have great accessibility? Who is paying for it? How do I justify the investment (AI or not) to management?
- Moto7451 11mo ago
  I’m doing a PoC at work with Workback.ai, which is essentially what you’re asking about. So far it’s early but it seems ok at first brush. We have a firm we pay for traditional accessibility assessments, remediation, and VPATs and my expectation is that the AI tooling does not replace them due to how business needs and product design interact with accessibility. I.e. ChatGPT and Cursor can probably remediate adding screen reader support for a solving a Captia for the blind, but do you want to really do that? There’s likely a better design for the blind. Either way, I agree. This is a big area where there can be real impact in the industry. So far we’ve gotten scans back in record time compared to human in the loop scans.
- westont5 11mo ago
  The agent-driving-a-screenreader footgun is that it's quite easy to build UI that creates a reasonable screereader UX, but unintentionally creates accessibility barriers for other assistive technologies, like voice control. Ex: a search control is built as <div aria-label="Search"><input type="search"/></div>. An agent driving a screenreader is trying to accomplish a goal that requires search. Perhaps it tries using Tab to explore, in which case it will hear "Search, edit blank" when the input is focused. Great! It moves on. But voice control users can't say "click Search". That only works if "Search" is in the control's accessible name, which is still blank, the outer div's aria-label has no effect on components it wraps. Would an agent catch that nuance? Would you? You could realign to "I want to know if my features work for screenreader, voice control, switch, keyboard, mobile keyboard [...] users", but you can imagine the inverse, where an improvement to the voice control UX unintentionally degrades the screenreader UX. Accessibility is full of these tensions, I worry an multi-agent approach would result in either the agents or you getting bogged down by them. I think a solution needs to incorporate some heuristics, if you consider WCAG a heuristic. For all its faults, a lot of thought went into rules that balance the tensions reasonably well. I used to be more of the "forget WCAG, just show me the UX" attitude, but over the years I've come to appreciate the baseline it sets. To the example above, 2.5.3 Label in Name clearly guides you towards setting an accessible name (not description) on the search itself, patching up support for screenreaders and voice control. Not that WCAG concerns itself with the details of ARIA (it packs all that complexity into the vague "accessibility supported"[1]). We do need more seamless ways of quickly evaluating whether ARIA or whatever markup pattern has the intended rendering in screen readers, voice control, etc, but at a level that's already constrained. In the example, WCAG should apply its constraints first. Only then should we start running real screen readers and analyzing their audio, and to avoid the footguns that analysis should be at a low level ("does the audio rendering of this control reasonably convey the expected name, state, value, etc?"), not a high level ("does the audio rendering contain the info necessary to move to the next step?"). Unfortunately both agents and heuristic-driven accessibility scanning tools struggle to apply WCAG today. Agents can go deeper than scanners, but they're inconsistent and in my experience really have trouble keeping 55+ high level rules in mind all the time. In the example, an agent would need to use the accessibility tree to accomplish its goal and need to reject a node with label "Search" containing a role=textbox as an option for searching (or at least flag it), which is made trickier by the fact that sometimes it _is_ ok to use container labels to understand context. I think the answer might be to bundle a lot of those concerns into an E2E test framework, have the agent write a test it thinks can accomplish the goal, and enter a debug loop to shake out issues progressively. Ex: if the agent needs to select the search control for the task, and the only allowed selector syntax requires specifying the control's accessible name (i.e. Playwright's getByRole()), will the agent correctly get blocked? And say the control does have an accessible name, but has some ARIA misconfigurations — can the test framework automatically run against some real screenreaders and report an issue that things aren't working as expected? We've done some explorations on the framework side you might be interested in [2]. [1] https://www.w3.org/TR/WCAG22/#dfn-accessibility-supported https://www.w3.org/TR/WCAG22/#dfn-accessibility-supported [2] https://assistivlabs.com/articles/automating-screen-readers-for-accessibility-testing https://assistivlabs.com/articles/automating-screen-readers-...
i-con 11mo ago
No CSS is better than bad CSS In my browser that "Page Contents" box is hovering above the end of the line, so I can't read the full text. Kind of ironic, that this is on w3.org
- the_other 11mo ago
  > No CSS is better than bad CSS That's only true if the markup and JS are also good. If, for sake of argument, the HTML had been badly authored such that the links in that menu were DIVs with click event handlers, rather than real links, then removing CSS would likely make the experience worse rather than better. I guess that a key point underpinning your comment is that progressive enhancement is still better than assuming all potential users are on the bleeding edge, despite the evergreen update pattern for the most popular 3 or 4 browsers.
- account42 11mo ago
  What browser is that?
  - i-con 11mo ago
    Tested with WebKit and Gecko. Apparently the position gets fixed up at runtime if JavaScript is enabled. But why have dynamic elements with CSS if you need JavaScript to fix it?
    - account42 11mo ago
      Ok yeah that's really weird. It uses javascript to unconditionally add the has-sidebar class to <body>. Maybe a limitation of their templating system but that's not really an excuse.
gampleman 11mo ago
Is this really true? Messaging like this will cause a lot of developers to just give up. Most places I've worked at did accessibility at best as a best effort sort of thing. After reading this, there will be no attempts made to improve the state of affairs. Perhaps that will be an improvement? I don't know.
- askew 11mo ago
  The statement is about encouraging folks to use the platform: `<button>Hello!</button>` over `<div role=button tabindex=0>Hello</div>`
- austin-cheney 11mo ago
  ARIA is often a compensating technology more than a primary solution. I try to not use ARIA in my own code aside from the role attribute. I instead rely on the clear navigation and order HTML content and events as my primary solutions.
  - no_wizard 11mo ago
    Using the right elements (like button instead of a div) will take you very, very, very fair with little to no additional work.
    - tracker1 11mo ago
      +1 here... <button> vs <a> in particular... if it's programmatic behavior, use a styled button if you want it to look like a link, and vice-versa for navigation behaviors. I will add that a good component library should also handle some of this for you... in particular menu navigation, popouts/drawers etc. That said, can't say how many sites/apps have really broken behavior with this.
- nabla9 11mo ago
  It is true. This is not messaging. They are not selling you ARIA. If you are developer, just write semantically clear HTML instead. Just doing something is worse than doing nothing in accessibility.
hamonrye 11mo ago
[dead]
Bengalilol 11mo ago
2 cents here. Let's make this article optimistic and forward looking. That's somehow intriguing to write an article that says "no" without providing "yes" examples. I don't view this as very generous. Looking for further updates.
- dnrvs 11mo ago
  This is the "Read Me First" page on a site absolutely full of documentation...
- throawayonthe 11mo ago
  the rest of this website section is exactly that: https://www.w3.org/WAI/ARIA/apg/practices/ https://www.w3.org/WAI/ARIA/apg/practices/ and generally: https://www.w3.org/WAI/ARIA/apg/ https://www.w3.org/WAI/ARIA/apg/
emsixteen 11mo ago
I think it would be very beneficial if the browser vendors, together with screenreader vendors and those who use them, were able to come together to actually unify the approach to how elements/these attributes/etc. are communicated to the end user.
- pickpuck 11mo ago
  They're working on it in the "Core Accessibility API Mappings" spec https://www.w3.org/TR/core-aam-1.2/ https://www.w3.org/TR/core-aam-1.2/
- gostsamo 11mo ago
  this part is covered. the issue are the web devs who need or decide that they need to repurpose a set of elements into another set of elements and skip informing the non visual user about that.
draw_down 11mo ago
[dead]
tonyhart7 11mo ago
this is why I don't bother with ARIA
notpachet 11mo ago
This is also true of alt text for images. I'm active on Bluesky, and so often I see an image with an "ALT" tag (meaning that the user has specified alt text for the image) only for it to be some meaningless offhand bullshit like "lmao i guess i showed them". Pisses me off.
- diegolas 11mo ago
  people've been confusing the title and alt tags since like IE4
jillesvangurp 11mo ago
I've looked a few times at this space. Most of the documentation seems to devolve into a depth first deep dive into here's a bunch of tags and attributes without laying out a coherent goal of what you should be doing. My observations: - most web developers have never seen a screen reader version of their application; or any application. - most teams don't have visually handicapped people that use a screen reader that could provide feedback - so, no bugs ever get reported regarding accessibility That is, unless developers go out of their way to use proper tools and do proper testing for this. And testing practices for Aria probably is at the same level as it is for other application features: sketchy to non existent at best. Let's face it, mostly Aria is pure box ticking for developers. There has to be some (regulations, and PMs insisting because of that). But it doesn't have to be good since nobody really checks these things. Including the PM. Without a feedback loop, it's not surprising that most web apps don't get this even close to right. IMHO, over time, agentic tools might actually be more helpful to blind people as they can summarize, describe, and abstract what's on the screen. Agentic testing via a screen reader might also become a thing. I've done some testing via the agent mode in chat gpt and it was shockingly good at figuring out our UI. Not a bad process for automating what used to be manual QA. I've been meaning to put more time in this. I actually have as a very low priority target to start driving some of this in our own application. Mostly that's just a hunch it might come up because of some government customers. But this is Germany and they seem to have lots of blind spots on software quality. I don't actually expect any feedback whatsoever from actual customers or anyone on this. I just want to pre-empt that.
- scroot 11mo ago
  For those of us in civic tech, this is a higher priority. At the federal level especially, there are laws on the books about website accessibility compliance -- even if, at present, the powers that be are ignoring them. I have found the Web Content Accessibility Guidelines [1] to be especially useful when thinking through what I need to implement and why. It is _impossible_ to thoroughly test any of your accessibility concerns only with automated tooling. You will need to have an experienced user of screenreaders go through your site, especially if it contains complex JS enabled controls and other dynamic updates. This is because the habits of individual users and the combination of a particular screenreader application / browser can often produce different results. It's important to know what the common "patterns of use" are for, say, a JAWS user vs a VoiceOver user. Last thing I'll recommend is that if you are testing a11y yourself on a Mac using VoiceOver, do all your a11y testing in Safari. In our research, most VO users on Macs/iOS use Safari because it has the best screenreader integration on that platform, and other browsers miss basic things. [1] https://www.w3.org/WAI/standards-guidelines/wcag/ https://www.w3.org/WAI/standards-guidelines/wcag/
deleted 11mo ago
[deleted]
londons_explore 11mo ago
The future of accessibility is AI agents. Ie. Don't make the web page accessible to some ancient screen reader software - instead make sure AI agents can interact with it so the real user can instruct the AI to perform the task on their behalf.
- the_other 11mo ago
  How does the user know what the page is capable of in order to be able to instruct the agent?
wccrawford 11mo ago
No examples are better than no examples. They really needed to show what the proper way to implement those scenarios was, as well as the proper way to use those aria properties. As it stands, they look good, and someone that isn't paying attention is going to think they're correct and use them.
- wccrawford 11mo ago
  Oops. I mean "than bad examples". Guess I should have proofread, huh?
sapphirebreeze 11mo ago
MMMKAY?
daveguy 11mo ago
Since the acronym is not defined anywhere in the link: ARIA = Accessible Rich Internet Applications Part of the W3 consortium's Web Accessibility Initiative. https://en.wikipedia.org/wiki/WAI-ARIA https://en.wikipedia.org/wiki/WAI-ARIA
burningChrome 11mo ago
Interesting as a developer coming into accessibility, I was repeatedly told, "The first rule of ARIA is not to use ARIA." It feels like we've gone so far away from semantical code that ARIA is now being used a crutch to replace semantical approaches to coding.
- tracker1 11mo ago
  Can't +1 this enough... I've found that in practice, outside of images, menu pop/flyout and dialogs/trays, there really isn't too much need for additional aria attributes. Most component libraries should already be configured out of the box imo. ARIA should only be needed relatively sparingly assuming you're using appropriate semantic elements. Testing with keyboard only navigation can reveal a lot as well. Related, and one I experience a lot are issues on mobile devices with text/display cranked up... too many modal interactions with buttons off-screen.
codelikeawolf 11mo ago
As someone who has spent a lot of time trying to gain a11y expertise and learn best practices, this messaging drives me a little bonkers. There is so much inaccessible content on the web. The official ARIA guide tells you "you're better off doing nothing". All of the example patterns in the ARIA Practices Guide (APG) tell you the code isn't for production use [1]. They provide an explanation which points back to..."you're better off doing nothing". When I need to add a toolbar to my app, and I want it to be accessible. I look at the APG, the APG has a toolbar example with markup, CSS, and JS, but apparently I'm not supposed to use it. I've been at this for years and it's incredibly frustrating. I usually use the APG code in production anyways. It's probably not catastrophically wrong, but it always makes me feel like I'm screwing something up. The alternative is to use a bunch of divs, spans, and buttons because not all of the patterns have semantic HTML equivalents. [1] https://www.w3.org/WAI/ARIA/apg/patterns/grid/examples/layout-grids/#support-notice-header https://www.w3.org/WAI/ARIA/apg/patterns/grid/examples/layou...

126 points by robin_reala 11mo ago

simonw 11mo ago

Something I'm desperately keen to see is AI-assisted accessibility testing. I'm not convinced at all by most of the heuristic-driven ARIA scanning tools. I don't want to know if my app appears to have the right ARIA attributes set - I want to know if my features work for screenreader users. What I really want is for a Claude Code style agent to be able to drive my application in an automated fashion via a screenreader and record audio for me of successful or failed attempts to achieve goals. Think Playwright browser tests but for popular screenreaders instead. Every now and then I check to see if this is a solved problem yet. I think we are close. https://www.guidepup.dev/ https://www.guidepup.dev/ looks extremely promising - though I think it only supports VoiceOver on macOS or NVDA on Windows, which is a shame since asynchronous coding agent tools like Codex CLI and Claude Code for web only run Linux. What I haven't seen yet is someone closing the loop on ensuring agentic tools like Claude Code can successfully drive these mechanisms.

simonw 11mo ago
... I just saw Guidepup has an official GitHub Actions setup action, so that's great news! https://github.com/guidepup/setup-action https://github.com/guidepup/setup-action On macOS it can record audio too.
PebblesHD 11mo ago
Rather than improving testing for fallible accessibility assists, why not leverage AI to eliminate the need for them? An agent on your device can interpret the same page a sighted or otherwise unimpaired person would giving you as a disabled user the same experience they would have. Why would that not be preferable? It also puts you in control of how you want that agent to interpret pages.
- eru 11mo ago
  What you are describing is something the end user can do. What simonw was describing is something the author can do, and end user can benefit whether they use AI or not.
- simonw 11mo ago
  I'm optimistic that modern AI will lead to future improvements in accessibility tech, but for the moment I want to meet existing screenreader users where they are and ensure the products I build are as widely accessible as possible.
- K0nserv 11mo ago
  It adds loads of latency for one. If you watch someone who is a competent screen reader user you'll notice they have the speech rate set very high, to you it'll be hard to understand anything. Adding an LLM in the middle of this will add, at least, hundreds of milliseconds of latency to interactions.
- 8organicbits 11mo ago
  The golden rule of LLMs is that they can make mistakes and you need to check their work. You're describing a situation where the intended user cannot check the LLM output for mistakes. That violates a safety constraint and is not a good use case for LLMs.
- devinprater 11mo ago
  I, myself, as a singular blind person, would absolutely love this. But we ain't there yet. On-device AI isn't finetuned for this, and neither Apple nor Google have shown indications of working on this in release software, so I'm sure we're a good 3 years away from the first version of this.
askew 11mo ago
Guidepup also includes a Virtual Screenreader[1]. [1] https://www.guidepup.dev/docs/virtual https://www.guidepup.dev/docs/virtual
edflsafoiewq 11mo ago
Can screen readers emit their narration as text instead of / in addition to audio?
- devinprater 11mo ago
  Yes, they can. NVDA has a Speech Viewer. VoiceOver (Mac) has the caption panel. NVDA Speech viewer: https://download.nvaccess.org/documentation/userGuide.html#SpeechViewer https://download.nvaccess.org/documentation/userGuide.html#S... Caption Panel: https://support.apple.com/guide/voiceover/use-the-caption-panel-unac078/mac https://support.apple.com/guide/voiceover/use-the-caption-pa...
- askew 11mo ago
  Yes. Output can be sent to a Braille device too.
devinprater 11mo ago
There are thousands of blind people on the net. Can't you hire one of them to test for you? Please?
- simonw 11mo ago
  Realistically I'm unlikely to do that for my dozens of non-income-generating personal projects. I still want them to be accessible! (The amount of accessibility testing I want to do would bankrupt me very quickly.)
- m12k 11mo ago
  If you don't want this to break eventually, you need it tested every time your CI/CD test suite runs. Manual testing just doesn't cut it
  - cenamus 11mo ago
    AI in your CI pipeline won't help either then, if it randomly gives different answers
    - simonw 11mo ago
      An AI-generated automated testing script in your pipeline will do great though.
      - debugnik 11mo ago
        And then we're back at your own: > I'm not convinced at all by most of the heuristic-driven ARIA scanning tools.
        simonw 11mo ago
        That's entirely different. ARIA scanning tools are things that throw an error if they see an element that's missing an attribute, without even attempting to invoke a real screenreader. I'm arguing for automated testing scripts that use tools like Guidepup to launch a real screenreader and assert things like the new content that was added by fetch() being read out to the user after the form submission has completed. I want LLMs and coding agents to help me write those scripts, so I can run them in CI along with the rest of my automated tests.
throawayonthe 11mo ago
can we just hire disabled people as testers please
- simonw 11mo ago
  How about both?
wouldbecouldbe 11mo ago
Not a joke. If truly you want a properly functioning website for blind/bad sight/ Step 1 would probably be to put on a blindfold and go through your website with a screenreader (cmd + f5 on a mac).
- simonw 11mo ago
  Here are notes from last time I tried that: https://tools.simonwillison.net/aria-live-regions https://tools.simonwillison.net/aria-live-regions It's not something I'm comfortable enough with to do on a regular basis though.
  - wouldbecouldbe 11mo ago
    yeah its a real challenge, but probably the only way to really understand it. It's a completely different way of using the web. GPT can really help understand it while doing it.
- ErroneousBosh 11mo ago
  I would very much like to be better at building websites that handle assistive technologies like screen readers well. I don't have a lot of blind users to worry about because they don't let you be a firefighter if you're blind. But a lot of firefighters are people who simply did not do well in school, even the very senior ones, and that's because they are often very clever people who are of an age where things like dyslexia were just not diagnosed early or often. So now I deal with a lot of people who use assistive technologies to help with dyslexia and related comorbidities. I have dyscalculia that wasn't diagnosed until I was 19 and at uni, and even then it was diagnosed initially by my mate's Educational Psychology undergrad girlfriend in the pub one evening. That was in the early 90s and we're better at it now - but not by much.
  - wouldbecouldbe 11mo ago
    Yeah i don't think it's worth doing for every web app. But I do think it's fair that for instance government websites try to meet these criteria.
api 11mo ago
What about just AI assisted accessibility? Like stop requiring apps to do anything at all. The AI visually parses the app UI for the user, explains it, and interacts. Accessible is an also-have at best for the vast majority of software. This would open a lot more software to blind users than is currently available.
- simonw 11mo ago
  That's expensive, slow (listen to a screenreader user some time to see how quickly they operate) and likely only works online. I'm also not going to shirk my responsibilities as a developer based on a hope that the assistive tech will improve.
  - api 11mo ago
    It’s expensive for now, slow for now, online for now, but it’s pretty clear that this is the future. If I were blind I’d want it to go here since it would just unlock so much more. Very little software or sites have good accessibility. Open source and indie stuff often has none. A custom local model trained only for this task seems like a possibility, and could be way smaller than some general purpose model being instructed for this task. I’m thinking screen reader and UI assist only. Could probably be like a 7B quantized model. Maybe smaller.
jillesvangurp 11mo ago
A more viable path might actually be agentic testing via agents that simply use a browser or screen reader that can work off high level test scenarios. I've done some UI testing via the agent mode in chat gpt and I got some pretty decent feedback out of that. I've been trying to do more of that. Accessibility testing might require a bit more additional tooling than comes with chat gpt by default. But otherwise, this could work.
klysm 11mo ago
There might be a great use case here, but the economics make me nervous. Don't the same problems apply here for why we don't have great accessibility? Who is paying for it? How do I justify the investment (AI or not) to management?
Moto7451 11mo ago
I’m doing a PoC at work with Workback.ai, which is essentially what you’re asking about. So far it’s early but it seems ok at first brush. We have a firm we pay for traditional accessibility assessments, remediation, and VPATs and my expectation is that the AI tooling does not replace them due to how business needs and product design interact with accessibility. I.e. ChatGPT and Cursor can probably remediate adding screen reader support for a solving a Captia for the blind, but do you want to really do that? There’s likely a better design for the blind. Either way, I agree. This is a big area where there can be real impact in the industry. So far we’ve gotten scans back in record time compared to human in the loop scans.
westont5 11mo ago
The agent-driving-a-screenreader footgun is that it's quite easy to build UI that creates a reasonable screereader UX, but unintentionally creates accessibility barriers for other assistive technologies, like voice control. Ex: a search control is built as <div aria-label="Search"><input type="search"/></div>. An agent driving a screenreader is trying to accomplish a goal that requires search. Perhaps it tries using Tab to explore, in which case it will hear "Search, edit blank" when the input is focused. Great! It moves on. But voice control users can't say "click Search". That only works if "Search" is in the control's accessible name, which is still blank, the outer div's aria-label has no effect on components it wraps. Would an agent catch that nuance? Would you? You could realign to "I want to know if my features work for screenreader, voice control, switch, keyboard, mobile keyboard [...] users", but you can imagine the inverse, where an improvement to the voice control UX unintentionally degrades the screenreader UX. Accessibility is full of these tensions, I worry an multi-agent approach would result in either the agents or you getting bogged down by them. I think a solution needs to incorporate some heuristics, if you consider WCAG a heuristic. For all its faults, a lot of thought went into rules that balance the tensions reasonably well. I used to be more of the "forget WCAG, just show me the UX" attitude, but over the years I've come to appreciate the baseline it sets. To the example above, 2.5.3 Label in Name clearly guides you towards setting an accessible name (not description) on the search itself, patching up support for screenreaders and voice control. Not that WCAG concerns itself with the details of ARIA (it packs all that complexity into the vague "accessibility supported"[1]). We do need more seamless ways of quickly evaluating whether ARIA or whatever markup pattern has the intended rendering in screen readers, voice control, etc, but at a level that's already constrained. In the example, WCAG should apply its constraints first. Only then should we start running real screen readers and analyzing their audio, and to avoid the footguns that analysis should be at a low level ("does the audio rendering of this control reasonably convey the expected name, state, value, etc?"), not a high level ("does the audio rendering contain the info necessary to move to the next step?"). Unfortunately both agents and heuristic-driven accessibility scanning tools struggle to apply WCAG today. Agents can go deeper than scanners, but they're inconsistent and in my experience really have trouble keeping 55+ high level rules in mind all the time. In the example, an agent would need to use the accessibility tree to accomplish its goal and need to reject a node with label "Search" containing a role=textbox as an option for searching (or at least flag it), which is made trickier by the fact that sometimes it _is_ ok to use container labels to understand context. I think the answer might be to bundle a lot of those concerns into an E2E test framework, have the agent write a test it thinks can accomplish the goal, and enter a debug loop to shake out issues progressively. Ex: if the agent needs to select the search control for the task, and the only allowed selector syntax requires specifying the control's accessible name (i.e. Playwright's getByRole()), will the agent correctly get blocked? And say the control does have an accessible name, but has some ARIA misconfigurations — can the test framework automatically run against some real screenreaders and report an issue that things aren't working as expected? We've done some explorations on the framework side you might be interested in [2]. [1] https://www.w3.org/TR/WCAG22/#dfn-accessibility-supported https://www.w3.org/TR/WCAG22/#dfn-accessibility-supported [2] https://assistivlabs.com/articles/automating-screen-readers-for-accessibility-testing https://assistivlabs.com/articles/automating-screen-readers-...

i-con 11mo ago

No CSS is better than bad CSS In my browser that "Page Contents" box is hovering above the end of the line, so I can't read the full text. Kind of ironic, that this is on w3.org

the_other 11mo ago
> No CSS is better than bad CSS That's only true if the markup and JS are also good. If, for sake of argument, the HTML had been badly authored such that the links in that menu were DIVs with click event handlers, rather than real links, then removing CSS would likely make the experience worse rather than better. I guess that a key point underpinning your comment is that progressive enhancement is still better than assuming all potential users are on the bleeding edge, despite the evergreen update pattern for the most popular 3 or 4 browsers.
account42 11mo ago
What browser is that?
- i-con 11mo ago
  Tested with WebKit and Gecko. Apparently the position gets fixed up at runtime if JavaScript is enabled. But why have dynamic elements with CSS if you need JavaScript to fix it?
  - account42 11mo ago
    Ok yeah that's really weird. It uses javascript to unconditionally add the has-sidebar class to <body>. Maybe a limitation of their templating system but that's not really an excuse.

gampleman 11mo ago

Is this really true? Messaging like this will cause a lot of developers to just give up. Most places I've worked at did accessibility at best as a best effort sort of thing. After reading this, there will be no attempts made to improve the state of affairs. Perhaps that will be an improvement? I don't know.

askew 11mo ago
The statement is about encouraging folks to use the platform: `<button>Hello!</button>` over `<div role=button tabindex=0>Hello</div>`
austin-cheney 11mo ago
ARIA is often a compensating technology more than a primary solution. I try to not use ARIA in my own code aside from the role attribute. I instead rely on the clear navigation and order HTML content and events as my primary solutions.
- no_wizard 11mo ago
  Using the right elements (like button instead of a div) will take you very, very, very fair with little to no additional work.
  - tracker1 11mo ago
    +1 here... <button> vs <a> in particular... if it's programmatic behavior, use a styled button if you want it to look like a link, and vice-versa for navigation behaviors. I will add that a good component library should also handle some of this for you... in particular menu navigation, popouts/drawers etc. That said, can't say how many sites/apps have really broken behavior with this.
nabla9 11mo ago
It is true. This is not messaging. They are not selling you ARIA. If you are developer, just write semantically clear HTML instead. Just doing something is worse than doing nothing in accessibility.

hamonrye 11mo ago

[dead]

Bengalilol 11mo ago

2 cents here. Let's make this article optimistic and forward looking. That's somehow intriguing to write an article that says "no" without providing "yes" examples. I don't view this as very generous. Looking for further updates.

dnrvs 11mo ago
This is the "Read Me First" page on a site absolutely full of documentation...
throawayonthe 11mo ago
the rest of this website section is exactly that: https://www.w3.org/WAI/ARIA/apg/practices/ https://www.w3.org/WAI/ARIA/apg/practices/ and generally: https://www.w3.org/WAI/ARIA/apg/ https://www.w3.org/WAI/ARIA/apg/

emsixteen 11mo ago

I think it would be very beneficial if the browser vendors, together with screenreader vendors and those who use them, were able to come together to actually unify the approach to how elements/these attributes/etc. are communicated to the end user.

pickpuck 11mo ago
They're working on it in the "Core Accessibility API Mappings" spec https://www.w3.org/TR/core-aam-1.2/ https://www.w3.org/TR/core-aam-1.2/
gostsamo 11mo ago
this part is covered. the issue are the web devs who need or decide that they need to repurpose a set of elements into another set of elements and skip informing the non visual user about that.

draw_down 11mo ago

[dead]

tonyhart7 11mo ago

this is why I don't bother with ARIA

notpachet 11mo ago

This is also true of alt text for images. I'm active on Bluesky, and so often I see an image with an "ALT" tag (meaning that the user has specified alt text for the image) only for it to be some meaningless offhand bullshit like "lmao i guess i showed them". Pisses me off.

diegolas 11mo ago
people've been confusing the title and alt tags since like IE4

jillesvangurp 11mo ago

I've looked a few times at this space. Most of the documentation seems to devolve into a depth first deep dive into here's a bunch of tags and attributes without laying out a coherent goal of what you should be doing. My observations: - most web developers have never seen a screen reader version of their application; or any application. - most teams don't have visually handicapped people that use a screen reader that could provide feedback - so, no bugs ever get reported regarding accessibility That is, unless developers go out of their way to use proper tools and do proper testing for this. And testing practices for Aria probably is at the same level as it is for other application features: sketchy to non existent at best. Let's face it, mostly Aria is pure box ticking for developers. There has to be some (regulations, and PMs insisting because of that). But it doesn't have to be good since nobody really checks these things. Including the PM. Without a feedback loop, it's not surprising that most web apps don't get this even close to right. IMHO, over time, agentic tools might actually be more helpful to blind people as they can summarize, describe, and abstract what's on the screen. Agentic testing via a screen reader might also become a thing. I've done some testing via the agent mode in chat gpt and it was shockingly good at figuring out our UI. Not a bad process for automating what used to be manual QA. I've been meaning to put more time in this. I actually have as a very low priority target to start driving some of this in our own application. Mostly that's just a hunch it might come up because of some government customers. But this is Germany and they seem to have lots of blind spots on software quality. I don't actually expect any feedback whatsoever from actual customers or anyone on this. I just want to pre-empt that.

scroot 11mo ago
For those of us in civic tech, this is a higher priority. At the federal level especially, there are laws on the books about website accessibility compliance -- even if, at present, the powers that be are ignoring them. I have found the Web Content Accessibility Guidelines [1] to be especially useful when thinking through what I need to implement and why. It is _impossible_ to thoroughly test any of your accessibility concerns only with automated tooling. You will need to have an experienced user of screenreaders go through your site, especially if it contains complex JS enabled controls and other dynamic updates. This is because the habits of individual users and the combination of a particular screenreader application / browser can often produce different results. It's important to know what the common "patterns of use" are for, say, a JAWS user vs a VoiceOver user. Last thing I'll recommend is that if you are testing a11y yourself on a Mac using VoiceOver, do all your a11y testing in Safari. In our research, most VO users on Macs/iOS use Safari because it has the best screenreader integration on that platform, and other browsers miss basic things. [1] https://www.w3.org/WAI/standards-guidelines/wcag/ https://www.w3.org/WAI/standards-guidelines/wcag/

deleted 11mo ago

[deleted]

londons_explore 11mo ago

The future of accessibility is AI agents. Ie. Don't make the web page accessible to some ancient screen reader software - instead make sure AI agents can interact with it so the real user can instruct the AI to perform the task on their behalf.

the_other 11mo ago
How does the user know what the page is capable of in order to be able to instruct the agent?

wccrawford 11mo ago

No examples are better than no examples. They really needed to show what the proper way to implement those scenarios was, as well as the proper way to use those aria properties. As it stands, they look good, and someone that isn't paying attention is going to think they're correct and use them.

wccrawford 11mo ago
Oops. I mean "than bad examples". Guess I should have proofread, huh?

sapphirebreeze 11mo ago

MMMKAY?

daveguy 11mo ago

Since the acronym is not defined anywhere in the link: ARIA = Accessible Rich Internet Applications Part of the W3 consortium's Web Accessibility Initiative. https://en.wikipedia.org/wiki/WAI-ARIA https://en.wikipedia.org/wiki/WAI-ARIA

burningChrome 11mo ago

Interesting as a developer coming into accessibility, I was repeatedly told, "The first rule of ARIA is not to use ARIA." It feels like we've gone so far away from semantical code that ARIA is now being used a crutch to replace semantical approaches to coding.

tracker1 11mo ago
Can't +1 this enough... I've found that in practice, outside of images, menu pop/flyout and dialogs/trays, there really isn't too much need for additional aria attributes. Most component libraries should already be configured out of the box imo. ARIA should only be needed relatively sparingly assuming you're using appropriate semantic elements. Testing with keyboard only navigation can reveal a lot as well. Related, and one I experience a lot are issues on mobile devices with text/display cranked up... too many modal interactions with buttons off-screen.

codelikeawolf 11mo ago

As someone who has spent a lot of time trying to gain a11y expertise and learn best practices, this messaging drives me a little bonkers. There is so much inaccessible content on the web. The official ARIA guide tells you "you're better off doing nothing". All of the example patterns in the ARIA Practices Guide (APG) tell you the code isn't for production use [1]. They provide an explanation which points back to..."you're better off doing nothing". When I need to add a toolbar to my app, and I want it to be accessible. I look at the APG, the APG has a toolbar example with markup, CSS, and JS, but apparently I'm not supposed to use it. I've been at this for years and it's incredibly frustrating. I usually use the APG code in production anyways. It's probably not catastrophically wrong, but it always makes me feel like I'm screwing something up. The alternative is to use a bunch of divs, spans, and buttons because not all of the patterns have semantic HTML equivalents. [1] https://www.w3.org/WAI/ARIA/apg/patterns/grid/examples/layout-grids/#support-notice-header https://www.w3.org/WAI/ARIA/apg/patterns/grid/examples/layou...