[nfw2]

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.

[lozenge]

MDN agrees with the author:

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

https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

[zachrip]

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

[lucideer]

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

[croes]

Seems like it's best supported on interactive elements and doesn't lead to unintended behavior.

https://www.w3.org/TR/using-aria/#practical-support-aria-lab...

[Archelaos]

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]

[1] This is WAI-ARIA 1.2 (and not 1.1): https://www.w3.org/TR/wai-aria-1.2/#aria-label

[2] https://w3c.github.io/aria/#aria-label

[wittjeff]

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

[Vinnl]

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?

[1] https://w3c.github.io/aria/#namefromprohibited