sIFR 2.0: Rich Accessible Typography for the Masses

Today, a rainy and gloomy day in Stockholm, I thought would be a good day to talk about sIFR. Since the authors of sIFR (Mike Davidson and Mark Wubben) have written extensive and thorough explanations themselves, I won’t write too detailed about it here.
Version 2 is also just released.

Other useful posts about it are sIFR by Dave Shea and How and when to use sIFR by Andrew Hume.

However, there are three things I want to cover; Why sIFR has arisen, the concept and my opinion about it.

 

Why

The different options for using typography on the web are extremely limited to a few basic fonts that can be taken for granted in the visitor’s computer. This has held ADs, Interface Developers and their likes back with fonts like Arial and Verdana. Enter sIFR.

The concept

Basically, it is:

…a method to insert rich typography into web pages without sacrificing accessibility, search engine friendliness, or markup semantics.

The code for this doesn’t lay in the XHTML/HTML file, it is done through a JavaScript and a Flash file. This results in that the code will look something like this: <h3>My heading</h3>. Then, the magic begins: if the user’s web browser supports/has JavaScript activated and the Flash plug-in, it replaces the heading (or several headings, if that’s the case) with a small Flash movie that draws in the text at the desired size but gives you the ability to have any font you want that is also anti-aliased.

For people without JavaScript capabilities or the Flash plug-in, it simply outputs the H3 as normal.

My opinion

All in all I think it’s for a very good purpose, and I really appreciate when people think outside the box. I’m also glad that they have thought of the accessiblity perspective on it, and that there’s no tampering with the XHTML/HTML. As the authors themselves state, it should be used with moderation, mainly for headings and similar elements.

A common objection is: “Why don’t you just use images whose text and size will be dynamically generated on the server?”.
Well, each image is a separate request to the server, and, as opposed to images, Flash movies generated through sIFR will scale accordingly to the font size the user has set in his/her web browser. The downside, however, to that is that it only scales when loading the docuemnt, not when the user resizes his font text on-the-fly. Personally, I use Ctrl+ or Ctrl- all the time in Firefox while browsing web sites that don’t have a font size I like. This is merely a guess, but I think many users surf that way, they don’t just have font-size large for every web page they visit.

Once can argue that you will reach a wider audience if you use images, since it is very likely that more user’s will accept images than JavaScript and Flash.
Images placed directly in the XHTML/HTML code also downgrades nice to screen readers if you use the alt attribute correctly.

Another alternative is using image replacement techniques through CSS.

What you choose is up to you. I prefer having options, and I will most likely choose using image replacement or sIFR totally depending on the situation and project.

One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *