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

Aria-label is a code smell

ericwbailey.website

Post reply on HN
Print view View original

61–70 of 74 posts

Re: Aria-label is a code smell

#61

Post by 7sidedmarble »

bryanrasmussen wrote: post #58
derefr wrote: post #22

Earlier quoted context omitted.

Why do you elevate "significance"? In terms of the number of developers who care, "significant sites" are a minor niche. The web obeys a power law; there are only 1000 "significant" websites in the world, and far more "insignificant" ones. Most of the world's web developers are creating blogs, business-card-ware (e.g. restaurant websites that let you see the menu as a PDF but don't let you order from it), and HTML-ba…

The vagaries of English being what they are significant does not need mean important, in this case I think they mean a site with a significant amount of work behind it. That is to say not a quick resume site. A real site with a few 100 pages and complicated workflows are significant in the way I believe the OP meant. >You don't need the aria- tag attributes when building any of those. what, these are exactly the site…

>what, these are exactly the sites where you need aria tags, because they all have buttons and workflows the context and usage of which are totally obvious to anyone who can see and completely opaque otherwise.

The authors point was that you should rely first on the information you can communicate in the actual content, ie, a button with the content of 'submit', when it's inside a form element, is enough to communicate what it does to every user. But if you have multiple buttons that all say 'submit', and you can't consider changing the content to be more explicit, that's when you may want aria-label. The authors point was that this latter scenario is actually less common though, and I agree with them.

Re: Aria-label is a code smell

#62

Post by wittjeff »

Archelaos wrote: post #44
nfw2 wrote: post #12

The article claims that aria-label is only intended to be used on interactive elements. This surprised me, so I looked into it. The ARIA spec says aria-label can used with any roles, with no mention of being reserved for interactive elements. https://www.w3.org/TR/wai-aria-1.1/#aria-label Also, maybe I am too jaded by working at orgs that don't care about a11y, but any indication that any amount of thought has been p…

The current[1] WAI-ARIA spec is to blame for not clearifying this intend. However, the W3C Editor's Draft of WAI-ARIA 1.3 of 26 October 2022 attempts to do so: "In the cases where DOM content or a tooltip is undesirable, authors MAY set the accessible name of the element using aria-label, if the element does not prohibit use of the attribute. [...] Authors MUST NOT specify aria-label on an element which has an explic…

That doc lists only a few elements where aria-label should not be used: caption, code, definition, deletion, emphasis, generic, insertion, mark, paragraph, presentation, strong, subscript, suggestion, superscript, term, time

I am particularly concerned if people interpret the parent article to mean that aria-label shouldn't be used on certain semantic containers that are exposed in the accessibility tree by screen readers, such as and .

Re: Aria-label is a code smell

#64

Post by user3939382 »

Ensorceled wrote: post #21
user3939382 wrote: post #16

Earlier quoted context omitted.

> But do to accessibility correctly you almost ALWAYS need to use aria-* What? No... Screen readers do best with standard elements and you're supposed to avoid aria labels where possible, and only as a last resort.

> What? No... Screen readers do best with standard elements and you're supposed to avoid aria labels where possible, and only as a last resort. Yes, you should avoid overusing them, which is the point the author is turning into a "code smell", but I've no idea how the heck you would pass an AAA or even a AA audit without aria-* labels. Can you point me to a significant site, i.e. one that's not just a simple content…

I work daily on a pretty complex platform that is able to completely bypass them. That’s because Vue, and I imagine other UI frameworks like it, have good support for building components by essentially decorating these simple HTML elements that the screen readers like.

In other words, for example, your dropdown can be a and Vue can still do automagic with it, it doesn’t have to be a pseudo-dropdown built from s that you then need aria for. And in fact even in our complex codebase that’s been universally true.

I’m sure there are exceptions but I assume they’re rare enough that even other large projects don’t have any.

Re: Aria-label is a code smell

#65

Post by emptysea »

onion2k wrote: post #38

One of the nice things about Testing Library (a library that provides helpers for testing frontend code) is that it encourages devs to use Aria tags to find elements in the DOM to test[1]. This has the neat side effect that frontend devs who want to unit test their components 'accidentally' make them more accessible. I suspect this could be at least partly responsible for the overuse of aria-label. An element can be…

One caveat with testing library’s getByRole function is that it’s really really slow.

In my experience with medium side components it would take seconds to find the element vs a few milliseconds for getByTestId.

Re: Aria-label is a code smell

#66

Post by bryanrasmussen »

7sidedmarble wrote: post #61
bryanrasmussen wrote: post #58

Earlier quoted context omitted.

The vagaries of English being what they are significant does not need mean important, in this case I think they mean a site with a significant amount of work behind it. That is to say not a quick resume site. A real site with a few 100 pages and complicated workflows are significant in the way I believe the OP meant. >You don't need the aria- tag attributes when building any of those. what, these are exactly the site…

>what, these are exactly the sites where you need aria tags, because they all have buttons and workflows the context and usage of which are totally obvious to anyone who can see and completely opaque otherwise. The authors point was that you should rely first on the information you can communicate in the actual content, ie, a button with the content of 'submit', when it's inside a form element, is enough to communica…

have you used a screen reader?

