To title abbr or not?

Reading Time: 4 minutes

The following code snippet caught my attention when following posts by Chris Coyier and Eric Bailey diminishing objections to the abbreviation of accessibility to “a11y”.

Abbreviation <abbr>a11y</abbr>

There is no title="" attribute within the abbr element. I was groomed to always include it.

The Correct HTML?

A little research including the WHATWG Living Standard (September, 2020) confirmed the snippet is correct. I learned:

  • The title attribute, “may be used to provide an expansion of the abbreviation”.
  • The sample use-case is useful to mark-up an in-line abbreviation between parentheses within an <abbr> element.
  • We can independently style when the  title="" attribute is present, or not.

WHATWG’s use-case 2 of 3 directs us, [use when]:

“Abbreviations that are likely to be unfamiliar to the document’s readers, for which authors are encouraged to either mark up the abbreviation using an abbr element with a title attribute or include the expansion inline in the text the first time the abbreviation is used”

When I add abbreviations in the future:

  • When inline within parentheses, I will include the abbr tag and without a title attribute.
  • When inline without an adjacent definition, I will include the abbr with a title="" attribute.

I will also consider particularly screen reader users who may skip sections between headings, etc. Writing style guidelines often prescribe defining an abbreviation only on its first page instance. Skipping past the definition may leave our screen reader users stranded.

Visual Styling

The default visual styles of the abbr tag seem to vary by browser? In Chrome, Safari, Firefox, and New Edge or other browsers I expect the copy text contained within an abbr tag to display as follows:

  • Without a title="" attribute, there is no dotted underscore.
  • With a title="" attribute, there is a dotted underscore.

This is vital as:

  • An abbr with a title="" attribute invites a user interaction to reveal the title text.
  • An abbr without a title="" attribute has no interaction and must not falsely indicate that it has.

Test 1

The following test HTML code was opened in different Mac and Windows browsers:

<html lang="en">
<title>Test 1: default abbr visual style</title>
<p>I am interested in whether an abbreviation for accessibility (<abbr>a11y</abbr>) needs a title element, or not. For example, this abbreviation, <abbr title="accessibility">a11y</abbr> has a title.</p>

Test 1 Results

Test 1 default abbreviation visual style results by browser.
Each browser is annotated when it displays the dashed underscore with a Yes, or No when it does not. Safari was the only fail.
Browser With title attribute Without title attribute
Mac Chrome Yes No
Mac Firefox Yes No
Mac New Edge Yes No
Mac Safari No No
PC Chrome Yes No
PC Firefox Yes No
PC New Edge Yes No

When styling a visual difference between the abbr with and without the title attribute, we can use the following declarations:

  • abbr[title] {style}. Example:
    The State of CA.
  • abbr {style}. Example:
    The State of California (CA).

Don’t forget to style the cursor to “help” to indicate the interactivity!

Note. The above example is tweaked to override the default blog styles and may not display as intended in some browsers. The default blog style is to underscore the abbr element with or without the title attribute!

Programming for Touch

We can leap to an assumption that Safari attempts to consolidate display and touch screen experiences. Hover and title-based tooltips do not feature natively on touch devices. This may be sensible, or not?

It is a good habit to accommodate touch screen users by programmatically displaying the expected title tooltip. Correctly written, the native HTML without CSS or JavaScript will still reveal the abbr elements interaction state on a ‘desktop’ device with a dotted underscore, or not. Safari’s stance omits that use case.

To mitigate the situation as best we can, we must employ CSS and JavaScript, and warn visitors to ‘desktop’ pages and without either that they may be missing out on the intended experience. Think of the depreciated noscript tag only done properly for 2020 with JavaScript as follows:



On hovering over, clicking or tapping on the abbr, we:

  1. Use JavaScript to create an empty container
  2. Identify and place the title attribute string in the new container
  3. Display the new element
  4. Add a Close button to the element
  5. Style and position with CSS
  6. Reverse the process for mouseout

Note. There is no need for ARIA-live, etc. when screen readers can announce the title natively. Ah, and Safari?

Example of a programmed tooltip with a close button
The programmed tooltip as viewed using iOS Safari showing the close button. From



In tests with VoiceOver, how the abbr element is announced seemed to depend on how the screen reader was set up. At times it read the title seamlessly and at others only with effort. Abbr elements without a title attribute were read as standard copy text in all cases. I am likely only a biff with VoiceOver.


Some commentators profess adding the aria-label="" attribute. In testing, I found that interrupted and even repeated the VoiceOver flow and made a pig’s ear of the editorial intent. More testing is needed.

Writing Special States

By chance during this blog’s drafting, NS posted the following to a Facebook a11y group:

“Do screen reader users know when they’ve hit an abbreviation for a state (CT, NY, MA, etc.), they know it’s a state? Maine reads as “Me.” The document in question is contextual, so the abbreviations might make sense to screen reader users. Thoughts?”

I gave this some thought and removed the abbr altogether and tested placing a visually-hidden span between the State letters and in the adjacent paragraph as follows:

<p>The State of M<span class="visually-hidden">&nbsp;</span>E is almost as large as the whole of Europe.</p>

<p>The State of ME is almost as large as the whole of Europe.</p>

In Safari browser with VoiceOver, both paragraphs were read correctly, “M E”. The capitalization seems to work without additional mark-up? Yet, there must be a problem for screen-reader users and abbreviations as reported by ML in the same thread:

“I’m a native screen reader user. The screen reader will not recognize it as a state or as an abbreviation yet. Hopefully at some point screen readers will be able to recognize the appropriate HTML tag that would indicate it’s an abbreviation but we’re not there yet. So that said, most people that use screen readers are acclimated to recognizing things like this and will generally figure it out via context.”

SW wrote:

“Addendum: Not to say that I feel this is right. We could be doing better. When writing the code, I believe there are ways to use ARIA attributes to label the abbreviations differently, so the user doesn’t have to try to figure it out.”

As before, I found ARIA to be less than optimal.

Study continues.

Leave a Reply