Don't put aria-label on generic elements like divs
36 points by cyanbane 4 days ago | 20 comments

Xirdus 3 hours ago
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).
reply
jnovek 3 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.
reply
pbalau 2 hours ago
> 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%.

reply
oneeyedpigeon 2 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?!
reply
ryandrake 15 minutes 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.

reply
cestith 2 hours ago
Which platform is this on? I usually read hn on a desktop browser, and it works fine well above 110% there.
reply
uallo 2 hours ago
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...

reply
ryandrake 18 minutes ago
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.
reply
injidup 2 hours ago
The irony of a tool designed to enforce usability and discoverability that which itself is unusable and undiscoverable.
reply
chrismorgan 46 minutes ago
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”).
reply
542458 3 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!

reply
goda90 3 hours ago
Left part of the page is cut off and only accessible with reader mode on IronFox for Android. Talk about #WebAccessibilityFails
reply
recursivedoubts 2 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.

reply
nostats 11 minutes 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.

reply
paulryanrogers 3 hours ago
Zoom bug reading this article. Perhaps it's just my Firefox?

Still, a nice concise read if you can get it

reply
jrochkind1 53 minutes ago
today i learned there are browser built-in popovers now.
reply
karlshea 7 minutes 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!
reply
nailer 2 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.

reply
jraph 2 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.

reply
ramblurr 2 hours ago
What document?

Do you have any sources to back these claims up?

reply