It's official: Level Access and eSSENTIAL Accessibility are becoming one! Read the Press Release.
Cartoon people constructing an app

The content CSS property is an interesting property used in conjunction with either the :before or :after pseudo-elements that can insert text, symbols, and images into a web page from a stylesheet.  This property presents a number of issues for developers who understand the importance of making sure their work is accessible to people who use assistive technology.  Assistive technology allows people to use the power of the Internet even if they happen to be blind, or if they have cognitive, motor, or visual impairments. Developing a website that is accessible is not only the socially responsible thing to do, but it will reduce risk, help people find jobs, and meet federal compliance requirements. Screen readers are a type of assistive technology that can read the contents of a web page to a person who is blind. It will make a tremendous difference in this person’s life if she has the ability to do something as simple as order her groceries online.

What the content property does

Stylesheets are usually used to control the colors, fonts, and layout of a web page. Using the content CSS property, developers and designers can ensure that certain symbols, images, or text always appear next to certain styles on the page.  You can read more technical details about this property on the Mozilla Developer Network. For the remainder of this article the symbols, images, and text inserted from a stylesheet will be referred to as “symbols.”

You might be able to guess where this could be useful on a webpage. This property can be used to make sure the TM (trademark) symbol always appears after a trademarked word or phrase.  This property can be used to put the symbol for the Euro next to a price of an item on a webpage. This property can also be used to make sure phrases have a fancy left quote and right quote.

Jon Hicks explains two other advantages of using the content property with icon fonts: less HTTP requests pulling in icon images, and better resolution of icon fonts in high-resolution displays.  We all want to do whatever we can to speed up page loads. And we don’t want our designers’ heads to explode when they see choppy images on their tablets. That just ruins everyone’s day.

But let’s look at this new property in more detail. The W3C states: “Authors specify the style and location of generated content with the :before and :after pseudo-elements. As their names indicate, the :before and :after pseudo-elements specify the location of content before and after an element’s document tree content.” So whatever is inserted into the page via the content CSS property appears after the document tree (also known as the DOM) has been loaded into the browser.

Now those of you who know a little bit about screen readers are probably having a moment of truth right now and/or a conniption. This is because screen reader software usually reads from the DOM that initially loads in the browser before the stylesheet is applied. The symbols that are inserted into the page using the content CSS property are generated symbols loaded after the DOM loads.  The screen reader will not announce generated content to the user who is blind — even if the user refreshes the screen reader’s buffer after the page loads. This can be a problem if the symbols inserted into the page are essential to understand the meaning of the page. If the content CSS property is used to insert a little smiley face, for example, it’s no big loss to the screen reader user if he doesn’t know it’s there. There are plenty of other smiley faces in other places on the Internet to thoroughly annoy him.

But if the content CSS property is used to insert important information, then we have a problem. As in the example mentioned earlier, what if the symbol is used to show how much something costs in Euros? It would appear on the page like so “Sale Price: €19.99”. The screen reader user will hear something like “Sale Price: 19.99” announced, but may not be able to figure out whether that means dollars or Euros or Pounds.

Screen readers make their best effort to guess when they encounter something new and unusual. In some cases the screen reader will guess by reading off a few random characters when it encounters these symbols. In most cases, the screen reader will simply not announce the symbols at all. If the attribute data-icon is used, the screen reader will read whatever the value of the data-icon attribute will be. Usually something like <i data-icon=”p”></i> will be announced simply as “p” when it may actually appear on the page as a little play button. This is not helpful.

But how does this content CSS property stand up in the presence of assistive technology? Well the good news is that it’s not a complete disaster, and the bad news is that there’s no one answer…which is sort of good since it allows a little flexibility and creativity.

So that’s the content CSS property in a nutshell. Here are few suggestions if you decide to use this property:

Ask yourself: could I see it if I couldn’t see it?

Some of these icons indicate visual cues like direction or color. Arrow icons are used to indicate links or point the user to another part of the page. In this case, you need to put yourself in the shoes of a blind person for a few minutes. Remember screen readers read a page from top to bottom in a linear fashion, and users who are blind are using the keyboard, not a mouse, to navigate through the page. How is a an arrow, even if it is announced as “Right Arrow” or “Left Arrow” or “Click on the orange arrow ”, going to help a person who cannot see? It’s not. It might be useful to hide icons like these using an aria-hidden attribute like so:

<i class=”icon” data-icon="p" aria-hidden=”true”></i>

This may be the way to go for all of these types of icons, since many of them are only for decoration or presentation purposes and for the following reason…

All screen readers are not the same

Some Unicode characters used to create these symbols have references associated with them. The symbol for a checkmark, represented in Unicode as 2713 is not announced as a checkmark when using the JAWS screen reader….sometimes. When using the Open Source screen reader NVDA however, it is announced as “Check.” Just because a particular Unicode character may have a reference such as “Check” associated with it, this is not consistently supported across screen readers. Even if it were, there is no way to know each screen reader would present the same information.  One screen reader could announce it as “Check” and another as “Checked”, so it can be taken out of context very easily.

