NOTE: I cannot get rid of </abbr> from the title... Help me...
TL;DR
Wrap abbreviations with
<abbr>in HTML, purely as a more semantic way of styling them with CSS than using<span>.Check if the font of your choice supports small caps as an OpenType feature. If so, move on to next step. Small caps may be available as another font family; in this case, simply use the
font-familyproperty and move on to step 4, or forget about small caps if the performance is a major concern. If small caps are not available, forget about styling abbreviations to avoid fake small caps rendered by browsers.If small caps are supported as an OpenType feature, use
font-variant-caps: all-small-capsto style<abbr>elements. You may want to forget about a fallback for legacy browsers withfont-feature-settings: "c2sc", "smcp".For some fonts, you may want to increase letter spacing for small caps only slightly, starting with
letter-spacing: 0.01em. Adjust the value until the black-and-white balance of small caps matches with that of the rest of body text.
Motivation
Using small caps for abbreviated words (e.g., HTML, CSS) is one of those typographic details that are standard in print media but not for websites. For the best "user experience", however, web designers/developers should adopt it. There are at least three reasons.
First, uppercase characters are bigger than the rest, and a bigger size conveys emphasis (and also YELLING!). But abbreviated words are not necessarily what the author wants to stress, especially if they appear repeatedly in text. The author's intention can consequently be misunderstood by the reader. It is a bad user experience where the reader is the user of a webpage.
“Regular uppercase letters jump out and yell, creating undue emphasis on words such as acronyms.”—(Shoaf 2021, checkpoint #37)
Second, abbreviations in uppercase characters will interrupt a smooth flow of reading sentences which mostly consist of lowercase characters. It is again a bad user experience.
“Small caps are designed to reduce the size of imposing capital letters in a balanced way, so that they don’t disrupt running text.” —Brown 2018, chap. 4
“Small caps create a better reading experience compared to regular uppercase letters because they blend in and flow with the rest of the text”—(Shoaf 2021, checkpoint #37)
Finally, since it's a standard practice in books, newspapers and magazine articles, abbreviations in small caps can make web articles look more professional. (This is my personal opinion.)
Once you're convinced that we should style abbreviations with small caps, however, it's not immediately clear how to code it. The information is scattered around on the web. As part of my ongoing effort of perfecting web typography, I've written this article to put everything together in one place about abbreviations in small caps for web articles, with sources of information clearly indicated.
(A screenshot of Line-height Picker, an app that I’ve built. See how the term CSS, rendered in small caps, blends into the rest of the text.)
1. Marking up in HTML
In the HTML document, wrap abbreviations with <abbr> like this:
5:00<abbr>pm</abbr>
But there are exceptions
There are a few types of abbreviations for which we should not use small caps.
The first type is two-letter geographical acronyms (e.g., Washington DC, state names such as NY), and the second type is acronyms for personal names (e.g., JFK) (Bringhurst 1996 p. 48).
So the abbreviations should look like this (image source: Rutter 2019):
Why not <acronym>?
In old days, there was an HTML element called <acronym>. But it is deprecated with the arrival of HTML5 (Leadbetter 2010).
Why <abbr> instead of <span>?
The use of <abbr> is simply for the sake of applying different CSS declarations to them from the rest of paragraphs. As far as I understand, using <span> instead doesn't have any practical consequences. It's just that <abbr> is more semantic than <span>. W3Schools used to say, “Marking up abbreviations can give useful information to browsers, translation systems and search-engines” (W3Schools 2018), but this sentence has been removed since then (W3Schools 2021).
Updated on 28 April, 2021: As a comment to this article, InHuOfficial 2021 explains two benefits of <abbr> for screen reader users:
“
<abbr>has a dual purpose for screen readers. First it lets them know this is an abbreviation so it can announce it as such. Second it lets the voice synthesis part of the screen reader know to read it as an abbreviation rather than a word. This is the key difference between an<abbr>and a<span>.”
The title attribute may be unnecessary
Every discussion on <abbr> involves the user of the title attribute. As far as I see, the only benefit from using <abbr> is that its title attribute will activate a tooltip so the mouse users can see what the abbreviation stands for by hovering over it:
“The global title attribute can be used in the tag to show the full version of the abbreviation/acronym when you mouse over the element.” —W3Schools 2021
Clearly, this functionality is not available for mobile device users. Making it work for touchscreens requires up to 50 lines of JavaScript code (Coyier 2019).
The title attribute for the <abbr> element doesn't change how screen readers read out the abbreviations by default. The user can configure a screen reader to read the title attribute value.
“...screen readers usually just read out the element content. ... You can set up the screen reader to read the title content, but it's an opt-in setting ... There's really no way to set content for a screen reader with title.”—Li 2017
Still, I don't really see the value of adding the title attribute.
For common abbreviations such as AM and PM for time or BC and AD for years, there is no point of explaining them as ante meridiem, post meridiem, before Christ, anno Domini. Indeed I just learned these phrases. :-)
For uncommon abbreviations (e.g., technical terms in a document written for non-experts), the standard practice in print media is to define it when it first appears in the document and use them without explanation afterwards. And I don't see what's wrong with it.
But not everyone agrees (see a comment to article by InHuOfficial 2021, for example). If you go with the title attribute, a code example is as follows (taken from W3Schools 2021):
<p>The <abbr title="World Health Organization">WHO</abbr> was founded in 1948.</p>
2. Checking the availability for small caps
Fonts with no small caps
The font you have chosen may not contain small cap characters. In this case, applying CSS declarations for rendering small caps will yield an ugly result as browsers “fake” small caps:
(Roboto with fake small caps whose letter stroke widths are inconsistent with full caps. Image source: loominade 2016)
All typographers disdain fake small caps.
“Genuine small caps are not simply shrunken versions of the full caps. They differ from large caps in stroke weight, letterfit, and internal proportions as well as in height. Any good set of small caps is designed as such from the ground up. Thickening, shrinking and squashing the full caps with digital modification routines will only produce a parody.”—Bringhurst 1996, p. 48
“Do not scale down full caps ... They will look odd and fake next to lowercase text.”—Truong 2019
“Pseudo small caps are easy to spot—they look thin and spindly compared to the surrounding letters.”—Shoaf 2021, checklist #37
“Software creates pseudo small caps by shrinking down normal caps to the approximate x-height; the resulting letters look starved and sickly because their weights don’t match that of their brethren.” —Lupton 2014
If you really need to use a font that doesn't contain small caps, it's better not to use small caps for abbreviations. Go with full caps.
Fonts with small caps as an OpenType feature
If your font supports small caps, these characters are available as an OpenType feature. To activate this feature, you need a set of special CSS declarations to apply to the <abbr> elements. We will discuss this in the next section.
In the case of using Google Fonts, however, it's a different story…
Fonts with small caps as a separate font family
If you use a font with small caps from Google Fonts, small cap characters are available as a separate font family. For example, Alegreya has a small cap family called as Alegreya SC.
Apparently, Google Fonts disables the OpenType feature for small caps (Leatherman 2018, de Mattos Neto 2020), presumably for the purpose of shortening the time for browsers to download font files.
In this case, you just need to add the small cap family to the <link> tag for loading Google Fonts and apply the font-family CSS property for <abbr> elements.
Of course, there is a cost: the user needs to wait for downloading an additional font file to see abbreviations in small caps. This may or may not be worthwhile:
“Loading a separate font file just to implement small caps may not be worth it on the web. I tend to only use OpenType small caps on my sites.”—Shoaf 2021, checklist #37
3. Activate the OpenType feature for small caps
If your font supports small caps as an OpenType feature, activating it requires either of the following two CSS properties: font-variant-caps and font-feature-settings.
font-variant-caps
Up until very recently, the browser support for font-variant-caps is limited. Consequently, everyone seems to recommend using font-feature-settings as a fallback, even though MDN Web Docs recommends otherwise:
“Whenever possible, Web authors should instead use the
font-variantshorthand property or an associated longhand property such as ...font-variant-caps... These lead to more effective, predictable, understandable results thanfont-feature-settings, which is a low-level feature designed to handle special cases where no other way exists to enable or access an OpenType font feature. In particular,font-feature-settingsshouldn't be used to enable small caps.”—MDN 2021
As of March 2021, however, 93.06% of global page views are compatible with font-variant-caps (Can I Use 2021). If you can forget about legacy browsers such as IE, use the following CSS code:
abbr {
font-variant-caps: all-small-caps;
}
and all the abbreviations wrapped in <abbr> will be rendered in small caps.
Rutter 2019 recommends adding to the above code font-style: normal because “vanishingly small numbers of fonts provide italicized small caps.” See if this happens with your font file.
There is an alternative declaration font-variant-caps: small-caps, which turns only lowercase characters into small caps. I don't think this is useful for abbreviations which are best written in uppercase characters for readability in HTML documents. Plus, with this declaration, “some older browsers will even override the proper OpenType small caps and replace them with pseudo small caps” (Shoaf 2021, checklist #37).
In case your font doesn't support small caps, then the font-variant-caps will force browsers to fake small caps (Leatherman 2018). As discussed in the previous section, this should be avoided. This is why we should forget using CSS if the font doesn't support small caps.
Font-feature-settings
To support legacy browsers, use font-feature-settings as a fallback. But its implementation is quite tricky. What Adobe Fonts 2021a recommends is as follows:
abbr {
font-variant-caps: all-small-caps;
-moz-font-feature-settings: "c2sc", "smcp";
-webkit-font-feature-settings: "c2sc", "smcp";
font-feature-settings: "c2sc", "smcp";
}
The c2sc value turns uppercase characters into small caps. The smcp turns lowercase characters into small caps. For the purpose of dealing with abbreviations, we don't need smcp, but it's just for making it consistent with the behaviour of font-variant-caps: all-small-caps which turns every character into small caps.
This code will behave as expected. However, what browsers actually do is to override font-variant-caps with font-feature-settings, even if the order is reversed(!):
“Because
font-feature-settingis a low-level property intended “for special cases where its use is the only way of accessing a particular infrequently used font feature” it will overridefont-variantregardless of source order. ”—Adobe Fonts 2021b
This fact is also pointed out by Leatherman 2018.
If we want CSS code to reflect what we really mean (i.e., using font-feature-settings as a fallback), therefore, a suggestion by Brown 2018 makes more sense:
abbr {
font-feature-settings: "c2sc", "smcp";
}
@supports (font-variant-caps: all-small-caps) {
abbr {
font-variant-caps: all-small-caps;
font-feature-settings: normal;
}
}
Without font-feature-settings: normal inside the @supports block, the font-feature-settings will keep overriding font-variant-caps. Setting it to normal stops this overriding behaviour.
But this code is more complicated and difficult to understand. So we should follow the previous one.
An extra care needs to be taken for using font-feature-settings when you use other OpenType features for all text, such as kerning. Since font-feature-settings overrides itself (Adobe Fonts 2021b), these other OpenType features stop being applied to the <abbr> elements if we just say font-feature-settings: "c2sc", "smcp". So if you use, say, the kerning OpenType feature throughout the text (which is activated with font-feature-settings: "kern"), your code for abbreviations should be like:
abbr {
font-variant-caps: all-small-caps;
-moz-font-feature-settings: "kern", c2sc", "smcp";
-webkit-font-feature-settings: "kern", "c2sc", "smcp";
font-feature-settings: "kern", "c2sc", "smcp";
}
All this drives web developers nuts. I guess that's why MDN 2021 recommends to use the font-variant-caps property instead of font-feature-settings, as mentioned above.
With today's good enough browser support of font-variant-caps, we should probably forget about supporting legacy browsers and let those old devices show abbreviations in full caps. It's in line with the principle of “progressive enhancement” (originally proposed by Champeon 2003, reinterpreted for 2020 by Steiner 2020).
4. Letter Spacing
Typographers recommend increasing space between letters for small caps, only slightly.
“Letterspace all strings of capitals and small caps ... Acronyms such as CIA and PLO are frequent in some texts. So are abbreviations such as CE and BCE or AD and BC. The normal value for letterspacing these sequences of small or full caps is 5% to 10% of the type size.”—Bringhurst 1996, p. 30
“Also, letterspace small caps very subtly, using ems so the spacing scales with font size. A little will do, like
letter-spacing: .01em.”—Brown 2018, chap. 4
The reason is:
"The extra space helps small caps breathe, and better matches the black-and-white balance of body text.”—Brown 2018, chap. 4
But some fonts have already adjusted the letterspacing of small caps:
"The small caps of some fonts already include built-in spacing, so you may not always need to add additional spacing."—Shoaf 2021, checklist #32
So judge by yourself if abbreviations in small caps appear a bit too blackier than the rest of text. If so, start with
letter-spacing: .01em
and adjust the value until the black-and-white balance evens out, without abbreviations breaking into individual small cap characters.
Summary
First, wrap abbreviations with the <abbr> tag.
If your font supports small caps as a separate font family, simply set it as the value of the font-family property for <abbr> elements. For the best performance of loading fonts, you may not want to do so, though.
If your font supports small caps as an OpenType feature, apply CSS to <abbr> elements as follows.
abbr {
font-variant-caps: all-small-caps;
letter-spacing: .01em; /* If black-and-white balance adjustment is necessary; tweek the value as you wish */
/* Skip below if you decide not to support legacy browsers */
-moz-font-feature-settings: "c2sc", "smcp";
-webkit-font-feature-settings: "c2sc", "smcp";
font-feature-settings: "c2sc", "smcp";
/* If you use other OpenType features such as "kern", don't forget include them in these declarations */
}
If small cap characters are unavailable, forget about these CSS declarations to avoid fake small caps.
Using small caps for abbreviations is not common on the web, probably because this typographic practice is not widely known among web designers/developers (I didn't know it until recently, even though I should have been familiar with it from reading books and magazines in print). But now you know about it with the rationale behind it.
Another reason for its rarity may be that most web developers think it's not worthwhile the effort of dealing with the tricky nature of the font-feature-settings property as described above. Given almost the universal adoption of the font-variant-caps property by modern browsers in 2021, this is no longer the case. We should revive this typographic practice for web media.
If you agree, always refer to this article for how to implement it with HTML/CSS.
Footnote: Other use cases of small caps
All these CSS techniques for small caps can also be used for lead-ins (the first few words of the very first paragraph; see Strizver 2015 for examples) as well as subheads and bylines (as suggested by Shoaf 2021). For these cases, however, font-variant-caps: small-caps is more appropriate to keep full capital characters intact.
Changelog
v2.0.0 — The title of the article has changed from “Abbreviations in small caps—the definitive guide for web developers in 2021” (May 1, 2021)
v1.1.0 — Part of a comment by InHuOfficial 2021 to this article is incorporated (Apr. 28, 2021)
v1.0.0 — The first version published (Apr. 27, 2021)
References
Adobe Fonts. (2021a) “Syntax for OpenType features in CSS”, Adobe Fonts User Guide.
Adobe Fonts. (2021b) “Using OpenType features”, Adobe Fonts User Guide.
Bringhurst, Robert. (1996) The Elements of Typographic Style, 2nd ed., Vancouver: Hartley & Marks.
Brown, Tim. (2018) Flexible Typesetting. A Book Apart.
Champeon, Steve. (2003) “Progressive Enhancement and the Future of Web Design”, hesketh.com, Mar. 21, 2003.
Coyier, Chris. (2019) “Revisiting the abbr element”, CSS-Tricks, Feb. 7, 2019.
de Mattos Neto, Jose. (2020) “A comment to ‘How to get true small-caps from a webfont from Google-fonts’”, Stack Overflow, Jul. 8, 2020.
InHuOfficial. (2021) “A comment to ‘Abbreviations in small caps—the definitive guide for web developers in 2021’”, Dev.to, Apr. 27, 2021.
Kramer, Jen, and Erika Lee (2021) “#30DaysofHTML Day 7: ”, 30 Days of HTML, Apr. 8, 2021.
Leadbetter, Tom. (2010) “The abbr element”, HTML5 Doctor, Nov. 30, 2010.
Leatherman, Zach. (2018) “Coded up a better test case showing real versus fake small-caps support...”, Twitter, Dec. 11, 2018.
Li, Andrew. (2017) “An answer to ‘How do screen readers read tags?’”, Stack Overflow, Aug. 19, 2017.
loominade. (2016) “Web fonts that support small-caps?”, Stack Overflow, Oct. 17, 2016.
Lupton, Ellen. (2014) Type on Screen: A Critical Guide for Designers, Writers, Developers, and Students, Princeton: Princeton Architectural Press.
MDN (2021) “font-feature-settings”, MDN Web Docs, Mar. 16, 2021 (last updated).
Rutter, Richard. (2019) “3.2.2 For abbreviations and acronyms in the midst of normal text, use spaced small caps”, The Elements of Typographic Style Applied to the Web, Jan 16, 2019 (last updated).
Shoaf, Jeremiah. (2021) Flawless Typography Checklist.
Steiner, Thomas. (2020) “Progressively enhance your Progressive Web App”, web.dev, Jun. 29, 2020.
Strizver, Ilene. (2015) “Designing with Lead-ins”, Creative PRO, Sep. 2, 2015.
Truong, Donny. (2019) “Discerning Typographic Details”, Professional Web Typography, 2nd edition.
W3Schools (2018) “HTML Tag”, w3schools.com, Dec. 11, 2018 (archived by Internet Archive).
W3Schools (2021) “HTML Tag”, w3schools.com.
Top comments (3)
A great article but in all that research accessibility didn't seem to crop up much....that is very worrying! So to fill in a few gaps that the articles you have read seem to have missed:-
<abbr>has a dual purpose for screen readers.First it let's them know this is an abbreviation so it can announce it as such.
Second it let's the voice synthesis part of the screen reader know to read it as an abbreviation rather than a word.
This is the key difference between an
<abbr>and a<span>.Also this is why the
titleattribute is useful (about the only time I would encourage use of the title attribute!) as screen readers can read the title out on abbreviations, so don't leave it off.Better yet using
aria-labelwill have better screen reader supportAlso you should include the whole phrase the first time you use it.1
As for the main premise of the article
Really interesting look into small caps - but as for using them for abbreviations...I would not (yet again for accessibility).
Small caps will be very confusing for people with dyslexia (for example) where differences in letter heights are essential to help legibility - small caps means your capitals end up looking the same size as smaller letters.....
You may find these resources useful:
H28: Providing definitions for abbreviations by using the abbr element
MDN abbr tag (much better resource than W3 schools)
I mean, there are even better ways to handle abbreviations such as creating a glossary / dictionary of terms, but this comment is already massive so I won't weight the merits of different approaches 😋:
Linking to definitions
for example
Using the whole phrase first time an abbreviation is encountered: Providing the first use of an abbreviation immediately before or after the expanded form - W3 ↩
Thank you very much for your comments, @inhuofficial !
My issue with the
titleattribute is that it gives a different user experience between sighted users and those screen reader users who configure it to read thetitleattribute value instead of text content.Take this as an example:
Sighted users don't see the
titleattribute value (only mouse users can see it if they dare to hover over it). They read "WHO". Screen reader users read it as "World Health Organization". The purpose of abbreviation is to take less time to understand what a phrase means. Screen readers will keep hearing a long phrase of "World Health Organization".Using
aria-labelwill force screen reader users to hear this expanded phrase, rather than leaving it up to their choice, becausearia-labeloverrides text content (Watson 2017).Is this accessibility? My gut feeling says no. Correct me if I'm wrong.
I feel that the
titleattribute assumes that (1) sighted users (subconsciously) read an abbreviation like WHO as "World Health Organization" every time they see it and (2) the purpose of abbreviations is to save space. But this assumption is wrong, at least for common abbreviations. It's so common to hear WHO these days so "W H O" acquires its meaning. Some people probably don't even know what it stands for (but they know what it is), just like I didn't know what AM and PM stand for.As for small caps, do you know any hard evidence that people with dyslexia find it difficult to read, if it's used for abbreviations such as WHO? Like researchers asking people to read two versions of text, one with small caps, the other without, and comparing how quickly they understand the text.
I will do you one better, I will write my next article on abbreviations, I may have led you down a rabbit hole you don't need to follow as there are much better ways to handle abbreviations and I was trying to keep my comment short(ish!).
I agree on
titleetc. and the issue witharia-label- it was meant to be a "this is the best option for a quick way to reach WCAG AA level". Glossaries are far more useful and following a couple of rules makes it easy (like I said I will write a whole article on it as there is a lot of explanation even though it is simple and drop you a message when it is done!).As for small caps - I will admit it is based on general knowledge of how people with dyslexia tend to choose fonts with nearly twice as tall "large letters" such as "t, b" etc. over small letters "o, a" etc. as it tends to aid comprehension.
However I will also admit that thinking about it, the variation in fonts people prefer is large so me generalising that small caps may be confusing may not be correct. I would call it an "educated hypothesis" based on other research 😋.
Unfortunately I would imagine that research into small caps is lacking but I will have a look around!