I recently posted a somewhat personal post on my other blog that I wrote concerning “creative constraints.” And how a renewed interest in typography specifically has made me realize the value limit can play in my life.
Leading a life with creative aspirations foremost in mind hasn’t always been the most productive or fruitful of endeavours. Meaning at times it can be quite frustrating. Add to that a level of technical detail I seem to need to keep my interest piqued merely adds complexities to a situation that, if anything, would benefit from less difficulty rather than more.
But it would seem this interest in type, and web fonts in particular, will be quite the challenge for me going forward. There’s no shortage of nerdy details to occupy my mind with for years to come. I’m actually quite looking forward to it.
And if that wasn’t enough there is also this thing I’ve recently been made aware of called font icons. “Font icons are awesome.” But more to the point of this post today, they are “accessible” (but they come with some things to watch out for, hence the quotes). And that really makes my dorky side drool. Details, details, details…
Some background on Font Icons
For some background on Font Icons read A List Apart’s March article The Era of Symbol Fonts. But, I should state before moving on, short of briefly poking around in Adobe Illustrator — a vector drawing program (vectors, or more accurately lines, make up nearly the entire basis of these Font Icon things) — and exporting that drawing to a Scalable Vector Graphic (SVG), then importing said drawing to IcoMoon to get my Font Icon so I could do this with them (the email icon located at the bottom of the linked to page), I have virtually no other useful experience with Font Icons. However, I was asked to review the resulting research the Fluid Project conducted concerning their use of Font Icons going forward to see how what they found translates. Here it goes. But I do recommend those interested in implementing Font Icons to read their research. It’s very (read: impressively) thorough.
This is a really complex issue. One that I’m not at all shamed to admit I don’t have a comfortable grasp on fully understanding at the moment. Which does speak to the learning curve involved in using Font Icons. It can be challenging to wrap one’s head around, at least it was for me. And I’m still learning.
You may wonder, like I did, why the Fluid Project would be interested in exploring something such as Font Icons. Aren’t they looking for solutions to problems they don’t really have? Why aren’t people content standing still?
It’s a bit of both
Seriously, as with almost anything else there isn’t a simple yes or no answer.
Yes, with respect they already have a working solution for this issue in place with User Interface Options (UIO) (the feature on the top of each page on this site, should you be reading this in a browser, that lets a user accommodate the interface to suit their needs/ preferences better) specifically. Via lots of tiny raster images — which brings to mind why they weren’t using sprites, I don’t know for sure, so I’ll avoid speculating (it really doesn’t matter any more, keep reading). However in terms of efficiency, even with sprites, there is still an amount of “waste” inherent in the process. I’m of course referring to all the various images in their different “states” that they would need to give a user even the most basic visual feedback. Fonts Icons could potentially better serve this end.
Point being Font Icons are essentially no different than any other text on a webpage. Aside from being “custom” bits of representational graphic information, which suffer from much the same problems images pose (where accessibility is concerned, more below), but they, unlike raster images, are “stylable” with CSS — everything you can do with CSS and text you can do to/ with Font Icons, “change opacity, rotation, add strokes, gradients, shadows, etc.” And while I bring it up, yes SVG images can be styled with CSS in certain circumstances, but for reasons outlined in the Fluid Project’s research concerning SVG specifically, Font Icons are preferable.
With UIOs theming feature alone (changing the interfaces colours for contrast perceptibility), instead of having to create and maintain images that reflect specific theme changes you can inject some simple CSS code into your style sheet to reflect theses alterations with the single Font Icon.
Font Icons are scalable
And like with regular text Font Icons are scalable. They are directly tied to the page’s font-size property. So as the text grows, these icons grow and remain every bit as “crisp” as any other letter form surrounding them. In an age of hi-DPI displays and laying out webpages with ems (essentially meaning Font Icons are directly related to a users specific browser’s text size preferences) a web author/ designer/ developer can’t possibly know how a user is consuming their content, this can theoretically be a welcomed addition to any web creators tool kit.
Towards accessibility, using images can be a little tricky. But with some care viable alternatives can be offered. Just like using the alt attribute in your mark-up for your images, to offer users a text alternative to viewing the image, you can use some Web Accessibility Initiative Accessible Rich Internet Application (WAI-ARIA) code for adding visually hidden descriptive text to a Font Icons through the use of;
<div aria-label="Descriptive text describing the Font Icon" role="img"></div>
This solution was fleshed out (hat tip to Heidi Valles) and tested on a variety of screen readers (another hat tip to Heidi and Justin Obara), Job Access with Speech (JAWS), Non-Visual Desktop Access (NVDA) and VoiceOver. And in various browsers (Firefox, Chrome and Internet Explorer 8, 9 and 10) for non-presentational Font Icons. Apparently Firefox with NVDA, I believe, had an issue not voicing the descriptive text with the role="img" missing. But it worked once it went in.
The use of ligatures
Which brings me to the use of ligatures. This aspect of Font Icons is what I’m having the most difficulty understanding. But ideally, in efforts toward “accessibility,” this would be most desirable. In the sense using ligatures with Font Icons, as I understand it, is theoretically the text will remain text “underneath” the visual rendering. Meaning in a web browser the combination of characters will cause those individual characters to be replaced by a custom glyph, or a Font Icon in this case. Why should we care? Screen readers will read ligatured text as text and not glyphs.
But of course in practice using ligatures to implement Font Icons is still somewhat limited. Browser support is still sort of problematic. As far as Internet Explorer is concerned, as of this writing, only the current version (version 10) supports ligatures. Multiple language support, or in the very least, ways to create and edit ligature metadata (the information ligatures need to even display) for multiple languages is limited. And ligatures alone may not be descriptive enough to portray the intent of the Font Icon. As you are only allowed a single “word,” in the sense no spaces are allowed, in a ligature. But, that said, ligatures are pretty cool, indeed.
And with all this ligature talk spoken both the Fluid Project and in my limited experience using Font Icons we’ve both come to the conclusion the easier and more reliable way to use/ inject Font Icons into a web design is to use CSS rather than through the use of ligatures.
Wrapping it up
So if you skipped directly to this, the not so drawn out point I was getting at is if the Fluid Project has use cases for simple, monotone (but should it be appropriate Font Icons are “stackable” for the sake of more complex styling) icons they have made a pretty strong case to use Font Icons, through CSS (not ligatures), going forward. I’ll be extremely excited to work with the Fluid Project and Font Icons as soon as their proposal is implemented into reality…