Screen readers use different synthesizers to create the voices that read the page, and they have different adjustable settings and preferences that can cause differences in interpreting these unusual symbols.  Here’s just a sample of three popular screen reader software interpretations of the Unicode checkmark symbol mentioned earlier. I tested the common Unicode checkmark icon with reference data, and a camera icon without reference data from an Open Source icon font solution called Font Awesome.

Screen Reader Browser

Font Awesome
Camera Icon

Checkmark Icon

JAWS 14 Internet Explorer 9

JAWS 14 Firefox 24


NVDA 2013.2 Internet Explorer 9


NVDA 2013.2 Firefox 24


VoiceOver Safari 5.1.7


VoiceOver Safari iOS6

Avoid the <i> element

The <i> element was originally created to indicate italicized text with HTML. The advent of HTML5 has changed the meaning of the <i> element, since italics is a style that should be part of a stylesheet, not in the HTML. The <em> element conveys emphasis and works well for all screen readers. Paul Wallas writes: “‘Bold’ and ‘Italic’ are words that only make sense visually. The idea of developing towards non-visual user agents encourages the designer to think beyond basic visual design and development.” Many people are using it now, especially to render icons, but that doesn’t make it right. It’s interesting to note that this element once blurred the line between presentation and content in the past, using HTML to put in italicized text, and now it is being used as an ‘icon’ element in the present to put in funky symbols. A <span> element will probably do a better job, and has more flexibility in this case

Stay away from the data- attribute

There are a few articles out there that demonstrate a method to keep the symbols in the HTML code, instead of in the stylesheet. They all seem to use icon fonts and the data-icon attribute. It requires developers to use questionable CSS properties like speak, to put in all this extra code just to get a little icon to appear, do three backflips, then spin around twice, sacrifice a unicorn, and so on.  Is it really worth all that to get a little magnifying glass to appear?

Use off-screen text

Another solution would be to use off-screen text in conjunction with the content property. Off-screen is text that utilizes CSS so it is not visible to the sighted user, but is visible to screen readers. If you already have a CSS class for rendering off-screen text, this may be the way to go for you. Just put a textual description of the symbol in a span, and you’re done.

<i class=”icon”><span class=”offscreen”>Favorited item</span></i>


ARIA labels allow you to provide screen readers something to announce when they encounter the symbol. Like off-screen text, ARIA labels are not seen by the sighted user, and they are a little neater since they don’t require a separate element like a <span> in order to exist. Simply place the label on the element that needs a label. This is ideal in cases when useful text may not be near the symbol to explain its purpose.

<i aria-label=”Filter”></i>

Use HTML entities

Most screen readers don’t have an issue with HTML entities, and many of the symbols you want to use are entities with overwhelming support in a variety of browsers. And they scale for high-resolution displays without choppiness. Page load times with HTML entities is fast since it doesn’t require an extra request to the server — it’s part of the HTML code itself. Some developers may see this as old-fashioned, I know. Not as slick as the cool new web font look you say? Yes, yes, that may be true. Quick, clean, small, and efficient…definitely!

<p>&#x2730 My favorite item</p>

Remember those things called images?

Ask yourself: do these icons really save time and make my webpages more efficient? Can’t I just use a foreground image here with alternative text for people using screen readers? Will anyone except me notice this 10×10 pixel png is slightly choppy on a high-resolution screen? Am I just trying to do something ‘cool’ that really doesn’t help at all? How did I get here? Who am I?

If you’re like me it’s really hard to resist trying out shiny new CSS properties. But I personally don’t see the usefulness of this particular CSS property. It blurs the line between presentation and content, which means you may have to translate and/or update CSS when you update content. Also, if some users apply their own styles to the page, which some users may do to increase font sizes or make the page more readable, the symbols added by the content property will disappear. Changing the accessibility settings in Internet Explorer causes all of the Font Awesome symbols to disappear on a page, so sighted users will not see them at all if they choose ‘Ignore font styles on webpages’. See below.

IE accessibility settings windowIE accessibility settings window

I understand the usefulness of small icons such as these on smaller screens, but I don’t see the advantage of changing the icon in a CSS file over just replacing a plain old image file on the server.  Many images are flushd once loaded, so the gains in page load speed are minimal at best.  Just remember to add alternative text to your images and you’re set.


Using the CSS content property seems to cause more headaches for developers who care about accessibility. But I have also presented some alternatives here for developers who may be inheriting code or need to work within existing boundaries. Hopefully this article can help developers the most at the beginning of a project/redesign, so accessibility is part of the creation process, instead of the remediation process.

Special thanks to Scott McCormack, Jeremy Hartley, and Jonathan Avila.