Dingbat Webfonts: Great potential, but we see (and hear) accessibility issues

Posted by Scott on 08/17/2010

While working through initial ideas for the forthcoming jQuery Mobile framework, we were looking for ways to decrease page weight and image requests, and did some experimenting with using a custom dingbat font (crafted with the excellent FontStruct editor) to enable rich, vector-based icons for the mobile UI components that could be enhanced even further with CSS. Unfortunately, support for CSS @font-face (the web-standards-based mechanism for referencing custom fonts) on mobile is spotty at best.

But the idea of using fonts for icons excited us, and may perhaps prove to be a great solution for desktop browsers. For this reason, we were thrilled to see the release of Pictos, a beautiful dingbat webfont by Drew Wilson. The Pictos site includes several examples of the icons in play, and the results are stunning, particularly with various CSS3 styles applied, and while scaling the browser's text size. However, dingbat fonts map visual symbols directly to standard keyboard characters, and this raises some concerns for accessibility.

We see some definite accessibility challenges with the solution, and tried several work-around solutions, which we'll describe below.

It looks good, but how does it sound?

In our brief experiments, we found that using dingbat fonts introduce some accessibility issues. A dingbat font basically maps images to the standard character map, meaning when their used alongside content on a web page, sighted users will see an icon in place of certain alpha-numeric characters in the markup. However, for users on screen readers and other assistive devices, the base characters (capital and lowercase letters, numbers, and standard symbols) are still read aloud. For example, if a dingbat font replaces, say, the letter "A" with an arrow icon, a screen reader still reads aloud the actual letter, regardless of its icon appearance.

This would be slightly odd but not necessarily terrible for simple static content scenarios (say, decorative icons on section headers), but has the potential to become quite confusing in more functional sites and applications.\</>

For example, consider the scenario of an ecommerce site that adds icons to its checkout and cart buttons. Even with the most careful mapping, some of the common icons will correspond to letters or numbers that might cause confusion. What if, for example, the shopping cart icon were mapped to the number "6"? The markup to create a button with a shopping cart icon alongside its text (in this case, a span wrapped around a "6" character) in a "Purchase" button could look something like this:.

<button type="submit">Purchase <span class="icon">6</span></button>

While a visual user may see that "6" replaced with a nice icon of a shopping cart, a screen reader user will hear "Purchase 6", which is probably not what they intend to do, or what the site intends to say.

Possible solutions

While we've admittedly had little time to invest in this so far, we have explored a few techniques to either hide the dingbat text from a screen reader, or provide more meaningful context in its place. Here are some ideas we've come up with so far:

  • A meaningful title attribute. Applying a title of "image: shopping cart icon" communicates the visual experience in an audible manner, but may be a bit verbose. In brief testing, we found that this text was not read aloud in place of the "6", but it may still be useful in an alternate implementation.
  • Using role="image". Applying a WAI-ARIA role attribute with a value of image may be the best approach, particularly combined with either a title attribute (above), or an aria-label to serve as alt text. In testing in VoiceOver however, this didn't seem to prevent the text from being read aloud. Oddly, the image role wasn't spoken either, which may be a VoiceOver bug, or possibly because we've placed it inside a form control.
  • Using the :before CSS pseudo-element This interesting idea is the proposed technique offered on the Pictos site. By placing actual meaningful content in the span and utilizing a CSS :before selector to add the icon text, we may end up with a similar experience to the title attribute idea proposed above. Unfortunately, in a test on VoiceOver, we found that it spoke the generated character aloud, reintroducing the original problem.
  • Using aria-hidden. Applying an ARIA attribute such as aria-hidden="true" may hide the text from being read aloud, which may be ideal if the icon itself is not essential to the experience. In brief testing on VoiceOver, the screen reader spoke "HTML content" when it encountered the span, which wasn't really an improvement.
  • Using character entity equivalents We also attempted using unicode entities in place of alpha-numeric characters (such as a &#0054; in place of the "6"), but the letter was still spoken aloud as "6".

Browser Support Concerns

Of course, several of these solutions require an ARIA-capable screen reader, so a bullet-proof approach would likely require a combination of ARIA attributes and attributes from earlier standards, such as title.

Also, sighted users with browsers that don't support webfonts will likely see a non-icon character (such as an actual "6"), because the browser will simply render the character in the next available font in its stack. This issue is of particular concern on mobile devices, as many lack support for webfonts, but also on many older desktop browsers as well.

Help us figure this out!

We'd be interested in hearing your thoughts on using fonts this way, as well as suggested approaches to making them accessible. Please drop us a comment below!

Also, thanks to Jason Santa Maria for the inspiration to post this article!



Design the font so that the word “right arrow” combines to make an arrow, or some other semantic description.

Opentype contextual alternates support would obviously rule the day. “Home” could be replaced by a house dingbat.

Comment by Aaron Carambula on 08/17  at  01:37 PM

Just wanted to express my positive surprise when I clicked a link from a tweet and arrived here - using my iPhone. Never heard of you before, but love the simple and effective design here! Kudos!!

Comment by Hilde on 08/17  at  02:26 PM

@aaron: nice idea, but could it work with existing browser technologies?

@Hilde: Thanks for stopping by. Glad you like our mobile design!

Comment by Scott (Filament) on 08/17  at  02:38 PM

I know FF is down with some OpenType features, lemme whip up an experiment. More in a minute!

Comment by Aaron Carambula on 08/17  at  02:56 PM

I’ve been puzzling this over for a couple hours, and all I can think of is to create a new browser standard where one can set the character encoding of that font to some special ‘icon’ character set, so that it doesn’t attempt to render the specified character in UTF-8.

First off, though: what about embedding an SVG font into an image element with an alt attribute?

Comment by Michael Kozakewich on 08/17  at  03:08 PM

Hey everyone! Stoked on the great convo’s i’ve started with Pictos!!!
I’ll be checking back here to see if you guys come up with some innovative techniques. I’d love to ensure Pictos Font is on the forefront of the best practices for web fonts :)
Thanks so much everyone!! Excited!

Comment by Drew Wilson on 08/17  at  03:19 PM

