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).
jnovek 6 hours ago [-]
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.
Joker_vD 3 hours ago [-]
I remember seeing a website that had <html style="font-size: XXX%"> for the top-level element, and had JS that would dynamically recalculate that percentage on every resize event to keep the visual font size almost (exactly) constant. Made me think for a moment that my mouse wheel broke.
jandrese 2 hours ago [-]
One of my pet peeves in the modern web is when someone displays an image and scales it to exactly the size of your screen, but I want to look more closely at a part of the image so I do a scrollwheel zoom, only for the image to actually shrink as every UI element except the thing I want gets bigger. And then you go "ok, right click on the image and do the "Open Image in new tab" thing and somehow the site defeats that and puts all of their UI crap in the new tab as well.
masfuerte 3 hours ago [-]
The modern version is to use @media to achieve the same annoying effect without js. Fortunately, there's a finite number of rules so I've found that if you zoom far enough the text does actually start getting larger. Though I expect that someone's already figured out how to use CSS Math to keep text tiny at all zoom levels.
bryanrasmussen 3 hours ago [-]
>The modern version is to use @media to achieve the same annoying effect without js.
I think that is the up until about 2020 way, the modern way is using clamp to do it
> 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%.
oneeyedpigeon 5 hours ago [-]
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?!
chowells 6 minutes ago [-]
Yeah, 12px is fine (27" 1440p, no display scaling). It is on the small side. I'd go a bit larger for something I made. But it's not a small enough to slow down my reading.
ryandrake 4 hours ago [-]
> I cannot believe that, in 2026, the default font size is set at 12px — is anyone actually reading it at that size?!
The 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.
voidUpdate 4 hours ago [-]
I leave HN on default everything, but I have a 1080p monitor so it might look bigger for me than someone with a higher resolution monitor... I don't know how that works. But I often have to zoom out of websites linked here because the text is so big and it feels uncomfortable to read
pbalau 3 hours ago [-]
For some reason I though the GP was talking about browsing on mobile, where I have the issue:
I use DuckDuckGo Browser, Firefox, and Chrome on Android pretty much in that order of preference. In both mobile mode and desktop mode all of these browsers support pinch zoom and two-finger drag scrolling. I have no problems with this site using those.
I think we might need a little more information than just the OS to differentiate.
jabroni_salad 4 hours ago [-]
I browse everything at 125% and HN is fine on my machine so I decided to check. It depends on your width.
1080px wide (aka on my vertical monitor) HN comments stop reflowing > 300%
At 1920px wide it never stops reflowing.
pbalau 3 hours ago [-]
For some reason I though the GP was talking about browsing on mobile, where I have the issue:
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.
Funny how the problem itself is created by CSS, and the solution is "more CSS." On the other hand, bare HTML tends to be extremely accessible and lacks these kinds of basic problems with panning, zooming, and scrolling.
xigoi 53 minutes ago [-]
Bare HTML is pretty bad for accessibility. For example, you get no maximum width, making websites painful to read in a wide window.
mostlysimilar 36 minutes ago [-]
Windows are resizable. Built-in width selection!
xigoi 20 minutes ago [-]
You can’t set a different size per site. More width is better for sites that have sidebars and stuff.
bobthepanda 2 hours ago [-]
CSS is this weird thing where it has dominance as a layout engine because it is so battle tested compared to a lot of other layout engines, but was clearly designed by a committee that could give a rat’s ass about how ergonomic it is to use.
It took until 2023 to support nesting, something that was so obvious that preprocessors have had it since at least 2006.
kid64 3 hours ago [-]
The most infuriating case I've seen within the last few days is the Airbnb CAPTCHA, which relies on the user being able to see content that is blocked at zoom levels over 100%. They have an alternative audio option that they've clearly never tested; it always reports failure, even if the CAPTCHA was solved correctly. Unthinkable for an organization with their resources.
pimlottc 12 minutes ago [-]
So what's the correction solution for something like this, and what's the desired voiceover?
injidup 6 hours ago [-]
The irony of a tool designed to enforce usability and discoverability that which itself is unusable and undiscoverable.
542458 6 hours ago [-]
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”.
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!
karlshea 4 hours ago [-]
This is spot on. They are ripe for getting entirely wiped out by AI, and good riddance tbh.
My personal gripe is their refusal to support restarting heading levels within sections, causing whole classes of problems with CMS templating.
jugglinmike 3 hours ago [-]
ARIA-AT is a W3C Community Group (of which I'm a member) trying to address this problem: https://aria-at.w3.org/about
jbreckmckye 2 hours ago [-]
Why would they want to improve their tools? In many cases (Vispero), they're the ones selling accessibility consultancy
goda90 6 hours ago [-]
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
jrochkind1 5 hours ago [-]
today i learned there are browser built-in popovers now.
karlshea 4 hours ago [-]
Those have been there for a bit, what is more recent is CSS anchor positioning which lets you position the popover near the item that triggered it. It’s all finally very nice!
DocTomoe 2 hours ago [-]
Ever since the EU has started to mandate web accessibility compliance - without defining what exactly needs to be done to be compliant, the only safe, lawyer-resistant way is to put aria-labels on absolutely everything.
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?
micromacrofoot 3 hours ago [-]
it's fine as long as you add an appropriate role
recursivedoubts 6 hours ago [-]
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.
jbreckmckye 2 hours ago [-]
> I think the accessibility consultants like this state of affairs: they can threaten more lawsuits and extract more in consulting fees.
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
micromacrofoot 3 hours ago [-]
It's not really arcane, a div is meaningless because it's simply a container. If you want it to have meaning you can't just add a label. If I put the word "button" on a rock, it doesn't make it a button. That's the same story here.
nostats 4 hours ago [-]
Is this an arcane rule? "Don't label divs" and "aria-label is for when there's no content in the DOM that can be read" are pretty simple rules. Labels are ways to tell a screen reader about content it can't read, like an image or icon. Pretty straightforward.
It's way way simpler than, say, var hoisting in JavaScript.
bryanrasmussen 2 hours ago [-]
it's a somewhat stupid rule. People process information differently visually than they do via aural methods. If you have a reason why something should not be read by a screen reader, because say the order you would be reading it makes sense visually but not at all aurally, then you have to jump through hoops to visually hide the aural content, and then aria-hide the visual content, and there may be more complicated things dependent on button position etc.
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.
htx80nerd 3 hours ago [-]
why is this even a post - this is common sense not 'hacker news'
nailer 6 hours ago [-]
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.
jraph 5 hours ago [-]
> 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.
nailer 2 hours ago [-]
> Respectfully screw making users rely on AI for accessibility.
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.
jakelazaroff 2 hours ago [-]
> Why? It's the right tool for the job.
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?
nailer 1 hours ago [-]
> rather than directly interact with one that's specifically designed to accommodate them?
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.
jakelazaroff 7 minutes ago [-]
Your advice to "avoid aria tags" would make that a self-fulfilling prophecy. The ways to make it happen:
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
jraph 2 hours ago [-]
For a user running into broken pages, sure, you have to compose with what you have.
As a developer, however, get your shit fixed! And that fixing doesn't involve any MCP. Don't expect visitors to run AI...
RobMurray 3 hours ago [-]
To hell with using vision based AI for web accessibility. it really isn't that hard to get right. Semantic html is already accessible. ARIA can help when devs want to use the wrong elements for some reason or for custom controls.
nailer 2 hours ago [-]
> it really isn't that hard to get right.
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.
I did read the article. Why do you need to label a div? It's just a container, not a semantic element. If you really want to use a div for something semantic you can set role and aria-label. That is done all the time and works with screen readers.
> 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.
rhdunn 50 minutes ago [-]
NVDA is a free screen reader for Windows (written by blind devs) that works with Firefox and Chrome.
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.
Clients can't automatically fix all existing web pages, because the semantic information just isn't there. AI doesn't excuse web developers. It wouldn't even be a fix. Who wants to wait for an AI agent for each interaction?
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 OS
Rendered at 18:17:14 GMT+0000 (Coordinated Universal Time) with Vercel.
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 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...
Just tested, hn breaks if you zoom >110%.
The 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.
https://imgbox.com/EiovsE5b https://imgbox.com/A4Fl9lE9
https://imgbox.com/EiovsE5b https://imgbox.com/A4Fl9lE9
I think we might need a little more information than just the OS to differentiate.
1080px wide (aka on my vertical monitor) HN comments stop reflowing > 300%
At 1920px wide it never stops reflowing.
https://imgbox.com/EiovsE5b https://imgbox.com/A4Fl9lE9
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...
It took until 2023 to support nesting, something that was so obvious that preprocessors have had it since at least 2006.
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!
My personal gripe is their refusal to support restarting heading levels within sections, causing whole classes of problems with CMS templating.
Still, a nice concise read if you can get it
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?
I think the accessibility consultants like this state of affairs: they can threaten more lawsuits and extract more in consulting fees.
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
It's way way simpler than, say, var hoisting in JavaScript.
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.
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.
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.
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?
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.
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 a developer, however, get your shit fixed! And that fixing doesn't involve any MCP. Don't expect visitors to run AI...
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.
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.
Do you have any sources to back these claims up?
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.
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: