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

51–60 of 92 posts

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

#51

Post by RobMurray »

nailer wrote: post #41
RobMurray wrote: post #27

Earlier quoted context omitted.

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.

> 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. But it can't. See this article.

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.

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

#52

Post by xigoi »

ryandrake wrote: post #19
uallo wrote: post #15

Earlier quoted context omitted.

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

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.

Bare HTML is pretty bad for accessibility. For example, you get no maximum width, making websites painful to read in a wide window.

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

#53

Post by rhdunn »

nailer wrote: post #42
ramblurr wrote: post #8

Earlier quoted context omitted.

What document? Do you have any sources to back these claims up?

> What document? 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.

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.

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.

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

#54

Post by RobMurray »

nailer wrote: post #42
ramblurr wrote: post #8

Earlier quoted context omitted.

What document? Do you have any sources to back these claims up?

> What document? 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.

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

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

#55

Post by mostlysimilar »

xigoi wrote: post #52
ryandrake wrote: post #19

Earlier quoted context omitted.

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.

Bare HTML is pretty bad for accessibility. For example, you get no maximum width, making websites painful to read in a wide window.

Windows are resizable. Built-in width selection!

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

#56

Post by xigoi »

mostlysimilar wrote: post #55
xigoi wrote: post #52

Earlier quoted context omitted.

Bare HTML is pretty bad for accessibility. For example, you get no maximum width, making websites painful to read in a wide window.

Windows are resizable. Built-in width selection!

You can’t set a different size per site. More width is better for sites that have sidebars and stuff.

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

#58

Post by jakelazaroff »

nailer wrote: post #49
jakelazaroff wrote: post #47

Earlier quoted context omitted.

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

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

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

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

#59

Post by cestith »

pbalau wrote: post #33
cestith wrote: post #16

Earlier quoted context omitted.

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

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.

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

#60

Post by chowells »

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

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