@Aaron has a great suggestion but I am not so sure if the current browser technologies are capable of that. And if it means relying on JS, then we are back to square one.
@Drew I have added other issues and solutions (besides accessibility) in using Dingbat Fonts like Pictos for Icons in my Journal (http://tuhinkumar.com/journal/pictos/)

Comment by Tuhin Kumar on 08/17  at  03:23 PM

@Michael: that sounds like an interesting idea. If you make a demo, we’d be happy to test it out.

@Drew: Like we said on Twitter, great work on Pictos! It’s a promising technique that we’d love to be able to use ourselves if the accessibility issues can be worked out.

Comment by Scott (Filament) on 08/17  at  03:34 PM

OK, the ligatures extension was meant for FF 3.7, we’ll see how it develops.

My solution also shows that opentype contextual alternates might be a real problem for things like spam and SEO, since you could have fonts change out enitre words for others on render rather than in the markup. font-face security is the next horizon…

I think this discussion points to a general need for universal and high-quality support for SVG, and the need to apply font effects to them. Icon fonts are a smart way to work it for now but clearly vector images with alts would fit the bill best.

Comment by Aaron Carambula on 08/17  at  03:35 PM

Curious what the screen reader would read if the icon was mapped to a semantically valid Unicode character (like Jon Tan proposed on Twitter) instead of “6”.

Comment by Ian Storm Taylor on 08/17  at  03:56 PM

On the topic of semantically-valid characters, it looks like Drew’s icons are mapped to a letter that best represents them. The key is ‘k’, for example, the mail is ‘m’, and the shopping cart is ‘$’.

Comment by Michael Kozakewich on 08/17  at  04:10 PM

@Michael: while that is indeed nice for developer convenience, it doesn’t make the text any more meaningful when spoken aloud on a screen reader. Some icons in the font are mapped to numbers as well, such as a check icon mapped to the “2” character. If used as the icon in our example markup, the screen reader would speak “Purchase 2”.

Comment by Scott (Filament) on 08/17  at  04:16 PM

Is there a way for you to leverage ABBR?

<span class="icon"><abbr title="">6</abbr></span>

How does that render in a screen reader?

Sorry, don’t have time for testing, but figured why not post an idea and see if it creates any ideas.

Comment by Aubrey on 08/17  at  04:25 PM

Tuhin mentioned a page from Opentype in his post, where they make a characterset which has most of the letters blank, with the ‘W’ mapping to their logo.

So how’s this:
Make an icon set with most everything blank, and then put twenty-six icons in the capital spaces. Put the shopping cart in ‘C’, because ‘cart’ starts with ‘C’. In your shopping cart example, it could say “Purchase, go to shopping Cart” but the “, go to shopping art” would be blank, the “C” would be the shopping cart symbol, and you’d see “Purchase []” where [] is the symbol.

You’d be limited to twenty-six symbols, and each must be applied to the letter you’ll use to start its name (unless you don’t mind the text “caRt” or such).

How much overhead is there on a font? The blank spaces would have almost no weight, and there would only be twenty-six glyphs. Hopefully, that would be under 10 KB?

Comment by Michael Kozakewich on 08/17  at  04:39 PM

What about designing the font to not use human-readable letters, but instead some exotic codepoint in UTF8?

Using the Unicode Dingbat block[1] would be best IMO. Replacing one arrow with another won’t have any semantic issue. Also there are other blocks (there’s even one for drawing boxes in all its ASCII glory [2], another for geometric shapes [3], etc).

I think we could easily find Unicode codepoints similar enough for any icon we would need. In case there’s none, we could just use some rare one (say, the snowman? ☃


[1] http://en.wikipedia.org/wiki/Dingbat#Unicode_Dingbats (Unicode code points 2700-27BF)
[2] http://en.wikipedia.org/wiki/Box_drawing_characters
[3] http://en.wikipedia.org/wiki/Unicode_Geometric_Shapes

Comment by nachokb on 08/18  at  12:46 PM

That’s similar to what I was thinking, and would solve the problem where there are odd letters littering the content, but it doesn’t solve the problem of non-semantics.

In Drew’s demo for his pictographs, he shows a demo where the icons are used in a stand-alone way. A button with a gear on it for Settings, as on an iOS device, is one such example.

So really, we need a way to associate some sort of description with the icon.

Someone mentioned OpenType features, while I went so far as to fudge up the character set so we can invisibly describe the content.

Comment by Michael Kozakewich on 08/18  at  01:12 PM

@Michael, I would expect using either a title attribute (which should be the sanest solution though it’s not well supported right now as you found) or hiding through CSS, which would need more verbose markup:

<ul class="actions">
<li>✆<span class="description">Call</span></li>


Comment by nachokb on 08/18  at  01:25 PM

I would be worried that the font download might time out on poor connections, and then there would be some random character sitting there. Having an indented description helps screen readers, but not victims of poor networks. Maybe including the title at the same time would help those odd cases where the font times out.
It seems the title isn’t spoken, so they would work together.

Then there’s the cognitive load. Some icons are completely indecipherable; and so no matter what method you use, you should have a title anyway.

<ul class="actions icons">
<li>✆<span title="Call">Call</span></li>

.icons span{..text-indent..}

Comment by Michael Kozakewich on 08/18  at  01:38 PM

Wait, it would be more like
<li title="call"><span></span></li>

Comment by Michael Kozakewich on 08/18  at  01:43 PM


let me take it step by step,

1. This would need some sense on the part of the designer. This would make sense if, e.g. the font combining all our custom vector artwork takes less space than images used for the same effect, even using sprites (I imagine this is not hard to achieve, particular if need to use the same icons with different stylings). On the other hand, designing you own font isn’t as simple as creating a PNG with sprites,

2. the idea is to use similar Unicode glyphs to what we are trying to show, so it wouldn’t be so problematic if the original Unicode rendering is used momentarily; in any case it wouldn’t be pretty so it could be hidden,

2.1. furthermore, what about using some JS to add a class to body ondocumentready so you could hide them until everything is loaded? (artwork { display: none; }; body.loaded .artwork { display: auto; })

3. ref cognitive load, we’re assuming that this will be used with care and only when needed (mobile apps is an example). Someone who’s making bad decisions will make them with images or custom font dingbats… when it’s not needed, all of this icons should have clear explanations right by them,

4. yes, I had omitted the CSS; there should also be some @font declarations to make that dingbat use the custom font



Comment by nachokb on 08/18  at  01:54 PM

First, nachokb, I assume you’ve visited Drew Wilson’s Pictos page.

1. The vector artwork is almost certain to use less space than a similar PNG. Not to mention that it will have anti-aliasing pretty much for free, while PNGs need a separate channel.
Designing your own font, like designing your own icons, takes time and experience. If this takes off, people would start specializing in font-icons.

2. The idea is to use ANY symbol imaginable; not just the Unicode ones. I’m not sure Unicode contains a gear symbol, which is in heavy use lately.

3. I think it’s safe to assume the web is the web, and people will do whatever tutorials tell them to do, despite accessibility, including setting their sites to 960px and setting their body font-size to 12px.
It’s also hazardous to assume that certain symbols in wide use within one country will be recognized in another. This is why it’s imperative that we add textual titles or descriptive text.
I’ll usually mouse over icons in Microsoft Office to see what certain buttons do

Comment by Michael Kozakewich on 08/18  at  02:11 PM

not to mention that dingbats would scale perfectly antialiased (furthermore, would respect user’s preferences so if someone doesn’t like antialiasing it will respect that); furthermore, this would be the only way, today, of taking advantage of subpixel rendering! (though I believe Cairo, the engine Firefox uses, played with the idea of subpixel rendering of any shape—I think they even played with autohinting for arbitrary shapes).

While of course you would be using any symbol you desire, trying to find similar symbols in Unicode shouldn’t be that hard, and by “similar” I’m being willingly vague, so you can choose any symbol as most Unicode symbols don’t have any semantic baggage. For a gear symbol, you can use ⚙ [1].

The other comments apply to any approach to using icons.

[1] http://www.fileformat.info/info/unicode/char/2699/index.htm

Comment by nachokb on 08/18  at  02:43 PM

Unicode 5.0 encodes exactly 98,884 graphic characters on different planes. http://www.decodeunicode.org/

Comment by David on 08/26  at  03:21 AM

Wait, it would be more like

Comment by مسلسل طاش ماطاش 17 on 08/28  at  10:22 PM

hey guys. great article. i too was really hopeful for the :before pseudoclass technique using Pictos and i was almost positive it would work fine on screen readers without reading the generated content part. sadly, VoiceOver, unlike Jaws or NVDA, reads the glyph aloud.

here’s my test using a normal class and an HTML5 data- attribute:

.test {
padding: 5px;

.test[data-icon=s]:before {
color: red;
content: “S”;
font-family: “silkscreen-1”, “silkscreen-2”, monospace;
margin-right: 1em;

.generated-content:before {
color: red;
content: “S”;
font-family: “silkscreen-1”, “silkscreen-2”, monospace;
margin-right: 1em;


This has an icon
So does this


after spending the morning on 3 different screen readers, i’m exhausted. kudos to you guys for making a strong case for baking in accessibility.

Comment by Cris Necochea on 09/09  at  12:44 PM

combining Aubrey & nachokb solutions ?

* using <abbr title="an explicit text” class="dingbats">�</abbr>

where � is a glyph form the private Unicode pane and “dingbats” a CSS class with a @font-face rule.

→ treats the � dingbat as an “image”

The question is “How are the private pane’s glyphs read by screenreader?”. Does anybody know ?

another way to do this should be using as many monoglyph fonts as needed (~one per glyph), with only “blank” glyphs used: SPACE, NBSP aso.

Comment by eleg on 09/27  at  08:00 AM