SVG, Icon Fonts, and Accessibility: A Case Study

In the digital world, graphical icons are used prominently—play buttons, social media links, warning indicators, and on and on. There are many maintenance, performance, and accessibility considerations when designing and developing icons—especially for the web—that makes something seemingly simple rather complex.

Let’s discuss a brief history of web icons, advantages and disadvantages of several development solutions, and how a particular web app uses them. Hyperlinked icons will be used in most code examples for purposes of consistency and also because that’s how the web app (Easy Chirp) uses them in the case study below.

Brief History of Web Icon Techniques

Images

A classic in-line image is a very accessible and robust method for displaying an icon.

Here’s an HTML example of an accessible linked image. It simply places the alternative text in the alt attribute. (Notice that the alt text conveys the target of the link more than the image itself.)

<a href="cat-toys.html">
    <img src="cat.jpg" alt="cat toys" />
</a>

Sprites

In the late 2000s, CSS sprites became a popular method for displaying icons and other images, mostly for performance reasons. A sprite requires a smaller total file size and less HTTP requests than using numerous independent graphic files. A sprite is a single graphic file with multiple images embedded within it; CSS background and positioning is used to display a single image at a time.

Sprites with some effort can be made mostly accessible, but there were issues with background images being removed in Windows High Contrast Mode (HCM). Also, many services that auto-generated sprites were not outputting code that supported accessibility.

Here’s an HTML example of an accessible linked sprite icon. CSS classes are used to create the visual icon with pseudo-content (:before or :after) and to visually hide the alternative text.

<a href="cat-toys.html" class="sprite-icon cat"> 
   <span class="visually-hide">cat toys</span>
</a>

Fonts

Then came icon fonts, somewhere around 2012. A major advantage of icon fonts is they scale very nicely; they increase in size with much better quality than raster images. Also, since a font icon is text, CSS can easily be applied to adjust the size and change the color. And since icon fonts aren’t used as background images like sprites, they are not removed with Windows High Contrast Mode.

Note: In Windows 10 (with Microsoft Edge), High Contrast Mode no longer removes background images. Also, Microsoft now provides two CSS media queries that can be used to explicitly enhance a design in High Contrast Mode—namely -ms-high-contrast media and -ms-high-contrast-adjust.

Below is an HTML example of an accessible linked font icon. Like sprites, CSS classes are used to create the visual icon with pseudo-content and to visually hide the alternative text. But in addition, ARIA is used to hide the character used for the font icon from assistive technology (so a screen reader doesn’t literally read the special character which wouldn’t make sense).

<a href="cat-toys.html">
   <span aria-hidden="true" class="font-icon-cat"></span>   
   <span class="visually-hide">cat toys</span>>
</a>

SVG

Recently, the use of SVG for icons (and general usage of SVG) has become much more prevalent. Since SVG icons are vector-based they scale beautifully, and even better than icon fonts since fonts are subject to anti-aliasing. SVG icons can be multi-colored (whereas icon fonts are limited to one color), and they can be animated.

Browser support for rendering SVGs is very good. But because browsers often don’t pass pertinent information to the Accessibility API, SVG is still spotty for accessibility particularly for assistive technology such as screen readers. They can usually be made accessible depending on the use case but not always–see my SVG accessibility test page for details. There are several other great resources on the topic such as the HTML slide deck Making SVG accessible by Léonie Watson.

Here’s an HTML example of an accessible linked SVG icon (an aria-label in the A element could also be used and is often a more pragmatic solution):

<a href="cat-toys.html">   
  <svg role="img" aria-labelledby="title-cat-toys" focusable="false" width="40" height="40"> 
  <title id="title-cat-toys">cat toys</title> 
  <path ... /> 
  </svg>
</a>

Easy Chirp and its icon usage

Easy Chirp is a robust and accessible web-based Twitter application that I first developed in 2009 (originally named Accessible Twitter). It was rewritten in 2013 with the help of Andrew Woods and a successful Kickstarter campaign.

As expected, the Easy Chirp interface displays a timeline of tweets. Each tweet provides a graphical icon that can be activated to perform an action on that tweet such as favorite, re-tweet, and quote tweet. There are also icons for actions regarding the tweet author such as viewing their timeline, sending a direct message, and viewing their lists. Icon fonts were implemented for these types of actions in the rewrite of Easy Chirp.

