abbr design pattern
Use the abbr design pattern when you have localized, language, or design-specific human readable information that you want to markup and also provide a more globally human and machine readable alternative.
- Authors MUST NOT use the abbr design pattern to hide data.
- The contents of the
titleattribute MUST be both human-readable and human-listenable (e.g. for screenreaders), and SHOULD use a globally/internationally human readable format.
- For dates and times, authors SHOULD use the HTML5
<time>element instead of
<abbr>. (ed: Once common tools like Chrome Extensions, H2VX, Operator Firefox plugin all support the HTML5 time element, let's upgrade this statement to a MUST).
How to use it
- enclose the preferred local human readable text that you want to make globally human & machine readable with
- add the relevant microformats property names to the
- add a
titleattribute to the
abbrelement with the globally human & machine readable data as the value
- The end result MUST be human readable & listenable, when reading/speaking the abbr element's contents and its surroundings and when reading/speaking the abbr element's title attribute with its surrounding text.
The Date Design Pattern formally encodes globally human readable ISO dates into an
abbr element. Per the documentation/research on the Date Design Pattern page, ISO8601 dates, e.g. of the form YYYY-MM-DD, are the most globally/internationally date format.
Note: that dates and times SHOULD be marked up with the HTML5 time element. These examples illustrate both span/abbr markup for pre-HTML5 tools, and time element support for HTML5-capable tools.
The party is on the 10th.
Better (with HTML5 time instead of abbr)
You could also use the abbr-design-pattern to markup colloquial time references, but those should also use the HTML5 time element, e.g.
The party is at 10 o'clock.
Better (with HTML5 time instead of abbr)
Note that the following are all equivalent, to a microformat parser:
Better (with HTML5 time element)
These are all past examples that are usages to avoid.
Authors MUST NOT use the
abbr element as shown in these examples, as either the element text or the
title attribute text are not easily human readable.
The lack of dashes in "20070501" makes it read like a large number, not a date, both when viewing it, and when listening to it being read by a screenreader.
Avoid using the abbr design pattern for datetimes.
E.g. Authors MUST avoid doing this:
Ideally use the HTML5 time element:
Note the use of the hyphenated date to make it more human readable, as the more readable that even machine data is made, the greater the chance that a human will be able to accurately check it and verify that it matches the locale/language-specific contents of the time element.
Using ABBR to encode more formal human data around something less formal:
<abbr class="author" title="Danny Ayers">Danny</abbr>
This use is discouraged under the Don't Repeat Yourself principle, as it is a case of *more* information being less visibly present, namely, the family name in this case. If someone is not willing to make some information visible, then we shouldn't be encouraging them to store that information invisibly or less visibly, for all the same reasons that invisible metadata is bad/futile in the first place."
title attribute of the
<abbr> tag MUST always be human readable and speakable.
Screenreaders such as JAWS and others which use title attributes from abbr, and when used properly (as in this example below from the WCAG group), pronounce words which would otherwise be unreadable or confusing.
<p>Sugar is commonly sold in 5 <abbr title="pound">lb.</abbr> bags.</p> <p>Welcome to the <abbr title="World Wide Web">WWW</abbr>!</p>
If screen readers are unable to turn title content into something comprehensible, this will lead to accessibility failures. Here is a bad example:
would be read by Jaws as
we're having a party on Twenty million seventy-thousand three-hundred twelve tee seventeen-hundred dash zero six.
The accessibility task force from webstandards.org recommended:
<span class="dtstart" title="20070312T1700-06"> March 12, 2007 at 5 PM, Central Standard Time </span>
<span class="dtstart"> March 12, 2007 at 5 PM, Central Standard Time <span class="value" title="20070312T1700-06"></span> </span>
But both these approaches are problematic due to the title attribute being not easily human readable/verifiable because of:
- unhyphenated date, e.g. bad: 20070312; good:2007-03-12
- uncoloned time, e.g. bad: 1700; good: 17:00
- timezone offset without minutes, e.g. bad: -06; better: -0600
- combining date, time, and timezone into a single string without human-friendly separators
However, based on this input and subsequent research into better alternatives, the microformats community developed the Value Class Pattern with the following two alternatives:
And again, the even better alternative is to use the HTML5 time element: