One of the more common areas for designers to apply a custom font to a design is in the site headings. It is in their nature to stand out, making an attractive target for a custom type face. Developers have tried time and time again to come up with the best possible image replacement techniques to ensure that their documents retain proper accessibility while reaching the next level. A new and exciting method to obtain custom type became available and lots of people loved it; sIFR. sIFR gave designers an unobtrusive way to include any font under the sun in their designs, opening new doors for Web design. While sIFR has garnered quite a bit of attention and support, I have yet to see it implemented all that often.
A short history of custom type on the Web
We can all remember back to the days where finding bits of information about font requirements were found next to the screen resolution requirements as well as browser requirements. Many times, the fonts were supplied with a quick hyperlink and after a quick download, unzip, installation, and restart of your browser you were ready to go! Luckily, providing a requirement such as that seemed to be short lived (although you still run across the issue as well as browser and resolution requirements to this day). With the implementation of CSS, developers and designers had much more to work with and were now able to use more effective techniques in their designs.
CSS based image replacement
Using CSS image replacement caught on like wildfire and many designers use it in nearly all of their work. Personally, I find myself using the technique at least once in nearly every project I work on, including this website. There are many different methods used for image replacement, each with their own set of pros and cons. A great resource to read about and view examples of various techniques is a post on mezzoblue entitled Revised Image Replacement. A number of methods are detailed including a short description, code sample, and live examples of each.
During the second revision of this website, I had come up with a technique for image replacement that I hadn’t seen anywhere else. The details are included in the write-up, but essentially it was the best way I could find to not bloat the code with extra markup while retaining accessibility as best as possible. Instead of trying to hide any of the content in the first place, I attempted to camouflage it using the color of an image. Please read more about my latest take on image replacement.
What is sIFR anyway?
As taken from WIKI.NOVEMBERBORN:
sIFR (or Scalable Inman Flash Replacement) is a technology that allows you to replace text elements on screen with Flash equivalents. sIFR is the result of many hundreds of hours of designing, scripting, testing, and debugging by Mike Davidson and Mark Wubben. Mike, Mark and an invaluable stable of beta testers, supporters, and educators like Stephanie Sullivan and Danilo Celic of Community MX completely rebuilt a DOM replacement method originally conceived by Shaun Inman into a high quality cross-browser, cross-platform typography solution for the masses.
While requirements placed on the reader may be slightly overbearing, sIFR was developed in such a way where it will gracefully degrade for your readers. Am I mistaken in my observation that sIFR is not implemented as much as you’d think?
As with any story, there are two sides with both CSS based image replacement as well as sIFR as choices for custom type in headings. There are accessibility issues attached to image replacement, and user requirement issues when dealing with sIFR. Which do you think is the better choice and why?
P.S. I’ve ended posts with questions before in hopes of getting some opinion from readers as I value their opinion. I’m hoping that those of you who don’t normally write a comment after reading the article can find a few minutes to do so on this. I’m truly interested in the reaction other designers and developers have regarding the two techniques. Thanks a lot in advance!