Thank you! I switched from Prism to https://shiki.style/ recently to enable that, and allow VSCode-style wrapping (where it wraps to the indent, rather than the start of the line).
The addition of the single attribute "aria-labelledby=..." is horrible?
It's a single, very small addition to the code here. The element structure was already there, this was just signaling where to get the alt text for a button.
What about adding a single attribute is "horrible"? It seems concise, explicit, and DRY.
I'm assuming good faith question here. Good faith answer:
The title attribute may not be read by all screen readers by default, if at all. Some will, but some won't.
Additionally, when users are keyboard only, touch input, or using voice access they may not have an easy way to view the content contained by a title attribute. Whereas assistive technologies beyond screen readers can make use of it.
Users with fine motor impairment may be unable to hover long enough to show a title, depending on their browser.
Labelledby has the highest precedence in parsing, and every screen reader will know what to do with it. It removes uncertainty as a dev -- you know absolutely what will be read by it.
Aria labels can be used to give blind users the same experience as sighted users, which may not be the same text as a tooltip. If you need to convey something visual about the item being labeled and some text, you can use aria attributes to provide that.
Title gets inherited by all children, unless a child has an empty title. This could cause weird behaviors for screen reader users if one isn't careful. Labelledby is not inherited, and gives you control over which specific elements get labels.
Even if that was consistent, the other reasons are not addressed.
And the spec for the title attribute is for "advisory information", which isn't necessarily the same as descriptions. A title attribute could be used to give an image a credit, for example.
But the W3C recommends against relying on the title attribute for converting information:
* Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g., requiring a pointing device such as a mouse to cause a tooltip to appear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet).*
You could argue that all the user agents across all mobile and desktop applications and browsers should present title information consistently even when there is no pointing device. But, that's unlikely to happen.
So you have a choice, leave out users with disabilities because "it's all the world's software that could change" or add a labelledby attribute and get on with one's day.
Only one of those lines is the tooltip element. If you're comparing to the title attribute, it's one additional line, and solves all the problems vs title that others have already mentioned here.
I'm guessing you got 7 from the final code example which is referred to as "overkill", and only useful in cases where the tooltip has enough content to make it worth splitting up the label & description parts - something you can't do with a simple title attribute.
Basically, it's worth reading the thing you're critiquing.
> The content of the title attribute is often ignored or read inconsistently, leaving users who rely on assistive technology at a disadvantage.
Regardless of whether screen readers should better support title attributes, that's not the world we live in and blind users don't benefit from websites that fail to work because of principled takes.
It is frustrating that instead of fixing existing, fairly simple interfaces, web tech seems to instead create complicated and harder to use interfaces which are more likely to be used incorrectly or at least inconsistently. It feels like it's likely to make the problem worse, not better, in the long run.
(like, even if it was spelt differently due to backwards compatibility, it would be nice to just have a 'insert tooltip text here' interface that did work on desktop, mobile, and in screen readers. This doesn't feel like it's beyond the wit of man)
Aria spec is nearly 20 years old, with the first drafts being out in 2006. Labelledby was a core part of the first spec, and is not particularly complicated.
There is no way to make a change to title attribute that isn't breaking to some use cases if you want it to support everything label/labelledby supports.
That said, if you are talking about tooltips, which are different from accessibility attributes, I digress. Tooltips have always been a software nightmare, and the web is no exception.
That's the thing, though. Tooltips aren't just text. Qt, GTK, and Windows all support some flavor of rich text tooltips, so it's not even an operating system constraint. The simplest solution for this in an accessible way looks exactly like Aria labels.
But here's the thing: a text tooltip assumes the label you show to screen readers is the tooltip. That's not always true. In this case, the tooltip serves the purpose of labeling a button icon. A tooltip on a text button doesn't have the same purpose from an accessibility standpoint. There's simply no universal way to define what a tooltip is in a way that semantically correct.
It's a single, very small addition to the code here. The element structure was already there, this was just signaling where to get the alt text for a button.
What about adding a single attribute is "horrible"? It seems concise, explicit, and DRY.
The title attribute may not be read by all screen readers by default, if at all. Some will, but some won't.
Additionally, when users are keyboard only, touch input, or using voice access they may not have an easy way to view the content contained by a title attribute. Whereas assistive technologies beyond screen readers can make use of it.
Users with fine motor impairment may be unable to hover long enough to show a title, depending on their browser.
Labelledby has the highest precedence in parsing, and every screen reader will know what to do with it. It removes uncertainty as a dev -- you know absolutely what will be read by it.
Aria labels can be used to give blind users the same experience as sighted users, which may not be the same text as a tooltip. If you need to convey something visual about the item being labeled and some text, you can use aria attributes to provide that.
Title gets inherited by all children, unless a child has an empty title. This could cause weird behaviors for screen reader users if one isn't careful. Labelledby is not inherited, and gives you control over which specific elements get labels.
And the spec for the title attribute is for "advisory information", which isn't necessarily the same as descriptions. A title attribute could be used to give an image a credit, for example.
But the W3C recommends against relying on the title attribute for converting information:
* Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g., requiring a pointing device such as a mouse to cause a tooltip to appear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet).*
You could argue that all the user agents across all mobile and desktop applications and browsers should present title information consistently even when there is no pointing device. But, that's unlikely to happen.
So you have a choice, leave out users with disabilities because "it's all the world's software that could change" or add a labelledby attribute and get on with one's day.
I'm guessing you got 7 from the final code example which is referred to as "overkill", and only useful in cases where the tooltip has enough content to make it worth splitting up the label & description parts - something you can't do with a simple title attribute.
Basically, it's worth reading the thing you're critiquing.
- one line for an svg icon
- four lines for the tooltip.
From https://www.a11y-collective.com/blog/aria-label-vs-title/
> The content of the title attribute is often ignored or read inconsistently, leaving users who rely on assistive technology at a disadvantage.
Regardless of whether screen readers should better support title attributes, that's not the world we live in and blind users don't benefit from websites that fail to work because of principled takes.
(like, even if it was spelt differently due to backwards compatibility, it would be nice to just have a 'insert tooltip text here' interface that did work on desktop, mobile, and in screen readers. This doesn't feel like it's beyond the wit of man)
There is no way to make a change to title attribute that isn't breaking to some use cases if you want it to support everything label/labelledby supports.
That said, if you are talking about tooltips, which are different from accessibility attributes, I digress. Tooltips have always been a software nightmare, and the web is no exception.
But here's the thing: a text tooltip assumes the label you show to screen readers is the tooltip. That's not always true. In this case, the tooltip serves the purpose of labeling a button icon. A tooltip on a text button doesn't have the same purpose from an accessibility standpoint. There's simply no universal way to define what a tooltip is in a way that semantically correct.