Likewise, I don’t know if WCAG 2.0 will gain wide acceptance or if designers, developers, and bureaucrats worldwide will stick with WCAG 1.0. This chapter will concern itself with general principles of accessibility and with specifics of WCAG 1.0 and U.S. Section 508 (with occasional dollops of the WCAG 2.0 draft).
WCAG 1.0 offers three standardized levels of access, from the readily achieved (Priority 1), to one that requires slightly more work (Priority 2), to a master level (Priority 3). WCAG 2.0 also offers three levels.

The point of the three levels is that accessibility, like the other forms of standards compliance discussed in this book, is a continuum rather than an “all or nothing” affair. Your first CSS site might have imperfect semantics and might even use a table or two as a layout container, but you would at least be trying. Likewise, with a small and reasonable effort, any of useven those who are new to accessibility can attain Priority 1 conformance or something close to it.

In so doing, we’ll begin making our sites available to many of those whom we had previously locked out. In this chapter, we will cut through some of the confusion, dismiss cobweb-coated myths that befuddle many otherwise sophisticated web professionals, and provide a practical overview of common-sense, applied accessibility. We’ll also discuss tools that can help you incorporate accessibility into your design practice and point out the limitations of those tools.

No chapter can cover web accessibility in its entirety. Indeed, few whole books really get at the heart of the thing, even when accessibility is their stated subject. Some books on the topic contribute to designers’ confusion about or hostility toward access. Two books, however, do focus on accessibility in a designer-friendly way, and I’ll commend them to your attention in a moment.

(Netscape 4.5 rendered xx-small at six pixels three pixels below the threshold of legibility because Netscape’s engineers were following the W3C’s initial recommendation that each size be 1.5 times larger than the size below it. The W3C changed its recommendation to a gentler scaling value of 1.2 after seeing what Netscape had done.)
The Keyword Flub in IE/Windows.

Meanwhile, IE4/Windows, IE5/Windows, and even IE5.5/Windows got keywords wrong in a different way. In these browsers, there is a logical disconnection between the keyword and the way it is rendered. Small is medium, medium is larger than normal, and so on. How the heck did something that weird happen?

The engineers who developed IE for Windows were trying to do the right thing. Remember the seven tags of Netscape, mentioned in the beginning of this chapter? The IE developers mapped the seven CSS keywords directly to the seven Netscape font sizes. In many ways, it was a logical thing to do. Let’s give the team some credit for trying to support keywords in a way that would make sense to designers who had cut their teeth on Netscape font-size hacks.

Progress Happens, but Usage Eludes

Eventually, IE5/Macintosh, Netscape 6+, Mozilla, and IE6 got font-size keywords right. But by the time that happened, millions were using IE5 and Netscape 4, which got keywords wrong. If designers used CSS keywords as intended, the display would be off in IE4-5/Windows (and, less importantly, it would also be off in Netscape 4). If designers deliberately misused keywords to make the display look right in IE4-5/Windows, the display would be off in all other browsers and in later versions of IE/Windows. What could designers do? What most of us did was consider CSS font-size keywords to be just another option that didn’t work.

The Keyword Comes of Age: The Fahrner Method
You can read the evolution and details of Todd’s method in A List Apart’s “Size Matters” .

It works like this:
• Because 4.0 browsers don’t understand @import, they ignore the imported style sheet containing CSS rules they would only bungle. Let 4.0 browser users see text in the size they choose as their default, or if necessary, serve them pixel values in a linked external style sheet.

• Add a CSS rule with greater specificity to protect Opera from one of its bugs. (See the “Be Kind to Opera” rule in a discussion of the Box Model Hack.)

Even 11px type might be too small for some, depending on the font chosen (11px Verdana and Georgia get fewer complaints than 11px Times, for instance), the monitor size and resolution, the visitor’s eyesight, the degree of foreground/background contrast, and the presence or absence of distracting backgrounds. To a person who has less than 20/20 vision, the problem might be annoying. To one who is seriously visually impaired, it might be far worse than that.

There is also the occasional CAD engineer who likes to surf the web on his 4000 x 3000 32″ workstation monitor and pepper web design mailing lists with angry letters about flyspeck-sized text. If he actually wished to solve his problem, he could use a browser that supported Text Zoom or Page Zoom. If he preferred to use IE/Windows, he could switch on its option to ignore font sizes. He could even write a user style sheet like this one: html, body {font-size: 1em !important;}

But he would rather complain about his problem than solve it in any of these ways, because for him this whole thing is a religious issue. (He also complains that the magazines he subscribes to are filled with inane coverage of celebrities and their marital problems. And he dislikes peanuts, yet he keeps eating them.) As a designer, you are responsible for your users’ problemseven this guy’s.

