Speaking of WebAccessibilityFails, the article overflows to the left without a scrollbar when viewed on a phone narrower than an iPhone, making the first word of every line unreadable (and there are a lot of lines on a phone narrower than an iPhone).
This is caused by using CSS grid with "minmax(auto, 57rem)" and an overflowing table. It can be fixed with adding "safe" to "justify-content: safe center" that is defined on main.
I keep my browser zoomed in substantially to compensate for uncorrectable vision issues. I’d say perhaps once per day I’ll encounter a website that has never had zoom in/out (ctl +/-) tested because if you zoom up even one level from 100%, everything breaks.
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.
> I’d say perhaps once per day I’ll encounter a website that has never had zoom in/out (ctl +/-) tested because if you zoom up even one level from 100%, everything breaks
How does it break for you? Seems OK to me on android — in fact, I already had it at 110%. Reminded me to check my desktop settings which have HN fixed at 125%. I cannot believe that, in 2026, the default font size is set at 12px — is anyone actually reading it at that size?!
While web accessibility is important and something we should be investing in, I do feel that the vendors of accessibility tools are somewhat to blame here in how friggin difficult it is to actually make something accessible. Quirks and features are wildly inconsistent across tools, and feature uptake is much slower than it should be. For example, creating an accessible dialog shouldn’t be a multi-page essay to explain, it should just be “use the <dialog> element.” - but the a11y tools are so inconsistent that you can’t just do the standards compliant thing. And don’t get me started on roving tabindex techniques (for things like data tables), which are at best an ugly hack that the entire industry has collectively decided “eh, it’s good enough”.
No one has done more damage to web accessibility than the web accessibility industry. Arcane rules like this make any sane developer throw up their hands in disgust.
I think the accessibility consultants like this state of affairs: they can threaten more lawsuits and extract more in consulting fees.
Avoid aria tags. The spec is unworkable (see this document) the browsers made by the disability industry extract vast quantities of money from disabled people with little effectiveness because they try and boil the ocean which unsurprisingly is ineffective.
Support efforts for computer vision based browsers, MCP and APIs.
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.
Two days ago, in https://news.ycombinator.com/item?id=48248285 I commented on exactly this thing, a <dl aria-label=…> (dl has “no corresponding role”).
Speaking of WebAccessibilityFails, the article overflows to the left without a scrollbar when viewed on a phone narrower than an iPhone, making the first word of every line unreadable (and there are a lot of lines on a phone narrower than an iPhone).
This is caused by using CSS grid with "minmax(auto, 57rem)" and an overflowing table. It can be fixed with adding "safe" to "justify-content: safe center" that is defined on main.
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...
I keep my browser zoomed in substantially to compensate for uncorrectable vision issues. I’d say perhaps once per day I’ll encounter a website that has never had zoom in/out (ctl +/-) tested because if you zoom up even one level from 100%, everything breaks.
There are several equally useless failure modes I’ve seen with this, a few off the top of my head:
Certain websites are impossible for me to use and I just avoid them.> I’d say perhaps once per day I’ll encounter a website that has never had zoom in/out (ctl +/-) tested because if you zoom up even one level from 100%, everything breaks
Just tested, hn breaks if you zoom >110%.
How does it break for you? Seems OK to me on android — in fact, I already had it at 110%. Reminded me to check my desktop settings which have HN fixed at 125%. I cannot believe that, in 2026, the default font size is set at 12px — is anyone actually reading it at that size?!
Which platform is this on? I usually read hn on a desktop browser, and it works fine well above 110% there.
The irony of a tool designed to enforce usability and discoverability that which itself is unusable and undiscoverable.
Left part of the page is cut off and only accessible with reader mode on IronFox for Android. Talk about #WebAccessibilityFails
Zoom bug reading this article. Perhaps it's just my Firefox?
Still, a nice concise read if you can get it
While web accessibility is important and something we should be investing in, I do feel that the vendors of accessibility tools are somewhat to blame here in how friggin difficult it is to actually make something accessible. Quirks and features are wildly inconsistent across tools, and feature uptake is much slower than it should be. For example, creating an accessible dialog shouldn’t be a multi-page essay to explain, it should just be “use the <dialog> element.” - but the a11y tools are so inconsistent that you can’t just do the standards compliant thing. And don’t get me started on roving tabindex techniques (for things like data tables), which are at best an ugly hack that the entire industry has collectively decided “eh, it’s good enough”.
today i learned there are browser built-in popovers now.
No one has done more damage to web accessibility than the web accessibility industry. Arcane rules like this make any sane developer throw up their hands in disgust.
I think the accessibility consultants like this state of affairs: they can threaten more lawsuits and extract more in consulting fees.
Avoid aria tags. The spec is unworkable (see this document) the browsers made by the disability industry extract vast quantities of money from disabled people with little effectiveness because they try and boil the ocean which unsurprisingly is ineffective.
Support efforts for computer vision based browsers, MCP and APIs.
> MCP
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.
What document?
Do you have any sources to back these claims up?