Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't put aria-label on generic elements like divs

matuzo.at

Post reply on HN
Print view View original

21–30 of 92 posts

Re: Don't put aria-label on generic elements like divs

#21

Post by nostats »

recursivedoubts wrote: post #9

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.

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.

Re: Don't put aria-label on generic elements like divs

#23

Post by karlshea »

542458 wrote: post #6

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 explai…

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.

Re: Don't put aria-label on generic elements like divs

#24

Post by jabroni_salad »

pbalau wrote: post #11
jnovek wrote: post #5

Earlier quoted context omitted.

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 disa…

> 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%.

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.

Re: Don't put aria-label on generic elements like divs

#25

Post by voidUpdate »

oneeyedpigeon wrote: post #12
pbalau wrote: post #11

Earlier quoted context omitted.

> 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?!

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

Re: Don't put aria-label on generic elements like divs

#26

Post by Joker_vD »

jnovek wrote: post #5
Xirdus wrote: post #4

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 disa…

I remember seeing a website that had 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.

Re: Don't put aria-label on generic elements like divs

#27

Post by RobMurray »

nailer wrote: post #7

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.

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.

Re: Don't put aria-label on generic elements like divs

#29

Post by jugglinmike »

542458 wrote: post #6

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 explai…

ARIA-AT is a W3C Community Group (of which I'm a member) trying to address this problem: https://aria-at.w3.org/about

Re: Don't put aria-label on generic elements like divs

#30

Post by masfuerte »

Joker_vD wrote: post #26
jnovek wrote: post #5

Earlier quoted context omitted.

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 disa…

I remember seeing a website that had 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.

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.
Post reply on HN