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).
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 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.
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.
I figure there must be an extension to handle these problems, I googled and the AI gave me a bunch of helpful answers, which all happened to be Chrome extensions despite me using FF. hmmm. It did also say it could help me find FF extensions if I really wanted them, but there seems to be some shenanigans going on here.
Anyway, an extension should solve it.
A propos image tricks sites pull, I've noticed before the right click for images don't work at all in Instagram web, I wonder how they do that, probably background on a div.
In my experience, the reader mode works perfectly fine for sites like that (it worked for that one site I mentioned in my original comment as well) both in Chrome and Firefox.
i think firefox shows the "open image in new tab" for backgrounds also, now. at least sometimes. still easily defeated by putting an invisible div above it so no right clicks reach it... or do some js bullshit to disable right clicks...
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.
Six years is getting long in the tooth. Isn't it about time to upend everything once again and invent another cascading wheel that trades old, familiar edge cases for new, unfamiliar edge cases?
clamp is superior to @media because it solves a common problem with @media, although I am more apt to consider that problem in relation to proportions of divs and margins given the needs of responsiveness.
Indeed I'm not sure what edge case I might expect to find given the ability of using clamp in conjunction with @media.
> 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?!
> 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.
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
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.
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.
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.
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.
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.
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!
I don't know what accessibility tools you're thinking of. If you mean assistive technology software like screen readers and voice control, yes, too often they fail to do what they should even when web standards are followed but at least as often the fault is with the web browsers (assuming the page code is all technically correct).
I'm not aware of any accessibility reasons to not simply use a <dialog> element for dialogs. For it to be a modal dialog, it must be opened using the `.showModal()` method or the invoker command `command="show-modal"`.
The hack of needing to implement roving tabindex techniques is not due to the failings of accessibility tools but because of web standards have not yet provided an alternative (adding the `focusgroup` attribute to the HTML standard is in the works).
I was wondering that too. They explained the differences between the tools but didn't really qualify which was doing things "right" just that they differed.
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!
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?
They have defined what exactly needs to be done to be compliant, it's basically "meet WCAG 2.1 Level AA" with some additions. WCAG has already been the de facto standard for decades.
I assume you have not read Directive 2016/2102 and/or EN 301 549, because your approach is nice and so very, very, very suable.
The issue is not accessibility itself. I'm all for making things simpler. The issue is that the EU framework combines broad principles, partial technical references, vague proportionality requirements, and evolving judicial interpretation. In practice, that means the exact compliance boundary is often only defined by a judge during litigation, and with the website operator funding the clarification process through lawyer and court fees.
That is precisely the kind of legal environment that creates serial-litigation ecosystems like the ADA lawsuit industry in the US.
With systems becoming increasingly more complex, testing all potential code paths increases effort exponentially. With content being user-generated, not necessarily system-generated, you now technically need an editorial watchdog position that greenlights every change (if only to prevent Sally from Sales to post a meme in copy without a proper alt text, or worse, an infographic, without a wall of text describing the infographic in great detail).
And for the attacker, they only need to find one case of violation - while you need to be correct 100% of the time.
The only two ways to migitate such issues are
1. do not offer the service in Europe at all and actively prevent EUians from acessing any part of them - which becomes increasingly attractive (disclaimer: I am an EUian, unfortunately),
2. implement defensive overcompliance far beyond practical usability requirements, or
3. accept ongoing legal uncertainty and budget for it accordingly.
Unfortunately, "just build reasonable software and trust common sense" is not a stable legal strategy anymore.
None of that legal complexity has anything to do with putting "aria-labels on absolutely everything."
> And for the attacker, they only need to find one case of violation - while you need to be correct 100% of the time.
I don't know how European regulators work but even in the litigious U.S., this is not true, at least not in the courts. However, for small businesses, which are more likely to be targeted by the trolls, the cost of proceeding far enough to get a suit dismissed is burdensome. And in the EU, I thought individuals couldn't bring cases to a judge, they have to complain to a regulatory body that can decide whether proceeding is warranted or not.
> implement defensive overcompliance far beyond practical usability requirements
This is like complaining about having fewer grams of rat turd in your flour than legally mandated; "Oh no, we made our product too good!"
In practice, building "reasonable software" has never included making it work for people with disabilities, despite WCAG and the web standards themselves existing for decades.
> And in the EU, I thought individuals couldn't bring cases to a judge, they have to complain to a regulatory body that can decide whether proceeding is warranted or not.
EU regulations get made into member state laws, and these vary massively in who can sue through what way.
In Germany, for example, a common enforcement vector is the "Abmahnung" under unfair competition law. In theory, if a regulation imposes costs on compliant businesses, competitors should not gain an advantage by ignoring it.
The problem is that this has historically created an ecosystem of professional cease-and-desist mills. A competitor (or an organisation acting on their behalf) identifies a violation, sends a lawyer's letter, demands reimbursement of legal costs, and requests a cease-and-desist declaration with contractual penalties for future violations.
Whether the underlying issue is accessibility, consumer protection, labeling requirements, privacy notices, or something else is almost secondary. Once compliance becomes sufficiently complex, the enforcement mechanism itself becomes a business model. The cynic in me can't help but notice that our parliaments are made up disproportionately by lawyers.
That is why many businesses are worried less about accessibility itself and more about legal uncertainty around accessibility requirements. The concern is not "making websites accessible is bad."
The concern is that compliance costs are barely predictable, while litigation risk arising from ambiguous compliance boundaries is not.
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.
> 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 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.
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.
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.
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.
> 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.
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?
> 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.
As you mentioned, without proof. Sorry, but I think you have it completely backward.
ARIA attributes are only one of the tools to help with web page accessibility and are somewhat last resort when you can't do what you aim to do with bare HTML.
The first tool is to not break stuff in the first place.
The solution to "accessibility is not ideal across the world" is certainly not "Outright avoid tagging stuff for accessibility anyway", as if using ARIA attributes were somewhat harmful. It's not, unless you misuse them, and no, the spec isn't unworkable, and you also don't have to use it all.
The response to "software is broken" is not "software has had 50+ years to be bug free, let's put the burden on the users to deal with it since obviously developers can't do bug free".
I feel that claiming the web now consistently complies with ARIA is an incredibly bold claim, and the burden of proof is on you but you can test the top 50 websites yourself if you genuinely believe that.
> are somewhat last resort when you can't do what you aim to do with bare HTML
This thinking was popular 20 years ago when ARIA was created. Application-like behaviour, which nearly always means JS, is the majority of websites.
> ARIA attributes were somewhat harmful
Wasted engineering effort on minimally effective outcomes is harmful.
> "software has had 50+ years to be bug free, let's put the burden on the users to deal with it since obviously developers can't do bug free".
Others not following your religion is not a defect.
> I feel that claiming the web now consistently complies with ARIA is an incredibly bold claim
... that I didn't make
> This thinking was popular 20 years ago when ARIA was created. Application-like behaviour, which nearly always means JS, is the majority of websites.
That's besides the point, your JS code still generates HTML. Writing applications in JS doesn't change anything about the topic.
What I'm saying is that you mostly don't need to use aria attributes with a good HTML structure, generated from JS or not. Use them sparingly when you can do it in pure HTML (again, generated or not).
> Others not following your religion is not a defect.
That's not an answer to the stuff you quoted and there's no religion here.
You have a point about web accessibility lacking but we'll have to disagree about "let's just give up good practice since it's not been perfect despite all these years". Actually, you are not claiming "not perfect", you are claiming "not present", but you're wrong on this as other commenters told you.
> > I feel that claiming the web now consistently complies with ARIA is an incredibly bold claim
> ... that I didn't make
Ok so you agree that the web has not and is unlikely to be ARIA compliant?
But then persist in supporting ARIA despite knowing that goal isn’t and never will be achievable?
That seems exactly like religion.
> you're wrong on this as other commenters told you
As does this. Nobody has refuted the point in the original post that ARIA is a boil the ocean strategy, in face you have just conceded it. What makes you think other commenters disagreeing would change that?
You agree that most programs are bug ridden. But then persist in writing programs despite knowing that goal isn't and never will be achievable?
There are imperfections in any piece of furniture and yet we are still building furniture? How religious!
You sound like this to me.
There's a whole world between "accessible HTML is never achieved anywhere" and "accessible HTML is fully achieved everywhere". As other commenters already told you, we are actually mostly there, there's no complete failure here. Sure, shit's not perfect (far from it, sadly...) but I feel like you are throwing the baby with the bath water.
I'm not willing to increase my electricity bill or spend tokens to make up for your unwillingness to use widely accepted - and mandated by law in many cases! - solutions. I'll just pass and probably others will do as well.
I'll stop here, this is not productive, none of us will likely move from where we stand. Let's just say that you are apparently alone in your position here in this discussion and you have so far failed to convince us. Call that position in which everyone here is except you "religion" all you want. I'll even snarkily risk a tu quoque by emphasizing that AI is no magic dust.
> But then persist in writing programs despite knowing that goal isn't and never will be achievable?
Because, asides from users interacting with less programs than they do websites it’s not possible for a user to systematically fix all the programs they interact with. You are proposing an 0(n) solution instead of an 0(1) solution.
That should be incredibly obvious before this discussion even started, and even more obvious after reading this far in the thread. You’re replying but you’re not paying attention to what you’re reading. I’m not going to bother continue reading or interacting with you any further.
Because ethical issues aside, that's expensive to run, unreliable, non-deterministic hot mess that doesn't have predictable behavior. And predictable behavior is somewhat key.
I won't blame a disabled user seeking AI-based tools to browse the web to survive with what they have, but I will totally blame the devs who created the situation.
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.
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.
You said "see this article" re: how aria-label is not applicable to div elements, hence the second link which is the WAI-ARIA guide on labelling elements.
You also said that ARIA can't help with custom controls in that post, which is where the other links are applicable as they describe doing just that. I.e. using ARIA tags to implement tabs, accordions, etc. either with or without a framework library.
ARIA is a solution to a specific problem, not something that should be used on every site. HTML is accessible out of the box when semantic elements are used as intended. If you are using a div as a button, you probably aren't hand writing HTML. It is likely part of a library. Adding the necessary ARIA attributes benefits every site using the library. Your boiling the ocean analogy implies that every web developer needs to scatter ARIA attributes all over their code, which just isn't true.
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.
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
> Clients can't automatically fix all existing web pages, because the semantic information just isn't there
Yes it is. Webpages semantically provide information on the purpose of onscreen elements by their appearance. Vast quantities of humans ensure the semantic information is there by using the websites. Websites that do not convery semantic information through their appeareance will die, because nobody is using them.
> Not all accessibility tools are expensive
I want to acknowledge your point here - the situation may have improved the last time I looked at accessibility tools, which at the time was mainly overpriced badly maintained proprietary software. I still think the "boil the ocean" strategy is discredited and wrong.
I'm glad that a large proportion of web developers are happy to boil the ocean then. I use the web every day with a screen reader. It works. 99% of what I want to access is fine. Often not perfect, but a whole lot better than what I could get out of AI.
I do use ChatGPT to research things, but I don't usually see that as accessibility solution. I completely agree that screen readers and browsers would benefit from AI, as they already are; Chrome and Edge can generate missing image descriptions. AI can certainly enhance accessibility, but it can't replace the existing technology that already works quite well a lot of the time.
The other positive about AI for accessibility is that the frontier models have a good understanding of what works. Instead of learning all the guidelines, you can just ask an agent to review the page for accessibility and fix any problems.
I realise I am only looking at it from a screen reader point of view, and yes, we are quite a small minority. But good universal design helps everyone, whether they just need to zoom the page for comfort without it breaking, their eyes are not that of a young person, they have dexterity issues using a mouse, and many more. Accessibility in general isn't serving a tiny minority,. I imagine most of us will come to appreciate it in some way.
It's not a binary. most web sites are accessible to some degree. Just the fact that semantic elements exist at all makes a big difference. Popular frameworks have accessibility built in.
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.
reply