Where are we at right now in terms of the best markup for using icon fonts? Let’s cover some options I think are currently the best.

You want the icon to enhance a word You want the icon to stand alone but still be functional or informational

And our major goals here are:

As good of semantics as we can get As little awkwardness for screen readers as possible

This ground has been treaded before, but I think the following techniques are a small step forward.

Enhancing a word

Let’s say we have a header like “Stats” and we want to set it apart from other headers on the page and emphasize it’s meaning. Semantic ideal:

<h2 id="stats" class="stats-title">Stats</h2>

Result:

So to get that icon in there (remember we’re talking font icons here, we can’t just pad the left and use a background) we’ll need to insert some content.

Using a pseudo element is tempting because 1) they aren’t read by most screen readers 2) we don’t need dedicated markup for the icon which is a semantic ideal. Unfortunately, VoiceOver on OS X does read the content of pseudo elements. (reference 1, reference 2) Well, perhaps “fortunately” as if I’m reading the spec correctly that’s what it is supposed to do. Pseudo elements just aren’t in the DOM and thus that probably makes it harder for third-party apps to do.

The good news is that if we use a bit of markup, we can use aria-hidden attribute to prevent it from being spoken.

One more dash of bad news, even with aria-hidden on the markup surrounding the icon, VoiceOver on OS X will announce “HTML Content” when in focus. #dammit.

But alas! We can still win here. If we combine the markup technique and pseudo element technique, we can insert the icon with no VoiceOver weirdness. And as a double-win freebie, this combined technique is ideal for keeping our CSS lean and mean as it requires no class-name-bloat and works well with the next use case we need to cover.

So the final markup for this becomes:

<h2 id="stats"> <span aria-hidden="true" data-icon="⇝"></span> Stats </h2>

And the CSS is:

[data-icon]:before { font-family: icons; /* BYO icon font, mapped smartly */ content: attr(data-icon); speak: none; /* Not to be trusted, but hey. */ }

Holy cow that’s easy eh? Notice we aren’t using a specific class name for the icon (e.g. like .icon-stats or something), we’re using a data-* attribute to hold exactly which character we want to insert. In our icon font, we map those special characters to the icon we want to use. I find this perfectly semantic and even future proof (you could always select uniquely down the line even if you change the character). But if you prefer class names, more power to you, that’s fine and doesn’t change this technique drastically.

We’ll cover mapping characters at the end.

Stand-Alone Icons

Say we have an icon that is a link or in some way functional, but it isn’t accompanied by any text. For instance, a shopping cart icon that you can click to go to your shopping cart. Hopefully that functionality is obvious visually, with some kind of rollover state or general design obviousness. But that functionality also needs to be audibly obvious.

Instead of crafting a totally new technique to deal with this (which I’ve dabbled with in the past) let’s lean on what we’ve already started. A span that inserts the character with a pseudo element, and text that sits right next to it that we kick off the page visually.

<a href="#rss" class="icon-alone"> <span aria-hidden="true" data-icon="▨"></span> <span class="screen-reader-text">RSS</span> </a>

We need very little in additional CSS, just a little usability fix applied via class, and a toolbox class for hiding the text but leaving it accessible.

.icon-alone { display: inline-block; /* Fix for clickability issue in WebKit */ } .screen-reader-text { /* Reusable, toolbox kind of class */ position: absolute; top: -9999px; left: -9999px; }

Hey, it works

View Demo

Update October 2012: I made a more proper demo comparing icon font usage with different techniques.

In VoiceOver, anyway. Would be great to hear from people who use other screen readers how this holds up.

Building / Mapping Your Icon Font

One “issue” in the world of icon fonts right now is that the majority of them available come pre-mapped to letters. Used with improper markup, the letters become “content” and a part of the semantics of the document. Or worse, read outloud by screen readers.

It almost never makes sense for an icon to be mapped to a letter. Instead, I recommend mapping icons to the closest unicode symbol you can find. For instance, mapping a heart icon to ❤ is a splendid idea. The meaning of symbols is rather relative anyway, so close counts and will be a semantic improvement immediately.

Even better, I like the idea of mapping icons to the “Private Use Area” of Unicode. As I understand it, this is exactly why it exists, to use for your own special characters. Mapped this way, you’re in no danger of the character being spoken by a screen reader. Unfortunately at the time of this writing icons mapped this way don’t work in even the latest Safari, so it’s not yet recommended. Here’s the scoop on the Private Use Area issues paraphrased from Keyamoon:

There is a difference between PUA (Private Use Area) and SPUA (Supplementary Private Use Area). The difference is explained a bit here. In my testing, PUA mapping works perfectly in all browsers. SPUA mapping borks in Safari only on Windows. The IcoMoon app only maps to PUA, which is recommendable at least for the short term future.

Here are the steps to follow:

Pick out an icon font. Go to IcoMoon and load it up (or use their icon set) Choose the icons you want.



Map them to the characters you want. Best to map to a relavant symbol or PUA.

Download the fonts/demo.

You can also use Pictos Server to do the icon-picking and mapping, but it only works with Pictos and doesn’t help you with choose symbols (you could copy and paste from here). It is a very nice set though and hosts for you and makes it very easy to existing sets without manually swapping out font files.

The Future

In the future, hopefully we can rely on speak: none; working perfectly everywhere so we can go back to using pseudo elements and perfect semantics.

Relevant