Icon fonts [Was Re: <i>, <em> and font-style:italic in HTML 5]

Hi,

I did some research about the accessibility of icon fonts a while back. 

Ramón wrote:

> Anyway, the main issue with this use of <i> tags for icons is that they are usually left empty and the icon is inserted using some CSS background technique, which means that screen reader users and high contrast users receive no information at all.


That's not always true. Font-icons are inserted with the CSS pseudo elements :before or :after. Most (but not all?) screenreaders support CSS generated content. VoiceOver on Mac does. 
Every icon is matched to a unicode character. For example, I could insert a play-button (a right pointing triangle) with CSS using the letter "p" (data-icon="p"). That would look something like this:

HTML
<a href="#" data-icon="p" class="icon"></a>

CSS
.icon:before {
	font-family: 'Pictos Custom';
	content: attr(data-icon);
	}

VoiceOver and other screenreader that support CSS generated content, will read "internal link p". 
A possible solution would be adding hidden text for screenreaders that explains the play-icon.

HTML
<a href="#">
 <span data-icon="p" class="icon">
  <span class="visuallyhidden">play</span>
 </span>
</a>

CSS
.visuallyhidden {
  border: 0;
  clip: rect(0 0 0 0); 
  height: 1px; 
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;
}

Now VoiceOver will read "internal link p play". 
Better, but we're not quite there yet. We still need to get rid of the letter "p" that we inserted with CSS. 
Introducing aria-hidden. 

<a href="#">
 <span data-icon="p" class="icon" aria-hidden="true">
  <span class="offscreen">play</span>
 </span>
</a>

Now VoiceOver reads "internal link play". Note that this will only work with recent screenreaders with ARIA-support.

Adam wrote:
> Instead, I downloaded a custom icon set (I used IcoMoon) that only included what I needed.
> I then searched through the Unicode references to find proper, meaningful Unicode references whenever possible.
That's a strange approach in my opinion.
A Unicode reference (a letter, a number or a symbol) is rarely a meaningful alternative to an icon.
If you use font-icons for non-decorative purposes (play-button), add visually hidden text to explain the icon for non-sighted users, like in the example above.
If you use font-icons for decorative purposes, you would want screenreaders to ignore the icon entirely. Just like alt="" on decorative images in HTML.
Introducing Private Use unicode subset. 

There are many unicode subsets, for example Greek or Arabic or Arrows. 
http://www.utf8icons.com/subsets

When u insert an icon using a character from these subsets, most screenreaders will read them (unless you hide them with aria-hidden) as explained above.
Unicode also has a  "Private Use" subset.
http://www.utf8icons.com/subsets/private-use

These characters do not represent known symbols and therefore will not be read by screenreaders. Perfect for creating decorative icons.
Twitter bootstrap uses font-icons from the Private Use Subset:
http://getbootstrap.com/components/#glyphicons

One of the examples is an icon representing a magnifying glass which you could use in a search form. 

<span class="glyphicon glyphicon-search"></span>

Note that Bootstrap doesn't use <i> or another meaningful HTML-element, but <span>. Which is the right way to go if you ask me.
The magnifying glass is inserted with CSS :before

.glyphicon-search:before {
 content: "\e003";
}

"\e003" stands for Unicode U+E003 (private use subset): http://www.utf8icons.com/character/57347/UTF-8-character
Since this icon has meaning (search), we need to add some hidden text for screenreaders. Common accessibility problem.
No need for aria-hidden on the icon itself because it won't be read by screenreaders.

<button>
<span class="glyphicon glyphicon-search"></span>
<span class="visually hidden">search</span>
</button>
 
Hope this helps,

Gijs


---
Gijs Veyfeyken
AnySurfer - towards an accessible internet
A project of Blindenzorg Licht en Liefde vzw
Kunstlaan 24 box 21
1000 Brussels
Belgium
http://www.anysurfer.be/en




On 25-okt.-2013, at 10:46, Adam Powell <adam@adaminfinitum.com> wrote:

> I built my own website with Twitter Bootstrap and this bothered me enough that I customized it; here's my approach:
> Even if you use a version of the framework which uses font icons (sharp on any screen, at any resolution, as they are vector based) instead of CSS sprites chances are high you are loading a whole lot of unnecessary stuff, this slows your site down and degrades user experience, especially in the context of mobile.
> Instead, I downloaded a custom icon set (I used IcoMoon) that only included what I needed.
> I then searched through the Unicode references to find proper, meaningful Unicode references whenever possible.
> While I did use <i>, with data-attributes, I was able to find meaningful Unicode characters for the majority of icons (it was time-consuming, though).
> While I know the support for this is lacking, it seemed better than nothing so I gave all icons a descriptive 'title' attribute. 
> I welcome feedback on these techniques, I do a fair amount of front-end development and always try to bear accessibility in mind but I am pretty new to serious accessibility considerations.
> 
> I wasn't thrilled with using <i> elements but out of brevity stayed with it instead of <span>...I wish the spec. included something like <icon>.
> 
> Adam Powell
> Learn more at my website: Adam Infinitum 
> 
> 
> 
> On Thu, Oct 24, 2013 at 2:59 PM, Ramón Corominas <listas@ramoncorominas.com> wrote:
> I would say that the "common practice" argument is not an argument. The most common practice is indeed "to be inaccessible". There are many popular libraries that make even more weird uses of the HTML elements, but that doesn't mean that we will accept them because of the "common practice".
> 
> Anyway, the main issue with this use of <i> tags for icons is that they are usually left empty and the icon is inserted using some CSS background technique, which means that screen reader users and high contrast users receive no information at all.
> 
> The semantic of the <i> tag will probably not cause big issues, but if the screen reader user configures it to read the tag with a different tone of voice, his/her perception of the content might be a bit strange.
> 
> Cheers,
> Ramón.
> 
> 
> Thomas asked:
> 
> I have a follow-up question related with the use of the <i> tag. When testing a web site's accessibility, we found an extensive use of the *<i> tag **in conjunction with icons*, such as:
> 
> 
> <i class="icon-right-default icon-white"></i>
> 
> We raised an issue because we consider this use of the tag doesn't meet the defined semantics, but we were replied that this use of the tag is common practice, and that popular libraries such as Twitter Bootstrap use the i tag for this purpose and it has no affect on accessibility.
> 
> *Should this use of the tag be considered incorrect, or will the semantics of the tag eventually evolve to include this common use?*
> 
> 
> Thank you very much for your time. Regards,
> 
> 
>