Planning for Access: How You Benefit

September 12th, 2006

Access Serves You


Having trotted out the rationale behind many site owners’ sudden interest in accessibility, let me hastily add that fear of lawsuits is the wrong reason to incorporate access into your design practice. These enhancements open any site to new visitors and whose site could not use more visitors? Those locked out of other sites will be inclined to feel quite loyal to yours if you welcome them into it by making these adjustments to your markup.

If other online stores block disabled visitors and nontraditional device users and your store welcomes them, guess who will be selling to those customers, and guess who won’t be?

And don’t forget, the more accessible your site is to disabled visitors and nontraditional internet device users, the more available its content will also be to Google, AlltheWeb, and all the other crawler-driven search engines and directories that send visitors your way. Conversely, the less accessible your site, the less traffic it will draw from Google and its brothers.

Zeldman.com, A List Apart, and most sites designed by Happy Cog over the past few years rank highly in search engine results, not because we’re doing anything fancy, but because these sites are built with access-enhanced semantic markup.
Golly, I was trying to attain higher moral ground, and I still seem to have offered purely self-interested reasons for implementing accessibility.

Here are two more:

Implementing access enhancements can deepen your understanding of “design.” Considering things like tab order can take you beyond a vision of design as the decoration of surface appearance (”look and feel”) and into the realms of user experience, contingency design, and general usability. These are issues that web designers, information architects, and usability specialists think about anyway. Accessibility is just another aspect of considering how to best build our sites to meet diverse human needs.

Implementing access and honing a conformance strategy can sharpen your development skills and provide fresh perspectives you might never have considered otherwise. Learning the ways of WAI and the particulars of 508 (or any other legally defined access standard) will increase your value as a professional web designer, position your web agency as smarter and more clued-in than its competitors, and help your sites reach more people than ever before.

That is what every site owner wants and what every designer or developer strives for. Practicing accessibility will help your visitors reach their goals, yes; but it will also help you reach your own.

Posted in Web design | 1 Comment »

The Law and the Layout

September 12th, 2006

Images, CSS, table layouts, JavaScript, and other staples of contemporary web design are entirely compatible with 508 compliance; they simply require a little extra care. As this chapter progresses, we’ll examine some of what accessibility and Section 508 compliance specifically entails, and we’ll explore how you can use intelligent judgment and available tools to make your sites comply beautifully.
Tools of the Trade


If you use a visual editor to create web pages, several tools and plug-ins can simplify conformance with access guidelines:
• Firefox Web Developer Toolbar
This fabulous, free menu and toolbar for Firefox provides numerous web development tools, many of them ideal for quick accessibility testing. Toggle CSS styles on and off, temporarily disable JavaScript and page colors, and more. Installs in Firefox or Mozilla, on any platform that runs these browsers, including Windows, Linux, and Mac OS X.

• IE’s Web Accessibility Toolbar
Provided by the Accessible Information Solutions (AIS) team of Vision Australia, this free toolbar (donations welcome) for IE/Windows makes it easy to check for various aspects of accessibility. Toggling CSS styles, replacing elements with their alt attributes, test animated GIF images to determine if they are in a “flicker rate” range that can trigger photosensitive epilepsy, and more.

• UsableNet LIFT and Dreamweaver
Mentioned earlier in this chapter, UsableNet’s LIFT for Dreamweaver offers numerous features in addition to assisting with conformance. LIFT automatically identifies many (though not all) accessibility violations. There are also standalone versions of LIFT.

• Dreamweaver 8
Many of LIFT’s capabilities have been incorporated in Dreamweaver 8, including a built-in 508 validation checker, a 508 Reference Guide, and tools for adding accessibility features to images, tables, and frames. Remember: No tool catches all problems or offers a fail-safe substitute for your judgment and experience. Like a hammer and nails, tools only help those who know how to use them. Like eggs, milk, and flour… okay, never mind.
• Microsoft FrontPage Gets LIFT
UsableNet announced on July 9, 2002, that it had integrated its LIFT product into Microsoft FrontPage, the widely distributed authoring tool:

Posted in Web design | 1 Comment »

Good Books That I Recently Read

September 12th, 2006

Many well-intended accessibility books preach fire and brimstone. The smell of sulfur does not inspire designers. All too frequently, these books contain only visually ugly or completely unrealistic examples of accessible sites, along with impractical advice such as “never specify type sizes.” Some authors in the field are hostile to design. Others have no experience in developing commercial sites. Designers might come away from these books believing that accessibility is irrelevant.

