There are several equally useless failure modes I’ve seen with this, a few off the top of my head:
- rendering fails, everything falls apart
- some elements disappear
- it drops into the feature-limited mobile view
- the author or framework overrides zoom with some other behavior — this one makes me especially crazy because they had to do *extra work* to screw up accessibility
Certain websites are impossible for me to use and I just avoid them.It sucks, and arguably has the opposite effect, but this came from the same people who thought cookie banners were a good solution to anything, so ... what did we expect?
Still, a nice concise read if you can get it
Even what's described in the article basically boils down to "You can label things, but not generic things (for some reason?), unless that generic thing is a <section> or has a popover attr in which case it magically works." And this isn't even one of the "hard" accessibility things!
I think the accessibility consultants like this state of affairs: they can threaten more lawsuits and extract more in consulting fees.
Support efforts for computer vision based browsers, MCP and APIs.
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...
My personal gripe is their refusal to support restarting heading levels within sections, causing whole classes of problems with CMS templating.
I think there is truth in this. A lot of the assistive technology (AT) vendors, also sell consultancy.
Go to the Vispero career pages (who develop JAWS for Windows) and a big chunk of the jobs are remote consultancy roles advising clients on accessibility errors and selling for billable hours.
What makes a web page accessible? Why, it has to work with JAWS, of course!
Vispero makes a lot of money from this; the consultants are all in India, the clients are all in the West, so they can hoover up the difference. I get the impression most AT vendors are extremely cheap, which may explain why it takes decades for them to improve things
Respectfully screw making users rely on AI for accessibility. Just make the damn page accessible already. Actually, more like make sure you don't break the accessibility that's there by default with correctly written plain HTML.
It's way way simpler than, say, var hoisting in JavaScript.
Do you have any sources to back these claims up?
Just tested, hn breaks if you zoom >110%.
Yes you just need every website to use it, rather than fixing the client. Which is the 'boil the ocean' strategy mentioned in the comment you're replying to.
> ARIA can help when devs want to use the wrong elements for some reason or for custom controls.
But it can't. See this article.
Why? It's the right tool for the job.
> Just make the damn page accessible already.
Oh so just modify every website and expect the disabled people to wait while this happens?
This disabled web browser industry doesn't care about disabled people. Their solutions don't work, disabled browsers are expensive because government grants are given to purchase them.
Not be able to aria-label anything and have the screen reader say ok I take that in priority seems badly thought out.
Also - screenreaders could have a setting to read aria-label on divs and then read the content if the user wanted it. If the user determined the labels on divs were inadequate, they would flip this setting, if they decided this seems to be working well they would just go with what the site does.
https://news.ycombinator.com/item?id=48237159
> Do you have any sources to back these claims up?
Yes, asides from the article, check the prices of browsers from the disability industry and consider for yourself whether it's logically easier to fix every website or make a client that can adapt existing webpages.
I think that is the up until about 2020 way, the modern way is using clamp to do it
https://css-tricks.com/linearly-scale-font-size-with-css-cla...
It took until 2023 to support nesting, something that was so obvious that preprocessors have had it since at least 2006.
1080px wide (aka on my vertical monitor) HN comments stop reflowing > 300%
At 1920px wide it never stops reflowing.
See specifically https://www.w3.org/WAI/ARIA/apg/practices/names-and-descript... for details on naming. That has extensive notes and details for labeling elements correctly.
See https://getbootstrap.com/docs/5.0/components/ for bootstrap markup on creating accessible components.
There are plenty of other resources.
As a developer, however, get your shit fixed! And that fixing doesn't involve any MCP. Don't expect visitors to run AI...
No, it's not. Why should disabled users be forced to indirectly interact with a webpage via a non-deterministic agent, rather than directly interact with one that's specifically designed to accommodate them?
You don't need to pay for a specialist browser as all web browsers (Firefox, Chrome, Edge, Safari, etc.) will implement the native accessibility model of the operating system they are running on (IAccessible/MSAA for Windows, etc.).
In Firefox you can press the right mouse button and select "Inspect Accessibility Properties" or select the "Accessibility" tab from the developer window and it will show the accessibility tree (roles, states, properties, etc.) just like the DOM tree in the "Inspect" tab. That is what the browser is displaying to screen readers and other accessibility software and uses the behaviour of the HTML elements along with the ARIA roles/states/properties defined by the webpage to construct that tree. Thus, it will display an ol/ul as a `role=list` unless overridden to be e.g. a `tablist` by the website.
See https://www.w3.org/TR/wai-aria-implementation/ for a specification on how browsers should implement HTML and ARIA to different operating system accessibility APIs.
Not all accessibility tools are expensive:
- NVDA is free and open source
- Narrator is included with windows
- Voiceover is included with macOS and iOS
- Orca is free and open source.
- Talkback comes with Android
- Chromevox comes with Chrome OSThe very first "quality of life" thing I do when I install a new computer / operating system nowadays is double (sometimes triple) the default font size. 12pt was probably fine when our monitors were 640x480, and when we were 18 years old.
Because a world where that happens consistently doesn't exist, it hasn't existed for the last 20 years we've been using ARIA tags, and won't ever exist.
I think we might need a little more information than just the OS to differentiate.
1. A robust set of web primitives that are accessible by default, and
2. A government that will actually enforce laws (which already exist!) requiring websites to be accessible
As mentioned ARIA has had 20 years before by Hakcer News post. It will continue to fail with out without me.
posted on 22.05.2026
This post is part of a series called #WebAccessibilityFails, where I collect common issues I find in accessibility audits so that you can avoid them in the future.
The title already tells most of the story, but here's why you must avoid labeling generic elements like divs or spans using aria-label or aria-labelledby.
<div aria-label="News">
…
</div>
Don't do this
Looking at the ARIA spec, you'll find section "5.2.8.6 Roles which cannot be named (Name prohibited)". It lists all roles that cannot be named. It includes “generic”, which is the default role of divs and spans.
captioncodedeletionemphasisgenericinsertionparagraphpresentationstrongsubscriptsuperscriptSo, in theory, it's not allowed, but there is also a practical reason to avoid it. Browsers treat labeled generic elements very differently. Below you'll find the results for the following three elements I tested. The results were the same for every element. I've used the arrow keys on desktop and swipe on mobile to navigate.
<div aria-label="News">Content</div>
<p>
Some inline <span aria-label="News">content</span>
</p>
<ge-neric aria-label="News">
Content
</ge-neric>
VoiceOver in Safari on macOS announces “News, group“, Talkback in Chrome on Android “News“, and Narrator on Windows 11 with Chrome "News, group, content". All the other tested screen readers ignore the author-defined label completely and announce the text content.
Results from testing labeled generic containers
| Screen Reader | Browser | Announcement |
|---|---|---|
| VoiceOver macOS | Safari 26.3.1 | News, group |
| VoiceOver iOS | Safari 26.3 | Content |
| Talkback Android | Chrome 148 | News |
| Talkback Android | Firefox 150 | Content |
| Jaws 2026 Windows 11 | Chrome 148 | Content |
| NVDA 2026.1.1 Windows 11 | Chrome 148 | Content |
| NVDA 2026.1.1 Windows 11 | Firefox 150 | Content |
| Narrator, Windows 11 | Chrome 148 | News, group, content |
Update: Verena made me aware that results may differ if the element is empty. So, I tested that as well. I tested both an empty div with 0 width and height, and one that takes up space. There was no announcement in VoiceOver on iOS, JAWS and Narrator in Chrome, or Talkback in Firefox.
<div aria-label="News" style="width:100px; height:100px"></div>
<div aria-label="News"></div>
Results from testing empty labeled generic elements
| Screen Reader | Browser | Announcement |
|---|---|---|
| VoiceOver macOS | Safari 26.3.1 | News, empty group |
| VoiceOver iOS | Safari 26.3 | None |
| Talkback Android | Chrome 148 | News |
| Talkback Android | Firefox 150 | None |
| Jaws 2026 Windows 11 | Chrome 148 | None |
| NVDA 2026.1.1 Windows 11 | Chrome 148 | News |
| NVDA 2026.1.1 Windows 11 | Firefox 150 | News |
| Narrator, Windows 11 | Chrome 148 | None |
Of course, there are exceptions because otherwise it would be too easy. Honestly, I don't know all of them, but from the top of my head, I can think of two.
The section element has a generic role by default. If you put aria-label or aria-labelledby on the element, its implicit role changes from generic to region, turning it into a landmark. It's fine to label sections if it helps your users.
<section aria-label="News">
…
</section>
If you put the popover attribute on a div, its implicit role changes to group. So, if you label it –I'm not saying that you should – you're technically labeling a group and not a generic element, which is fine.
<div popover aria-label="I'm not sure how useful a label here is">
</div>
Update 25.05.26: Added more tests.