Assuming that youâve marked up the structure of your document with many well-meaning elements, weâll now turn to CSS to transform your well-organized outline into a multicolumned, colorful beauty. However, this is just the tip of the iceberg; of course, we focus on issues related to universal design. If you are new to CSS, check out a comprehensive CSS reference (anything by Eric Meyer or Christopher Schmitt).
One of the first concepts to introduce is units of measure, as they are a key component in designing a liquid layout. Early web designers were making the transition from print design to the Web. In print, you have fixed layouts that are precisely defined and staticâthey are âpixel-perfect.â But those designers had no control over which browser someone used, or the size of the browser window, or the size of the text, which meant that their pixel-perfect designs werenât very perfect.
As HTML and CSS evolved, designers realized they could create designs that would reflow to accommodate browser version, window size, and text characteristics. Instead of seeing everything as absolutely positioned, designers started thinking in terms of relative positions.
Thus, there are three ways to specify length: relative units, absolute units, and percentages. Here are the definitions from the CSS2.1 specification:[17]
The most commonly used units are em,
px, and percentages, and they are all relative to
something else (whether it be another length property or another
element) and reflow differently.
In terms of accessibility to users with disabilities, text size has become somewhat less of a problem recently. Firefox 3 and Internet Explorer 7 each adopted full-page zoom, a feature thatâs been in the Opera browser for years. This kind of zooming increases the size of every element on the pageâtext, images, tables, even Flash objectsâin contrast to the old model, on which only the text itself is magnified. MobileSafari uses this feature most often; itâs how users pinch and expand documents on the iPhone.
Of course, this shift isnât necessarily always an improvement. For example, if youâre a user who wants text to be twice as large, full-page zoom also doubles the column width, and depending on the kind of display, that could require users to scroll left to right, line by line through long passages of text. Thus, it is still important to set your font sizes using relative units so that users can override them without having to resort to zooming.
If you have used semantic HTML, thereâs not much that using CSS will do to break it. We wonât say much about positioning here, but we do have a lot to say about it and its effects in Chapter 8.
A great use of CSSâs ability to include images is background
images: they are decorative and donât need a text equivalent. However,
using background images for images that convey important information is
not a good idea unless that information is available in the text of the
page. General rule: if itâs purely decorative, itâs
cool to use CSS to include it; if the image conveys important
information, use the img element with
an alt attribute (see Chapter 3 for information about using the alt attribute).
Web content is reaching a turning point with respect to the treatment of text. In fact, there are two major changes that will have a near-term impact on text on the Web: full-page zoom and web fonts. During this transition, though, there will still be millions of users who arenât up on the new tech, so itâs important to look at what works now, and determine for yourself how to write your content so that you can transition without stress.
In the Firefox 2/IE 6 era, the zoom function of the browser caused the fonts to resize but not the remainder of the documentâs structure. The result was text that was often smashed together or short lines of chunky text in increasingly absurd layouts. To address this, it was recommended to design documents using CSS rather than tables and to use relative CSS units so that the document would resize along with (or around) the larger fonts. On the other hand, full-page zoom increases the entire pageâs dimensions, including images, tablesâyou name it. While we still emphasize using CSS for layout, itâs not strictly necessary for full-page zoom. CSS-based layouts will, however, come in handy when your page is transformed in mobile browsers.
Web fonts are another story. Due to a couple of unproductive attempts at web fontography, the Web has been limited to a small subset of the fonts currently available in TrueType, OpenType, or Adobe Type 1 format, to wit:
Times New Roman
Helvetica (or Arial)
Courier (or Courier New)
Verdana
Tahoma
Georgia
Trebuchet MS
Impact
In other words, this is the limited set of fonts that are common to both Windows and Mac operating systems. However, many *nix (Unix and Linux) machines do not have these fonts.
A lot of people havenât been very happy with this, and there have been many, many different attempts at trying to bridge that gap. Most of these were image replacement schemes that used CSS tricks to replace semantic HTML headings with images, ostensibly offering the best of both worlds. One of the first to take hold was Fahrner Image Replacement (FIR). The idea, named after creator Todd Fahrner, hid the heading text and replaced it with an image with the bitmapped text. Unfortunately, what was good for semanticists was not necessarily good for universal design. Namely, using FIR, screen readers no longer read the heading text at all.
Various other alternatives popped up, with various positive and negative effects. With image replacement, one big downside is that the images all have to be preauthored and sized to the area theyâre supposed to fill, making the approach fragile and time-consuming. With that in mind, Mike Davidson adapted a technique created by Shaun Inman, and Scalable Inman Flash Replacement (sIFR) was born.
The principal advantage of sIFR over image replacement schemes is that any heading can be rendered in nearly any antialiased font you like. It takes some configuring, with a separate style sheet and a JavaScript file you have to customize and embed, but once thatâs done, you can set, for example, every H4 to appear in red Trajan Pro. Better, if your users donât have Flash (such as, say, iPhone users), the heading itself degrades gracefully.
Alas, sIFR has its limitations as well. Like image replacement, when you select a span of text that includes a sIFR heading, the heading text wonât be included. Youâll need a copy of Flash and the font you want. And you donât want to use it for more than a couple headers per page, or you risk dramatically increasing the load time. That said, it works with screen readers, itâs pretty, itâs reasonably simple, and itâs much more fun than sitting in Photoshop, churning out GIFs.
But still, when thereâs a better way, use it.
For examples, documentation, and a support forum for the sIFR technique, read Mike Davidsonâs blog âsIFR 2.0: Rich Accessible Typography for the Massesâ at http://www.mikeindustries.com/blog/sifr/.
One approach to the limited number of fonts on the Web has been floating around almost as long as the Web itself. As early as 1997âthe golden age of the browser warsâembedded or downloadable fonts saw implementations in Internet Explorer 4 and Netscape 4. Naturally, as with much of the ingenuity of that era, they were incompatible with each other: Microsoft based its embedded fonts on OpenType, while Netscape partnered with Bitstream. For a long time, nothing happened, and eventually the wind was gone from the web fontsâ sails.
Today, thanks at least in part to a new CSS-support arms race, a new round of web font mania has arrived. Opera Software has announced support for the web fonts module of CSS3, published as a working draft in 2002 by the W3C. The developers of WebKit, from which Safari and Konqueror are drawn, have also announced theyâre working on web fonts, and Microsoft is rumored to be in the mix as well with Internet Explorer 8.
You may think that web fonts will finally make your life easier. But they wonât. Especially when youâre thinking about increasing your audience. Most mobile devices wonât ever bother to process embedded fonts in CSS. Itâs simply too much to ask of devices with limited bandwidth and processing power. Using arbitrary fonts has implications for readability as well, given that not all fonts are created equal, and many designers, to put it lightly, are not known for their restraint.
An even bigger problem, though, is internationalization. If your style sheet is ever going to be used with content in several languages, you will need to ensure that the fonts you select contain glyphs in all of those scripts (Japanese, simplified and traditional Chinese, Hebrew, Arabic, Indic scripts, and so on). One advantage of local fonts is that these issues have long ago been sorted out. Issuing just-in-time font selections will certainly expose the poor support in many otherwise very pretty fonts for scripts other than Latin.
Get Universal Design for Web Applications now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
