Using abbr Element with title Attribute

How the <abbr> element is defined and exposed, along with the title attribute:

This broadly tells us what to expect from <abbr title>. But it’s still a bit of guessing game to know how users will actually experience it.

Testing

A black ceramic mug with a handle, except instead of the front of the mug following the general round shape, it extends out almost like a large human nose, and at the top of the mug where the bridge of the nose hits the rim, there are two stubby horizontal wings extending the rim. Why guess when we can test?

Join NASA for a briefing on its zero-G espresso cup, powered by capillary action! 

<p>
Join <abbr title="National Aeronautics and Space Administration">NASA</abbr> for a briefing on its zero-G espresso cup, powered by capillary action!
</p>

Windows 11 23H2

Firefox 121
Default style of dotted underline.
Exposes the title as the name on an element with the generic implicit role.
Does not display title as tool-tip with touch.
Does not display title as tool-tip with keyboard.
Does not display title as tool-tip with Voice Access unless I use it to control the mouse.
NVDA 2023.3
When using read-all, does not announce title.
When using virtual cursor, does not announce title.
Does not expose title in Braille display.
Chrome 120
Default style of dotted underline.
Exposes the title as the name on an element with the abbr implicit role.
Does not display title as tool-tip with touch.
Does not display title as tool-tip with keyboard.
Does not display title as tool-tip with Voice Access unless I use it to control the mouse.
JAWS 2024.2312.53
When using read-all, does not announce title.
When using virtual cursor, does not announce title.
Does not expose title in Braille display.
Edge 120
Default style of dotted underline.
Exposes the title as the name on an element with the abbr implicit role.
Does not display title as tool-tip with touch.
Does not display title as tool-tip with keyboard.
Does not display title as tool-tip with Voice Access unless I use it to control the mouse.
Narrator / Windows 11 23H2
When using read-all, does not announce title.
When using virtual cursor, announces title and then requires another keypress to announce visible text.

macOS 14.2.1

Safari 17.2.1
No default style.
Exposes the title as the label on an element with no matching role.
Does not display title as tool-tip with keyboard.
Does not display title as name with Voice Control when asking to show names.
VoiceOver
When using read-all, does not announce title.
When using virtual cursor, announces visible text and then title.
Does not expose title in Braille display.

Ubuntu 22.04.2 LTS

Firefox 115
Default style of dotted underline.
Exposes the title as the name on an element with the generic implicit role.
Displays title as tool-tip with touch.
Does not display title as tool-tip with keyboard.
Orca
When using read-all, does not announce title.
When using virtual cursor, does not announce title.

Android 14

Firefox 121
Default style of dotted underline.
Does not display title as tool-tip with touch.
Does not display title as tool-tip with keyboard.
Does not display title as name with Voice Access when asking to show names.
TalkBack 14.1
When using read-all, does not announce title.
When swiping through content, does not announce title.
When using explore-by-touch, does not announce title.
Chrome 120
Default style of dotted underline.
Does not display title as tool-tip with touch.
Does not display title as tool-tip with keyboard.
Does not display title as name with Voice Access when asking to show names.
TalkBack 14.1
When using read-all, only announces title.
When swiping through content, only announces title.
When using explore-by-touch, only announces title.

iPadOS 17.2

Safari 17.2
No default style.
Does not display title as tool-tip with touch.
Does not display title as name with Voice Control when asking to show names.
VoiceOver
When using read-all, does not announce title.
When swiping through content, does not announce title.
When using explore-by-touch, does not announce title.

Verdict

Don’t use <abbr> with or without title. Exposure continues to be inconsistent across browsers and assistive technologies. Some set of users will always miss some piece of information.

Explain abbreviations, acronyms, initialisms, numeronyms, etc. on first use and then feel free to fall back to the shortened form. The test sentence might then be:

Join National Aeronautics and Space Administration (NASA) for a briefing on its zero-G espresso cup, powered by capillary action!

18 Comments

Reply

