Reading Time: 4 minutesThe 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
abbrtag and without a title attribute. - When inline without an adjacent definition, I will include the
abbrwith atitle=""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
abbrwith atitle=""attribute invites a user interaction to reveal the title text. - An
abbrwithout atitle=""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"> <head> <title>Test 1: default abbr visual style</title> </head> <body> <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> </body> </html>
Test 1 Results
| 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:
/*JQuery*/
$('#noScript').hide();
Strategy
On hovering over, clicking or tapping on the abbr, we:
- Use JavaScript to create an empty container
- Identify and place the title attribute string in the new container
- Display the new element
- Add a Close button to the element
- Style and position with CSS
- 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?
VoiceOver
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.
ARIA
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"> </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.