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.
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
https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
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.
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.
https://www.w3.org/TR/using-aria/#practical-support-aria-lab...
"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
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>.
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?