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 put into a11y issues is the opposite of a code smell to me.
Note: aria-label is intended for use on interactive elements, or elements made to be interactive via other ARIA declarations, when there is no appropriate text visible in the DOM that could be referenced as a 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 put into a11y issues is the opposite of a code smell to me.
You can actually reduce accessibility by misusing aria attributes. Folks should try to use semantic elements first. Then if those aren't meeting their needs (please try to make them meet your needs), there are good, well tested implementations of the common aria patterns (https://www.w3.org/WAI/ARIA/apg/patterns/) for frameworks like react. Some examples of this are radix and ariakit.
> any indication that any amount of thought has been put into a11y issues is the opposite of a code smell to me
You're absolutely right but that's mainly just because the bar is so low.
Ultimately it does seem like code smell to me. Insofar as it indicates you're doing something toward a11y, it's what I'd call a "good problem" (the type you only encounter when things are going in the right direction), but it seems a good indicator that a11y is being applied as an addon process (where a functional product goes through a11y review before iterating) rather than an intrinsic consideration at the architecting stage.
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 explicit or implicit WAI-ARIA role where aria-label is prohibited."[2]
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 <section> and <nav>.
I was surprised as well, and I wonder what the reason for that is.
The article also mentions that it's explicitly disallowed on a bunch of elements in point #5 [1]. I know that I've used an aria-label on a <time> element in the past because the actual order of the contents of the element in there was kinda funky due to the visual presentation, so it felt like it would make sense to have a more sensible description in an aria-label. I wonder what the problem with that would've been, had browsers not discarded it?
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 implemented using "<img aria-label='avatar' src='user.jpg' />" and then tested using "getByRole('img', { name: 'avatar' })". This is technically wrong because getByAltText would be preferable, but it works and it's easy so devs do it.
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."
> 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.
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.
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.
Luckily I don't see any "encouragement to use aria" on that page you linked to, as that - and particular your example - goes directly against the first rule of ARIA [1] (paraphrased: "only ever use ARIA if you can't use native HTML").
A "code smell" is supposed to be something that is a warning sign that there are other probable issues and you should look deeper. Using aria-* incorrectly is an actual problem, not a hint that there may be deeper issues.
It's always annoying when an article begins with a strained attempt to redefine well known terms.
THIS article defines "code smell" exactly as you did. And it says that using aria-* incorrectly is not a smell, but an error, exactly as you did.
The claim of the article is that using aria-* at all is a code smell, in exactly the sense you said. They list a number of possible problems, and suggest alternatives. They're not saying that using area-* cannot be correct, just that it's so often incorrect as to be a smell.
> 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 site, that doesn't use aria-* tags at all?
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-based CRUD UIs for backoffice software (i.e. the thing you get from bog-standard no-other-libraries-needed Django or Rails.) You don't need the aria- tag attributes when building any of those. To achieve accessibility with these, you just need a ca. 2001 CSS Zen Garden-esque understanding of semantic HTML.
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 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.
Even IF in one of these sites they order of your markup is such that the elements follow in a correct order and the seen text will be understandable when accessed through the screen reader there are likely to be instances in which, if you care about the experience of a visually challenged user, extra work would be useful to allow for navigating between parts of the site in an understandable way and to do things with a reasonable speed.
>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.
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?"
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 <select> and Vue can still do automagic with it, it doesn’t have to be a pseudo-dropdown built from <div>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.
Only if you want to give your users a terrible experience where the screen reader reads a bunch of separate items with no logical connection between them.
A single aria-label describing a component and its actions is always going to be better.
They're not saying all aria- attributes are a code smell, just that aria-label is. And they provided an extensive list of common usages where an alternative would usually be better.
"The more ARIA attributes that were present, the more detected accessibility errors could be expected"
This sounds about right for the current state of attention paid to assistive technology. Which is to say, it's an afterthought at best. Buying or installing some half-baked framework which attempts to use it correctly without even determining if it's correct or not and calling it good seems about as far as anyone will take it. One could make an analogy with left-pad: easy to use, but turns out it does the wrong thing for several cases.
Using anything incorrectly is probably a problem. What makes a smell is that using it at all is worth scrutiny. Things like eval and interpolating user input can be done correctly but frequently aren't and that's why we have lint rules and names like dangerouslySetInnerHtml
I am not sure I fully agree, opening up a old website and smashing a bunch of aria-* tags does not fix anything. It just adds a bunch of aria-* stuff that may or may not be used.
To correctly implement accessibility on a website can require a fair amount of redoing components so they are properly accessible.
Learning how to use a screen reader in order to test the a11y of my code has been on my todo for a very long time. Has anyone else done this? Is it worth it?
The easiest option is to use your operating system's default browser, and turn on assistance. So on mac use Safari and turn on Voiceover, and on Windows use edge and turn on Narrator.
To really test yourself, once you have learnt the basics of using voiceover and narrator, turn off your monitor and navigate your website :)
In my limited experience, many people use one of those two options (the situation in Linux is unfortunately much less functional).
Yes! It's not even that much of a time investment; a short video [1] and some playing around can already give you a pretty good grip of common issues in 15 minutes.
Yes, that's not enough for properly evaluating the performance of what you're working on (screen readers differ far more than browsers do, and there's many different ways of navigating), but it helps form a mental model and to quickly encouter really egregious issues that e.g. make your entire project inaccessible with any screen reader.
[1] I think I used this one, to learn the general principles and to at least find the terms needed to find the shortcuts for my operating system: https://www.youtube.com/watch?v=5R-6WvAihms
There's no "learn how to use," just enable it on your existing devices. Settings > Accessibility on android, at least.
Consider making a habit of using it when you are circumstantially visually disabled: in bright sunlight, while you can't be physically present at the phone (eg while doing dishes or folding laundry), etc.
I think it's good to learn the different ways people can use it too though, e.g. learn about landmark navigation, or skipping to headlines, or how people navigate a table, etc.
Absolutely worth it. Has helped me a lot, finding small issues like buttons with no meaningful label or custom checkboxes that don't announce their state.
I don't know what platform you're on, but I use VoiceOver on Mac. My blind relative uses JAWS on Windows.
I have considered writing a guide to using Voiceover for sighted users as a power tool, because it is great. The other ones not so much. The main problem you will find if you are developing is you cannot expect stuff that works in one screenreader browser combo to work reliably in others so you need to do a lot of testing with different combinations.
It would take a long time to get "up to speed" (setting the speech rate to 2x or 4x like a real user) but a lot of them have modes that show the spoken text on screen. That should let you test some basic a11y features like the "skip to main content" links.
Man talk about smell, there are like 18 olfactory cultural dimensions on display in this passage, esp. comparing para 2 as a prologue to para 1.
> In my experience, the term code smell usually has a negative connotation when someone mentions it.
> It’s a lot like a noticeable smell emanating from the office refrigerator. Ideally it’s some delicious homemade kimchi someone brought in, but more often than not it’s something like some forgotten fish sticks rotting in the back.
Google snippet when searching for "code smell martin fowler":
"According to Martin Fowler, code smells are not problematic on their own. They are warning signals that there might be a real problem in the code. For example, long functions are considered a code smell, but not all long functions are necessarily bad or poorly designed. Fowler suggests that junior members of a development team identify code smells and review them together with senior members, who can evaluate if there is really a deeper problem in the code."
And the first google result, which is Martin Fowler's own website:
"The second is that smells don't always indicate a problem. Some long methods are just fine. You have to look deeper to see if there is an underlying problem there - smells aren't inherently bad on their own - they are often an indicator of a problem rather than the problem themselves."
To be fair, browser already provide a bunch of accessibility. Unfortunately, the tech we use to build websites also provide a whole host of footguns that are too easy to trigger when building UIs of any meaningful complexity.
Yes! It’s not a good state of affairs. If you want people to build accessible websites, you can’t yell at them for not understanding complicated topics where best practices documents contradict each other. You have to lay out simple rules like “add an alt attribute to images.”
This page is impossible to read on smartphone at least. There are kilometers of empty space between each line and blocks. And the font is huge. There is 20 lines of a few words each at most per page of scroll.
I have now pain in my finger scrolling so much to try to see what is the point. Also a lot of useless speech and I have not reached the point of why aria label is code smell before giving up...
> I have not reached the point of why aria label is code smell before giving up
The main point was that they often see it used to label non-interactive elements, when it should only be used for interactive elements. It's a useful point to make, but that's not a code smell, that's faulty code.
The author should have chosen a better title, e.g. "Think twice before using 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 put into a11y issues is the opposite of a code smell to me.