If so have you ever used the more advanced navigational methods, here I'll just limit myself to the web-rotor on Voiceover because it is the easiest to think about and to remember how it works - at least for me.

>The authors point was that you should rely first on the information you can communicate in the actual content, ie, a button with the content of 'submit',

I understand the author's point, and the OP discussed that doesn't make any sense because on any 'significant' site you can't rely on that.

So ok, let's take another example. You come into a site as a sighted user

there is a button that says refresh under the User messages heading.

and a button that says refresh under the System messages heading.

As a sighted user you know exactly what the context is of these refresh buttons and you know that in a second.

As a blind user you will probably have to go through the page, at least the first time, and then remember to navigate to System Messages heading next time and go to refresh button after that.

In the sighted user context the nice design is to have all System messages underneath the header followed by the refresh button.

So you need to go through all the system messages to click the refresh button if you are the blind user.

Of course if the refresh button has an aria-label refresh System messages you can go to System messages heading, read the first, hear date has not been updated since last time you read, use web rotor to get refresh system messages button click button (why? Because this is an example of design conditions that affect sighted users and visually disabled users and not of any actual working site)

All of which is a very in depth example of a situation that should be easy to imagine without any detailed explanation of how in a reasonably complex site there can be constructs that will be totally apparent to sighted users and not apparent to people with visual impairments and how just relying on the natural layout of the site would be under-serving screen-reader users.

I admit that a submit button probably won't have this scenario, but there are lots of clickable buttons on most modern sites that are not a submit.

At which point I suppose someone might make the obvious argument that the buttons should have the text Refresh System Messages and Refresh User Messages

but that won't go because

1. buttons with a lot of text on them are harder to understand so now a large portion of the user base needs to be under-served to make things easier for the people who are visually impaired.

2. From a design perspective having Refresh System messages under the System Messages area instead of just Refresh is also grating.

At any rate as said, the above is a completely artificial scenario that should be immediately understandable as an example of the kind of thing to arise on a normal company site by any one who has had to develop for such a site.

And I say this to try to forestall the HN - "but you should not have a refresh button because the data should be pulled periodically" or "why would you come to the site, read a message and then know you should refresh huh?"

Re: Aria-label is a code smell

#67

Post by Wowfunhappy »

reitanqild wrote: post #54
Vinnl wrote: post #47

Earlier quoted context omitted.

> the ideal scenario is a description of what is in the image. I'd say the ideal scenario is conveying the information that the image conveys. If there is no new information in the image (for example, it might be redundant with the username next to it), it's better to explicitly add an empty alt tag, as far as I'm aware.

Adding an empty alt tag is often the correct thing yes. Rule of thumb: if someone read the page out to you, would you prefer if they read that alt tag you are thinking of adding or not?

I wish omitting alt text was the equivalent of empty alt text.

Nothing else works this way. If a page doesn't have a favicon, you don't add an empty icon href.

I know empty alt text is preferred because otherwise, screen readers will usually revert to reading the file name. But I wish screen readers didn't do that.

Re: Aria-label is a code smell

#68

Post by onion2k »

zachrip wrote: post #40
onion2k wrote: post #38

One of the nice things about Testing Library (a library that provides helpers for testing frontend code) is that it encourages devs to use Aria tags to find elements in the DOM to test[1]. This has the neat side effect that frontend devs who want to unit test their components 'accidentally' make them more accessible. I suspect this could be at least partly responsible for the overuse of aria-label. An element can be…

For those reading: using avatar as the alt text or aria-label is also wrong. At minimum it should say whose avatar it is but the ideal scenario is a description of what is in the image. The point of alt text is to make it accessible to everyone (slow connection, visually impaired, etc). Close your eyes and think "avatar" - not very useful, a better example is "Me in front of a lake showing off a fish I just caught."

"avatar" is fine in a test.

Re: Aria-label is a code smell

#69

Post by reitanqild »

Wowfunhappy wrote: post #67
reitanqild wrote: post #54

Earlier quoted context omitted.

Adding an empty alt tag is often the correct thing yes. Rule of thumb: if someone read the page out to you, would you prefer if they read that alt tag you are thinking of adding or not?

I wish omitting alt text was the equivalent of empty alt text. Nothing else works this way. If a page doesn't have a favicon, you don't add an empty icon href. I know empty alt text is preferred because otherwise, screen readers will usually revert to reading the file name. But I wish screen readers didn't do that.

I always thought it was standardized that way in an effort to get people to care about accessibility.

But FWIK it might just be because someone on the standards committee wanted it that way.

Re: Aria-label is a code smell

#70

Post by Wowfunhappy »

reitanqild wrote: post #69
Wowfunhappy wrote: post #67

Earlier quoted context omitted.

I wish omitting alt text was the equivalent of empty alt text. Nothing else works this way. If a page doesn't have a favicon, you don't add an empty icon href. I know empty alt text is preferred because otherwise, screen readers will usually revert to reading the file name. But I wish screen readers didn't do that.

I always thought it was standardized that way in an effort to get people to care about accessibility. But FWIK it might just be because someone on the standards committee wanted it that way.

Does that work though? If you don't care about accessibility, you can still leave out the tags. Screen readers will then default to reading the file name, which I'd argue is worse than skipping over images in the general case.
Post reply on HN