Howdy. I’m not trying to be snarky here, as I’m 99% certain this is part of the default WP comment form, but there’s a tad bit of *sigh* that the note underneath the field I’m typing this comment in (a) contains an <abbr> element with title attribute and (b) notes that an <abbr> element with title attribute is one of the elements that I can use in this field.

Thanks for all the work you do.

John P. Green; . Permalink
In response to John P. Green. Reply

Also, big thanks to WP for parsing my asterisk-wrapped “sigh” as markdown on top of the HTML elements I was already using. (bigger sigh…)

John P. Green; . Permalink
In response to John P. Green. Reply

Yeah, that is part of WordPress and I have not yet found where that lives so I can write a function to override it. Partly because I want to split each element into its own <code>, I want to strip all instances of title, I want to strike <acronym> & <strike>, and I want to strip the <abbr> around the “HTML”. But since most of my commenters either use no HTML or try to use Markup, I mostly just keep letting it slide.

Reply

Sad but not surprising state of affairs…
Also, I love the concept of RSS club!

Philipp Tautz; . Permalink
Reply

I have found that using <abbr> also encourages over-explaining acronyms.

For example, in one of my earlier posts, I wrote “HTML” (with an <abbr> and title), but that isn’t actually helpful or useful to readers. HTML (and other file format extensions) are mostly commonly referred to by their acronyms and knowing what they stand for isn’t super helpful. If you are writing for any audience who doesn’t know what HTML is, then “HTML (the file format and syntax of webpages)” is clearly more helpful than “HTML (HyperText Markup Language)”. I find using <abbr> hides this away too cleanly so you as an author don’t have to think about it, but when you write out the acronym in text, you’re forced to consider whether it’s clearer — and thus better aligned with Plain Language — to leave the acronym unexpanded, to expand it, or to explain it.

“NASA” is also a good example. NASA is most commonly referred as “NASA” and adding “National Aeronautics and Space Administration” might just make the text unnecessarily complex for English as a Second Language readers without really providing any benefit. Instead, I think most of the time it would make more sense to simply link to NASA’s site or their Wikipedia article, or to explain it in a parenthetical in-text.

There are certainly some situations in which it makes sense to expand those acronyms, but they are far outnumbered by situations where it doesn’t. Using <abbr> allows authors to always expand acronyms without interrupting the flow of the text, making it too easy to not think about this.

Reply

I’d say the commen t instructions are either theme-specific or can be over-ridden by a theme, as they don’t appear on my WP site (commercial Astra theme) or the TPGBi WP site (custom theme).

Also, it doesn’t always have to be “National Aeronautics and Space Administration (NASA)” – sometimes “NASA (National Aeronautics and Space Administration)” might feel more appropriate.

Overall, I agree is pretty useless.

In response to Ricky Onsman. Reply

Yeah, I can opt to remove the form instructions completely but I cannot edit them. Unless you know where I can edit them from any of the themes you have handy?

As for the acronym, also yeah, the order you choose to show the expanded version versus the acronym should be a function of your audience and context. Mine could work for people who never ever heard of NASA and yours for everyone else. Also, yes, mine should have an article.

Reply

What about doing this :
BB

abbr::before { content: attr(title); }

This retains semantics but should also display the title.

Maybe even doing this to only display it when element is interacted with:

abbr:active::before { content: attr(title); }

?

In response to bohwaz. Reply

Bear in mind that there are no semantics to retain — as I note above, it has none. But if you do that, you will want this (because it needs spaces, you would want it to appear after the existing text, and you would want parentheses):

abbr::after {
  content: " (" attr(title) ")";
}

But then Narrator and macOS / VoiceOver will give users a triple announcement. Never mind CSS generated content is not picked up by auto translation tool. At that point you are better off ditching the HTML and writing it out in the copy.

Don’t do it with :active since that requires a click or tap and then causes the content to redraw.

Reply

It seems from the tests that most people won’t get any additional experience, which is the same behavior as not having anything. So, why encourage people not to use it? Wouldn’t it be better to use it –so the document is ready when (if) browsers and assistive technologies provide support–, but not rely exclusively on it (e.g. by adding a description the first time it appears as you suggest)?

In response to Alvaro Montoro. Reply