The Font-Size Keyword Method
Little known and scarcely ever used, CSS1 (and later, CSS2) offered seven font-size keywords intended to control text sizes without the absolutism of pixels or the inheritance, cross-platform, and user option hazards of ems and percentages. The seven keywords appear next, and their meaning will be obvious to anyone who has ever bought a T-shirt :
xx-small

x-small

small

medium

large

x-large

xx-large

Why Keywords May Beat Them and the Percentages

As mentioned earlier, when you use ems or percentages, there is always the danger that their values will multiply, resulting in text that is too small or too large. By contrast, keyword values do not compound even when the elements nest.

If is small, is small, and is small, and p lives inside div, which lives inside body, the three small values do not compound (as ems and percentages do), and the result is still legible. Moreover, the result is still small (not x-small or xx-small). Ems and percentages compound. Keyword values do not compound.

If the CSS standard views pixels abstractly (remember that “average length of the web user’s arm” business), the makers of most browsers do not. They understand the pixel unit the way the rest of us understand it: as the smallest dot on the screen.
Thus, virtually all browsers, from the superb to the barely passable, support pixels the same way, and if you use px to specify your font sizes, you (and your users) will see what you expect in nearly every browser and on nearly every platform. As with any rule, there are exceptions: one sophisticated and vaguely troubling, and the other dumb and negligible.

When Pixels Fail in Opera
Some versions of the Opera browser consistently deliver smaller sizes than those specified. For example, if you specify 11px text, Opera 5 for Macintosh shows something closer to 10px. Håkon (pronounced How-come or Hokum) Lie (pronounced Lee) is Opera’s chief technical officer. He is also the father of CSS, to whom most designers with a lick of sense are grateful.

Some argued that Opera’s subsize handling of pixel values in its 5.0 browser for Macintosh was based on the “average arm length” abstraction. But it was just a bug.
When Pixels Fail in Netscape 4 Point Something or Other
Some versions of Netscape 4 also get pixel values wrong. In one or two incremental upgrades on one or two platforms, the old warhorse sometimes forgets how to interpret pixel units, as Grandfather sometimes forgets our names. Don’t ask me which versions of Netscape 4 get pixels wrong. Is it 4.73 for Linux/UNIX? Is it 4.79 for Windows 98? Who cares? Most versions of Netscape 4 get pixels right, even if they get practically everything else wrong.

This rare Netscape 4 pixel snafu has no basis in abstract theoretical concerns. It is simply a bugone that users can avoid by upgrading to the next incremental version of the ancient relic, or preferably to a browser released in this century. Some users won’t do it. One of them might be your boss or your client. If beating them about the head and shoulders with the nearest heavy object fails to enlighten them as to the benefits of a standards-compliant browser, start looking for a new job. (After beating your boss about the head and shoulders, you’ll have to look for a new job anyway. What were you thinking?)

Given these problems, pixels appeared preferable to ems and percentages. But if you used pixels to guarantee that all users initially saw the same size text relative to their screen resolution, the text size would not scale in IE/Windows, thus creating legibility and accessibility problems for millions.

I begged all browser makers to support the standard sizeand today they do. I also (here and behind the scenes, for years) begged Microsoft to let users of IE for Windows scale text set in pixels. One out of two ain’t bad.

A Passion for Pixels

Alone among all CSS values, with a few exceptions to be discussed next, the humble pixel (px) unit works in browsers old and new, compliant and noncompliant, on any platform you care to name. 13px is 13px whether viewed in Windows, Mac OS, or Linux/UNIX. Set your text in pixels, and it will look the same in any browser or on any platform.

The benefits are not limited to fonts. Images are created in pixels. If our product shot is 200px x 200px and we use CSS to specify a left margin of 100px, we know that the size relationship of picture to margin will be 2:1, and we also know that all users will see this size relationship. Size-based relationships are a key component of grid- and rules-based designs.

For crisp layouts, pixels are a natural. If we say that our headline text is 25px tall, that our left margin is 100px, and that our body text is 11px, all users will see the same thing, although the real-world size of what they see will depend on their PC’s resolution and their monitor’s dimensions.

Standards-compliant user agents make forward compatibility possible. If the web were still viewed mainly in Netscape and Microsoft’s 4.0 browsers, forward compatibility would be unattainable by all but the most rudimentary sites. If the leading user agents that succeeded 4.0 browsers had continued to promote proprietary technologies at the expense of baseline standards, the web’s future as an open platform would be open to doubt. Thankfully, all leading and many niche browsers released within the past few years can justifiably be called “standards-compliant.” But some are more compliant than others. Coping with compliance hiccups is what this chapter is about.

Embeddable Objects: A Tale of Hubris and Revenge

When the creators of the original Mosaic and Netscape browsers first seized on the brilliant idea of allowing designers to include images in web pages, they “extended” HTML by creating an tag specifically for their browsers. The W3C did not approve. It advised web authors to use the object element instead. But millions of websites later, the tag was still going strongand support for the W3C’s element was nonexistent.