Font Icon discussion continued

Justin Obara obara.justin at gmail.com
Thu Apr 18 15:17:40 EDT 2013


At this weeks community meeting we had a follow up discussion about our research into font icons. I'll summarize, below, but our research is also being collected on the wiki. 

http://wiki.fluidproject.org/display/fluid/Research+the+viability+of+using+icon+fonts+in+UI+Options

Please feel free to continue this thread by adding in new information, questions, and correcting any mistakes I may have made.

Thanks
Justin


Overview:
========

Pros:
Scalable (size, hi-dip screens)
Can modify with CSS (colour, shadows, etc.)

Cons:
Mono-tone
IE8 and IE9 do not support ligatures
Globally changing fonts could replace/remove icons
Adding/Modifying fonts not trivial, will likely need to rebuild the font family



Digging Into the issues:
==================

Mono-tone: 

Arash did some research into this. At the moment we are limited to mono-tone fonts; however he used some methods to create the appearance of gradient like effects through varying sized dots and/or lines. Another suggestion that came up during the meeting is to layer multiple font icons on top of each other to provide a richer presentation. Johnny provided an example of this http://conor.cc/posts/icon-stacks


Globally changing fonts:

Probably more of something to just be aware of and careful about when making changes. We were able to work around this in our UIO demo sprint through !important and specificity.


Adding/Modifying fonts:

We probably need to talk about this point some more, and how we will be breaking up fonts into families and etc. 


File sizes:

The more complex the icon the larger the size. In typical fonts individual characters are usually less that 1KB and the whole family around 100KB. Our font-icons are usually less that 5KB each. 


Ligature Support:

IE 8 and IE 9 don't visibly display ligatures, however the text itself is accessible. What this means is that it will not be rendered onto the screen, but an AT (assistive technology) would be able to read it.


Ligature vs PUA:

There are three basic methods for creating a font icon.

assign the icon to a common unicode character
assign the icon to a PUA (private use area) unicode character
assign the icon to a ligature (string of unicode characters)

PUA referes to the block of unicode characters reserved for 3rd party use. For example, Apple uses F8FF for their logo "".

http://en.wikipedia.org/wiki/Private_Use_(Unicode)
http://jrgraphix.net/r/Unicode/E000-F8FF

In our testing we've found that font icons built on top of PUA characters are not read by an AT. This is probably because there is no real representation that they could use for it. 

***Note: the obstacle course used for testing had an issue with displaying PUA font icons in IE8. They typically work in IE8 and may be a result of the method used to dynamically inject them into the test***

Ligatures and common unicode characters like "a" do get read by screen readers. Since ligatures are created off of a strings of text, they become tightly coupled with it. Making things like localization difficult. Furthermore, they only seem to support a single word and not phrases. 

There are four basic issues with ligatures.

hard to localize
may need more than a single word to describe the icon
multipurpose icons may need a different description in different contexts
e.g. undo / reset / back
browser support (i.e. IE 8 and IE 9)


Accessibility:

The benefit here is the scalability and possibility to easily modify colours (for contrasts). However, there are questions about their interpretation by screen readers. We have both the issue of needing to provide less information and provide more. When the font icons are used in a purely presentational aspect, we wouldn't want the AT interpreting it for a user. On the converse, when they do hold meaningful information, we want to make sure that the AT is provided with a complete description. With ligatures we were finding that both of these cases could fail. The AT will read the text value, even in cases where it was for presentation only, and sometimes the ligature itself did not hold enough detail to describe the full meaning of the font icon.

We have been and continue to explore options for providing richer text alternatives. For example using things like aria-label, or encompassing the font icon with other text in a <label>. We can also make use of PUA based font-icons to avoid ligatures being read.


Further Discussion Points:
=====================

Continue researching and experimenting with text alternatives for the font icons
Continue investigating issues from the test around PUA's in IE8
Think about how we'll assemble and share font icons between components
Research the use of svg icons vs font icons
What are the download file size implications of representing "the same" icon as a SVG or font icon?
Emeddability/stackability - is it as easy to composite multiple different "icons" as SVG or font icons?
How does the use of SVG interact with ATs - are there special issues relating to focus, announcement by screenreader, etc?
Performance implications, especially on mobile devices - these are sensitive both to download costs as well as CPU costs during rendering - are either or both approaches viable on a low-capability smartphone?
Visual fidelity - does a page containing SVG elements appear "solid" as it is zoomed, or does the SVG content appear to "lag" the main page in rendering?


Current thoughts:
=============

When to use:

We had a good discussion in the channel today about font icons vs svg and also came up with a good summary of when you'd want to use a font icon. 

I imagine we're basically saying "Icon fonts are useful for relatively simple images that can be viably represented using one colour (or a few if we find that the stacking technique works) and which likely need to be highly responsive to resolution, size, and colour thumbing changes on the fly."

And "For complex images, icon fonts are not likely appropriate. The use of SVG or multiple resolution-optimized raster images is preferred in these cases."

http://wiki.fluidproject.org/display/fluid/fluid-work+IRC+Logs-2013-04-18


How to use:

At yesterdays meeting, my recommendation on how we should approach using font icons was as follows.

Use PUA font icons, to avoid the various issues with ligatures
Provide a text alternative for non-presentational uses of font icons
use something like aria-label and etc.
Use class names as opposed to the data- attribute for adding the fonts
it will be hard to know what you are adding with the data attribute, particularly for PUA font icons
Font families for font icons should be applied as tightly as possible to the element which will hold it. Where possible, we should avoid mixing regular, non-icon characters with the ones which have icon representations.
good
<span class="addFont"> font icon </span>
bad
<div class="addFont> <span>font icon</span> other text </div>






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20130418/2cc7d4bd/attachment.html>


More information about the fluid-work mailing list