It seems from the tests that most people won’t get any additional experience, which is the same behavior as not having anything.

Not quite. Consider a Chrome / TalkBack user only hears the value of title. An iPad VoiceOver user never hears the value of title. So it’s not that people don’t get any additional experience, it’s that some people get a different experience.

Also, I am careful using “most” to make decisions, since that’s how we get inaccessible sites to begin with (as a client once said, paraphrased, most people aren’t blind so why would we care about them?).

Wouldn’t it be better to use it –so the document is ready when (if) browsers and assistive technologies provide support–, but not rely exclusively on it (e.g. by adding a description the first time it appears as you suggest)?

No, because of that different experience (not “additional” experience).

Also no because browsers and AT have not exposed it since it was introduced in HTM4 in 1999. Never mind its role mapping is still generic.

Also also no because it sets an expectation with authors that is has value.

Also also also no because it sets an expectation with some users that there is additional content there they cannot access.

So between 25 years of failure to adopt it consistently and its differing exposure to users (when it is exposed), never mind the message its sends users who cannot access it, using <abbr> seems to be more of an anti-pattern at this point in the life of the web.

Reply

The day countries would regulate browsers’ compliance with standards…

Neil; . Permalink
Reply

What about adding tabindex="0" on the ABBR element?

dogfood; . Permalink
In response to dogfood. Reply

That should be a straightforward scenario to test. Which of the problems I listed above did that resolve when you tried it?

Separately, what WCAG Success Criteria might that fall?

Reply

When a screen reader or other assistive technology encounters an initialism like <abbr>US</abbr>, does it spell out the letters, or does it try to pronounce the abbreviation as a whole word? Does it make a difference if the initialism contains periods, such as <abbr>U.S.</abbr> or even U.S. without the tag?

I don’t have the tools to test (except for Voiceover) so does anyone else know?

In response to Chris J. Zähller. Reply

Whether a string of capitalized letters is announced as a word, individual letters, or something novel is based on factors I outline in Don’t Override Screen Reader Pronunciation. If a screen reader looks to the <abbr> element independently of the accessibility tree is unknown to me since I have not seen it documented.

Reply

This is where I turn into a curmudgeon: ABBR is in the spec, so I am going to use it. Wait, browsers and/or assistive technologies do not properly process this element you say? Well, that sounds like a “you” problem and not a “me” problem. File a bug report on the non-compliant technology.

Far too many times, I, as the programmer, am forced to code around other people’s crap. It gets tiresome. I want to use semantic HTML. I want to make sites fully accessible. Yet, time after time, the technology is just broken and no one seems to give a damn or ever fix anything. Seeing the typical test matrix of OS, browser, and screen-reader is just a nightmare of partial support and outright failure to support accessibility. Attempts are then made to prop up the failures using ARIA. This leads to another test matrix showing partial and no support.

[Heavy sigh]

Robert Bottomley; . Permalink
In response to Robert Bottomley. Reply

ABBR is in the spec, so I am going to use it.

In fact, it is in multiple specifications. For example, it is in HTML Accessibility API Mappings 1.0 § 3.4.3 abbr.

Wait, browsers and/or assistive technologies do not properly process this element you say?

According to the specification that determines how elements are exposed to users via platform accessibility APIs, browsers are properly processing the element.

Granted, that doesn’t make it any less frustrating. At some level, I consider this a failing of WHATWG, which has a history of trying to retcon elements and concepts into its version of HTML regardless of what authors want, what users want, or even what can be supported by user agents.

Seeing the typical test matrix of OS, browser, and screen-reader is just a nightmare of partial support and outright failure to support accessibility. Attempts are then made to prop up the failures using ARIA. This leads to another test matrix showing partial and no support.

Which is why I wrote this post — to tell authors they need not worry about any of that. Or, more accurately, to get authors to stop trying to resolve that with code and improve the outcome for users as a result. Hence, my guidance:

Explain abbreviations, acronyms, initialisms, numeronyms, etc. on first use and then feel free to fall back to the shortened form. No code needed (nor warranted).

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>