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

31–40 of 92 posts

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

#31

Post by pbalau »

jabroni_salad wrote: post #24
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%.

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.

For some reason I though the GP was talking about browsing on mobile, where I have the issue:

https://imgbox.com/EiovsE5b https://imgbox.com/A4Fl9lE9

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

#32

Post by pbalau »

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

For some reason I though the GP was talking about browsing on mobile, where I have the issue:

https://imgbox.com/EiovsE5b https://imgbox.com/A4Fl9lE9

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

#33

Post by pbalau »

cestith wrote: post #16
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%.

Which platform is this on? I usually read hn on a desktop browser, and it works fine well above 110% there.

Android

https://imgbox.com/EiovsE5b https://imgbox.com/A4Fl9lE9

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

#34

Post by bryanrasmussen »

masfuerte wrote: post #30
Joker_vD wrote: post #26

Earlier quoted context omitted.

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.

>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

https://css-tricks.com/linearly-scale-font-size-with-css-cla...

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

#36

Post by kid64 »

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

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.

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

#37

Post by micromacrofoot »

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.

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.

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

#38

Post by bryanrasmussen »

nostats wrote: post #21
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.

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.

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

#39

Post by DocTomoe »

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?

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

#40

Post by zero_shift »

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.

> 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

Post reply on HN