The icon controls also provided a tooltip (keyboard accessible of course) to clarify what the icon is for. This benefits all users but especially those who are new to Twitter or who may have a cognitive impairment. The drawback is that creating keyboard-friendly tooltips adds more code weight and complexity and doesn’t function very well on touch screen devices.

Recently for Easy Chirp, I decided to add visible text labels to the icons and remove the tooltips. Text labels added to icons benefits all users and is especially beneficial for accessibility.

SVG Issues

Since text labels were to be added to Easy Chirp, a larger question arose—should the icons also be updated to SVG? There are many reasons why SVG icons are arguably better than icon fonts. But when attempting to implement SVG icons, the main question was how to reference the SVG code.

One method to implement SVG is using an image element that points to an SVG file as the source. This is straightforward and great for accessibility but requires many HTTP requests, which is poor for performance. Inserting the SVG code directly in the HTML page is the current standard solution, but this adds considerable page weight to every web page (the entire SVG code block must be present inline in the HTML page, usually inserted right after the body element). The ideal solution is to leverage the USE element that can point to an external source—and it can be cached. Here is a code example:

<svg width="50" height="50">  
   <use xlink:href="../path/to/icons.svg#cat" />
</svg>

The problem here is support; Safari 6 and IE 6-11 and Edge 12 do not support this technique. Polyfills such as SVG for Everybody are available but this adds more code weight and requires JavaScript (which is particularly a problem for Easy Chirp because its goals include fast/light pages and no JavaScript requirement).

Implementing the USE element also complicates accessibility issues, namely, exposing the accessible name to the Accessibility API for screen readers to process. This is not applicable to the change in Easy Chirp since visual text labels will provide the accessible name of the icon.

Temporary Solution

For Easy Chirp I decided to keep the icon fonts, at least for now. Essentially, the text label was unhidden, and the tooltips were removed. Icon fonts are still a viable solution as they require only one HTTP request, easily adjust color for themes, and scale well. And if the supporting CSS doesn’t load the text labels are still present.

The addition of the visual text label also really helps the clarity of the icons. And since they’re links, they also provide a larger target area for users.

Tweet from Easy Chirp interface showing icon buttons including text label.

Below is the updated HTML code snippet from Easy Chirp. Notice that it’s the same HTML pattern as the font icon example above, except the text label is no longer visually hidden. The CSS was updated to adjust positioning and spacing.

<a href="/quote/918605930853408768">
  <span aria-hidden="true" class="icon-quote"></span>
   quote tweet 
</a>

An accessibility issue regarding icon fonts is that they can be overwritten by custom style sheets. A custom style sheet, or user style sheet, is a user’s CSS file that is implemented at the browser level in order to help legibility, particularly for those with low vision. Another issue with icon fonts is that they are not supported in some user agents such as Opera mini in extreme mode. But for both of these cases, since text labels are being added, the graphical icon is not required to comprehend the meaning.

About Themes

Both icon fonts and SVG icons can support style changes via CSS (SVG actually has many more capabilities here). This comes in handy for websites that provide multiple themes. Easy Chirp has two themes: a Light Theme (which is the default) and a Dark Theme.

Since a font icon is text, nothing additional is required to adjust the color for a theme; the CSS that theme style will also modify the font icon. Here’s the relevant CSS for the font icon links in Easy Chirp when the Dark Theme is invoked:

.theme-inverse a {
   color: #fff; 
}

Tweet from Easy Chirp interface showing the dark theme, white on black.

If SVG icons were to be implemented, the color of the icon can be modified with the following CSS.

.theme-inverse a svg.icon {  
  fill: #eee; 
}

Looking Ahead

I still plan to convert all icons to SVG in Easy Chirp in the not too distant future, but for right now they remain icon fonts. If the icon font doesn’t render, the control is still usable via the text label. Although using SVG may add considerable page weight (depending on how much they’re used) and may require a polyfill, it would certainly be a better experience for users with custom style sheets and users of Opera Mini in extreme mode.

Final Thoughts

Web design and development is it challenging industry. A lot of knowledge and effort must be made to create a user-friendly and accessible website, including something as seemingly trivial as an icon. With a lot of hard work I hope you find the icon solution that’s right for you and your website—at least for now.