Other books are well researched and fueled by passionate insight. These are worth the devotee’s time. But they are not recommended for the general web professional because they are pitched at readers who live with one or more disabilities. In serving that readership, these books spend much time presenting alternate input methods and assessing the merits and demerits of alternative user agents.

Designers are likely to feel alienated if not unconsciously fearful that somehow they too will be afflicted. Fear of blindness, paralysis, and other disabilities partly fuels some designers’ discomfort with the very concept of accessibility, and such books will not help designers shirk that prejudice.

I recommend the following:


• Building Accessible Web Sites, by Joe Clark (New Riders: 2002)

Not merely the best and most complete book yet penned on the subject of web accessibility, Joe Clark’s Building Accessible Web Sites is also among the most compellingly written web design books ever: witty, opinionated, and truthful. In my strange line of work, I see most new design books and many new computer books.

Few are complete, fewer still are entirely lucid, and with very few indeed do I feel that I am in the hands of a master communicator. I devoured Clark’s book as if it were the latest Harry Potter novel. Then I read it again. Not only will you learn everything you need to know from this book, but you can actually read it for pleasure.

Building Accessible Web Sites covers it all, from the basics of writing usable alt attributes to the complexities of captioning rich media. Joe Clark, whom the Atlantic Monthly called “the king of closed captions,” has spent 20 years in the field of media access, and it shows.

He is uniquely positioned to guide the reader clearly and confidently from the big picture to the smallest detail offering phased accessibility strategies that fit any budgetary or time constraint, and straight talk that clarifies regulations and debunks myths. Moreover, Clark cares as much about design aesthetics as access, and he shows how the two are compatible. As with Eric Meyer on CSS (I recommend this book unreservedly.

• Constructing Accessible Web Sites, various authors (Peer Information, Inc.formerly Glasshaus: 2002)

Written by multiple subject matter experts including Jim Thatcher, Shawn Lawton Henry (a WAI member and contributor to WCAG), Paul Bohman, and Michael Burks, this task-focused book is like a wonderful compendium of best-of-breed magazine articles, each of which covers in thoroughly researched and practical detail a particular aspect of the access puzzle.

Among other subjects covered, Constructing Accessible Web Sites includes vital material on the limitations of push-button accessibility testing software, discusses feasible methods of implementing accessibility across large enterprises, and provides detailed tips on accessible Flash authoring.

Although it lacks the Clark book’s advantage of a single, authorial voice, the chorus that Constructing Accessible Web Sites offers instead is compelling in its own right. Both books demand space on the shelf of anyone who designs, builds, owns, or manages websites. Among other benefits, reading these two books will help overturn many mistaken and sadly widespread ideas such as those we are about to discuss.

Posted in Web design | 1 Comment »

WCAG 1 and 2

September 12th, 2006

WCAG 1.0 is a huge leap out of the dark, but it is also an aging specification, and it is not always as clear or as detailed as a standard should be. To clean up the parts that are vague, and to address changes in web development since WCAG 1.0 was new, WAI has developed a WCAG 2.0 specification , which is in final review status as this book heads to the printer.
Not everyone loves the results. Days before WCAG 2.0 was set to go from draft to published guideline, accessibility expert Joe Clark argued that “the fundamentals of WCAG 2 are nearly impossible for a working standards-compliant developer to understand,” and recommended that accessibility experts fix the errata in WCAG 1 instead . As I write this, I can’t say whether WCAG 2.x will eventually incorporate any of Clark’s recommended changes.

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.

Posted in Web design | 1 Comment »

Initial Problems with Keyword Implementations

September 12th, 2006

The seven font-size keywords might have been implemented correctly and uniformly, but they were not. Unfortunately, the keywords were ineptly or incorrectly implemented in the first browsers that attempted to support them, although in one case they were correctly implemented with results so bad they actually caused a subsequent version of the CSS standard to change.

(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.

The problem, of course, is that the sizes do not map to the keywords. In old-school browsers, is the default or medium size that the user has specified in her preferences. In Netscape’s extended HTML markup, is assumed unless you specify another size. Logically, a default size should map to the medium CSS keyword. Unfortunately, in the original IE/Windows scheme, maps to small instead of medium because small is the third size up from the bottom of the list.

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.

• Use the Box Model Hack to serve false font-size keyword values to IE5.x/Windows and correct values to more compliant browsers, just as we used it to serve false and true margin, padding, and content-area values to differently enabled browsers.

• 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.)

Posted in Web design | No Comments »

« Previous Entries