Introduction | Web Accessibility: Web Standards and Regulatory Compliance

It's easy for a non-disabled person to browse the Web. Point your mouse, see the screen, ignore (or read) the ads and the navigation on a page, and concentrate on the central area of a web page that contains the content. Skim through the headings, search for an interesting picture, and then settle your eye down to read the actual information.

Fine and dandy, if you aren't old and don't have arthritis, Parkinson's disease, or multiple sclerosis, and therefore have the motor control necessary to point your mouse. It's a piece of cake to listen to that news report if you aren't deaf, and easy as pie to find the main content if your vision is good enough to read—or if you are sighted at all. No problem ignoring all those flashing ads, if you don't have an attention deficit disorder, and no danger of a seizure, if you don't have photosensitive epilepsy.

But what about those people with disabilities? How can they ever hope to use the Web, which was designed for people who can see and use a mouse? The answer is in this book.

First, the Web was explicitly designed to be usable without a mouse, and without eyes if necessary. A good deal of what drives the Web and makes it so popular is animation, color, and images. But behind the scenes, underneath the hood of any website (choose your metaphor), lurks the computer code that powers it all. Because the Web was designed to be available to people with disabilities, carefully crafting that code (the "markup") can make your site much more accessible to people with disabilities.

Without damaging the attractiveness of your site to your non-disabled visitors, you can allow users with disabilities to reach, perceive, operate, and understand your content. Therefore, more people will have the opportunity to experience your brand, buy your products, or participate in whatever activity you hope to stimulate with your web presence.

It's a huge and utterly untruthful myth that accessible websites must be boring, text-heavy, and ugly. Many are, but that's a failure of imagination on the authors' part. The good news is that, in the vast majority of cases, a skilled developer can make websites accessible without any changes to the look of your website.

Many disabled people use extra gadgets to help them use the Web, known as assistive technologies. Some blind people use the Web with a program called a screen reader, which has a speech synthesizer that reads aloud the web page. Some deaf/blind people have a refreshable Braille display, which allows users to feel a set of pins that the computer moves up and down to form Braille characters.

Some people have voice recognition software to understand spoken commands, and others with motor problems don't use a mouse, so they navigate with the keyboard. Paraplegics may sip and blow into a straw to control the computer. People with low vision can use a screen magnifier. (Chances are, if you have a Windows operating system, there's a magnifier built into your system already; check out Start > All > Programs > Accessories > Accessibility.)

Many, many other people who don't necessarily define themselves as having a disability (such as older people) just soldier on without any assistance, peering at low-contrast, unscalable, 10-point type or trying to click tiny radio buttons on order forms.

To allow these gadgets (or strategies, in the case of increasing the font size) to hook into your site, it must be coded (marked up) the right way. This is nearly always about the code that underpins your site. The majority of the work is transparent to the surfer who doesn't require assistive technologies, yet vital to those who do.

To help include everyone in the Web, the Web's governing body, the World Wide Web Consortium (W3C), formed a group called the Web Accessibility Initiative (WAI), whose mission was to develop "strategies, guidelines, and resources to help make the Web accessible to people with disabilities." It issued the Web Content Accessibility Guidelines (WCAG) version 1.0 in May 1999 to help make content both "understandable and navigable." These are generally considered by web developers, lobbying groups, and many legislatures to be the "touchstone" by which one should code, or judge, the accessibility of a website. WCAG 1.0 gives 14 guidelines, plus checkpoints explaining how the guidelines may be implemented. Each checkpoint has a priority, ranging from Priority 1 to 3. Not conforming to Priority 1 guidelines means some of your content is impossible to access for some groups; conforming to Priority 1 but not Priority 2 can mean it's very difficult for some groups, and so on.

Grotesquely oversimplifying, putting the WAI guidelines into practice on your pages means making sure that important pictures have text equivalents (hidden or otherwise) that can be accessed by blind people, audio is subtitled/transcribed for those who are hard-ofhearing, links and form controls can be easily accessed by those with motor problems, and the site is well structured for use by those with learning difficulties or problems with the language. A handful of the techniques suggested in WCAG 1.0 no longer apply, given that many were written to overcome deficiencies in 1999 browsers, and arguably some of its edicts are ambiguous, contradictory, or even impossible to measure objectively, but most of them have stood the test of time well and continue to be useful today. It's certainly possible to argue with the guidelines, but generally, they still remain the yardstick for all new techniques that come along. They are also unusual in the panoply of W3C documentation—in that it's possible to read them and understand them. A new version (imaginatively called WCAG 2.0) is in Working Draft form and may appear sometime in 2006. Don't worry that this book will be redundant; the new rules restate (and clarify) the old ones, but the techniques for making your site accessible remain equally applicable.

The WCAG guidelines help authors make sites accessible for consumption by disabled people. There are also the lesser-known Authoring Tool Accessibility Guidelines (ATAG), which define how to make web authoring tools (such as Dreamweaver, Adobe Acrobat, content management systems, and blogging tools) usable by people with disabilities, and also ensure the output is accessible to end users. As fewer people make websites than surf them, this is WCAG's snot-nosed younger brother.

Then there are the even more obscure User Agent Accessibility Guidelines (UAAG), which you need to read only if you're developing a browser or media player, or you have a worrying fascination with the arcane.

Accessibility can also be used to refer to the coding of web pages needed to comply with legislation. The U.S., for example, has Section 508 of the Rehabilitation Act that requires federal agencies to make their electronic and information technology accessible to people with disabilities, and which gives a recipe of technical requirements. Other countries, such as the UK, have nontechnical laws that outlaw discrimination against disabled people and so are of obvious significance to the web professional or site owner, but don't describe the technical hoops that they should jump through in order to comply. It is generally considered that complying with these human rights-based laws requires at least WCAG Priority 2 compliance (that is, all Priority 1 and 2 checkpoints and some Priority 3).

Why Should You Care?

I'm not going to try to convince you of the need for accessibility. I'm assuming that you're interested because you're reading this. But if you need evidence, or need to convince others, here are some objective facts:

Many would also add "Including people with disabilities is the ethical thing to do" to this list. I'm not going to, as I promised you objective facts.

What Accessibility Isn't

Let's get this horrible statement out of the way right now. Ready? Here we go: You will never be perfectly accessible to everybody. There is not a simple binary opposition between accessible and inaccessible. There are more than five billion people on the planet, and they're all individuals. (Lone voice in background: "I'm not.")

All you can do is make the best accommodation for the people who come your way. An extreme example: What's good for a person with Down Syndrome may very well be the opposite of what benefits someone with an attention deficit disorder. A bread-and-butter example: What's good for a blind person might enrage your company's brand manager, who will just die unless every word of the website is in that gorgeous typeface that was commissioned for the logo.

"Hang on!" I hear you saying, "That stupid brand manager isn't disabled—why bring him into it?" Because, I respond (neatly segueing into my next point), accessibility is emphatically not about bringing every web page down to the lowest common denominator. It is not about abandoning branding, beauty, creativity, passion, or soul. Quite the contrary, it is about preserving all of those, while simultaneously maximizing the number of people invited in to experience them. Also, although there could never be a solution to suit all disability groups, creating content that can easily be repurposed goes quite some way to achieving that goal.

Because there's no simple polar opposition between accessible and inaccessible, it's very, very difficult to test for accessibility. Unlike the validity of the markup that makes your web page, which is a language for machines so it can be tested by machines, websites are for people and can't be stuffed through a validator for a definitive thumbs up or thumbs down.

Yes, there are products out there, some free and some pricey, that claim to test accessibility, but they're only labor-saving devices. (See Chapter 13 of this book for a detailed discussion of automated checkers.) They can do the heavy lifting and check the obvious stuff. And while this automation is welcome in a site of more than a dozen pages, never ever assume that because some package has found no errors, your site is therefore accessible, or I'll huff and I'll puff and I'll blow your monitor in (unless you have an iMac G5; in which case, I'll just take it home with me).

Why Another Accessibility Book?

This book is a totally revamped, rewritten, shiny new version of Constructing Accessible Web Sites, originally published back in 2002 by a sister brand of friends of ED.

"Ah, Bruce," you may be complaining, "I've already got that book. I've just wasted my money buying this one." Fear not. A lot has changed in the past few years.

The CSS and XHTML Combo Is the New Black and the New Rock 'n' Roll

A whole raft of better tools has come on the scene since 2002. Internet Explorer 6 is no longer the most advanced browser out there; in fact, it's looking shakier than Methuselah's grandfather with a hangover, and is imminently going to be replaced with Internet Explorer 7. In the meantime, Firefox, Safari, and Opera have blazed a trail in modern browsers, encouraging web professionals everywhere to use modern web standards to produce some staggeringly attractive designs.

There has been a mutual advancement between accessibility and web standards: Web professionals have been encouraged to use Cascading Style Sheets (CSS) and Extended Hypertext Markup Language (XHTML) on the grounds that the combination "increases accessibility." That has made a whole lot of designers—who were initially excited by the typographic possibilities of CSS—think about accessibility. It's also shown accessibility boors that accessibility can be good looking, too; see, for example, the work of Andy Clarke or many of the CSS Zen Garden entries curated by Dave Shea. "Synergy," our marketing director might say.

The Web Has Grown Up

Web designers are no longer exclusively ex-print designers. At the beginning of the Web, almost anyone who worked making sites with a credible claim to have an eye for design had previously worked in print. These are the fantastic pioneers who built the modern Web by making it more interesting than a bunch of hyperlinked physics papers, but whose expertise was almost entirely based on making things visually gorgeous, with pixel-perfect layouts that preserved the design's integrity. For the majority of these pioneers, the idea of designing beauty while keeping in mind the people with no visual faculties at all was simply too much for their paradigms to cope with.

We now have a generation of designers who've grown up with the Web, and the world of accessibility gets a boost because of that (although the world of computer book prefaces has suffered a blow at my gratuitous use of the word paradigm).

We've Learned New Techniques

Through trial and error, community websites, and the occasional ill-tempered argument, the accessibility community has learned a great deal, too. We've learned that screen readers no longer simply read the screen; instead, they read the source—so the text is read out in source-order rather than in the order that the CSS positions it. (Don't worry if you didn't understand that last sentence; you will soon.)

We've learned that not everyone with a disability is blind, and that not everyone with a visual impairment uses a screen reader.

We've also learned that while a website can be technically accessible (so, theoretically, a user with unlimited time and patience could get to the content), it's not always easily accessible. A good example would be a portal page with dozens of links before each page's main content. With no way for screen reader users or keyboard navigators to "jump over" the links, they're forced to listen to them or tab through them again and again and again as they move though your site.

Maybe most important, we've learned that online accessibility validators (which compare code against the rules for that language) cannot replace knowledge, testing, and understanding.

Accessibility: The Three-Legged Stool

It's a truism that retrofitting a completed project for "accessibility" is much more expensive than designing for it, and that it leads to a lower level of accessibility than if it were a design goal from the very beginning. The reason is that full accessibility is a combination of the WAI guidelines, web standards, and semantic coding. Think of these as the three legs of a stool; if one is shorter or weaker than the others, at some point, you're going to fall over and land painfully on your backside.

This is a fairly technical section, so if you're a site owner/technology officer, you might want to skip it, while making it mandatory reading for your developers. (You may want to make them memorize it and recite it at your holiday party—in which case, please video it and send me a copy.)

Web Standards

A couple of the WCAG 1.0 Priority 2 checkpoints are maddeningly vague. The following two checkpoints are taken to require web standards:

Web standards are a big subject and deserve a whole book in their own right (and friends of ED publishes a splendid introductory guide/cookbook by Dan Cederholm called Web Standards Solutions).

Putting it simply, by web standards, I mean using a markup language (HTML or XHTML— totally up to you) to describe the structure of the web page. Every single page of every single website across the world uses one of these languages, but most don't follow the rules properly. The markup languages have rules published by the W3C, and you'll get the most benefit if you follow those rules.

Unlike testing for accessibility, it's easy to test whether your (X)HTML conforms to the specification, as there are free online validators that pass or fail the code (see http://validator.w3.org). However, once you've made sure your code validates to the rules, you'll get extra accessibility, cleaner code, and depending on how well you've separated your content and presentation, easier maintenance.

Yes, I know that sounds like gobbledygook, but it simply means that you should use the markup language to describe what something is (is it a paragraph? a list? a heading?) and not what it looks like. Describing what it looks like in the markup mixes up presentation with content, and can therefore feed a lot of useless stuff to a device like a screen reader. By definition, a screen reader doesn't care what something looks like; it only cares if the current bit of the web page is a header, a link, or a quote, and will probably indicate that to its user. Mixing structure and presentation also makes maintenance a nightmare, as it's far more difficult to make site-wide changes without editing every page.

The place to describe the look of your content is in a style sheet (aka Cascading Style Sheets aka CSS), which tells the browser where on the page your headings, images, copyright section, and so on should go, plus what colors to use, which fonts to use, and all other styling considerations.

This is now standard practice among web developers, as it means that changing all fonts, colors, and so on throughout an entire site can be done by editing one style sheet, and not having to update the information on every page.

Semantic Code

It's really the practice of using the best HTML element for the job. So, don't use <blockquote> just because you want some indented text, merely because many browsers just happen to indent text inside a <blockquote> tag. Use it only if your content actually is a quote. If it isn't, enclose it in another element that more accurately describes what it is and use CSS to format it with an indent.

Similarly, if you have a navigation menu, don't mark it up as being a paragraph or a table. A menu is really a list of links, so mark it up as an unordered list. You can style it, remove the bullets, or even set it as a horizontal navigation bar later using (can you guess?) CSS.

This will make your code cleaner, more maintainable, and more useful for search bots like Googlebot to work out which content is important. There's also an accessibility benefit, especially for the blind, as the most popular screen readers (such as JAWS for Windows by Freedom Scientific and Window-Eyes by GW Micro) allow users to jump between certain types of content. In JAWS, for example, the H key jumps from header to header, and the 2 key jumps to the next second-level header. It's a way of allowing a blind user to "scan" a document in a manner similar to how a sighted user would read a newspaper: jumping from headline to headline, rather than listening to every word of every story in order. Imagine how tedious you would find it to listen to ten pages of sports news before you got to the horoscopes that you wanted.

Not all screen readers can take full advantage of web standards yet. This is because, historically, most websites have been so badly marked up that the screen reader developers spent most of their time developing the products to make a silk purse out of the bad code of the sow's ear. But screen readers do like well-marked-up code, and the influential lobby group, the Web Standards Project, set up the Accessibility Task Force to lobby assistive technology vendors to support even more web standards. It's a long-term job, but it's the way the wind is blowing, so you can be certain that you will be enhancing your accessibility by adopting a design methodology of semantic markup that separates content and presentation.

Remember my analogy of a stool? It's all too possible to write code that validates but isn't semantic. Here is an example:

It's perfectly possible to write code that separates content and presentation, but doesn't validate (usually due to a typo or small error). It's incredibly common to see a page that is semantic and valid but inaccessible (perhaps the main point of the page is a graph that is just a picture, but with no alternative text description that the visually impaired can understand).

Current Hot Potatoes

I wouldn't want you to think that making your sites accessible is just a matter of following a recipe; to make nourishing accessibility pudding, add one part CSS, one part valid code, a pinch of semantic markup, and a cupful of WCAG guidelines. It would be nice if I could guarantee that slavishly following such a recipe would make everything lovely, but there are two reasons why I can't. The first is that annoying fact that people are people, and insist on having different needs and abilities. The second reason is that, when discussing a discipline that's as new as web standards/accessibility, there are the expected disagreements between practitioners. In fact, when three accessibility practitioners are gathered together, there will be four or more different opinions.

I don't want this to discourage you from learning about accessibility. The most important accessibility techniques are uncontroversial and will help the huge majority of those people who are currently ill-served or locked out of the Web. However, there are several different authors following me, and they will occasionally disagree with each other. We think that glossing over these differences of opinion would do you, the book, and the discipline of accessibility a disservice, but you might want to skip these and return to them after you've read the rest of the book.

Accessibility Isn't the Same As Device-Independence

Some highly erudite and respected accessibility practitioners will claim a site isn't accessible if it can't be viewed and understood with images and CSS off, and over a dial-up modem. They feel that accessibility means that anyone with an Internet-enabled device— however slow or old—should be able to access the content.

The W3C, however, explicitly says that its guidelines are purely aimed at making sites available for people with disabilities, but "following them will also make Web content more available to all users, whatever user agent they are using or ... constraints they may be operating under." That is, the "all users" part is a happy by-product of accessibility for people with disabilities.

It's a debate that hangs on your understanding of the word accessible and how prepared you are to sacrifice imagery and design to accommodate those who choose to use very old or very slow technology. This book generally defines accessibility as dealing with disabilities, and not user choice, although making pages accessible goes a long way toward making them universal, just as the W3C says.

It Takes Two to Tango

A close relative of the accessibility vs. device-independence debate is the question of to what extent you can expect users to own the right tools to help them access the Web. If, for example, someone has an ancient version of a screen reader that can't use a wellestablished accessibility technique that I've sweated to implement, is that my fault?

The British Standards Institution's recently released PAS 78 "Guide to Good Practice in Commissioning Accessible Websites" says:

On this subject, we agree. The authors of this book believe that it takes two to tango—a user must be equipped to use the page that you spent so long making accessible. That means visitors must come with a reasonably modern browser, a reasonably recent version of any assistive technology (such as a screen reader or Braille display), and a reasonable knowledge of how to use their setup.

But note that even if a user does have the most up-to-date tools available, if one of the items brought to the party is a screen reader, it will most likely be deficient. Most screen readers can't process important bits of HTML. For example, the <ins> and <del> tags that indicate inserted and deleted text are ignored by some screen readers—making legal documents at best incomprehensible and at worst misleading or incorrect. JavaScript support is patchy, undocumented, and thus unpredictable. New techniques, like Ajax (a kind of fancy JavaScript-driven way to make websites feel more slick and responsive that you may have seen if you've used Google Maps or Google's Gmail), are very difficult to make accessible.

However, there's one reason for optimism with the screen reader inadequacies. There are numerous screen readers competing aggressively with each other. The vendors sell their products for hundreds of dollars, and lock the customers in by their screen readers being incredibly difficult to learn and difficult to replace, due to the costs.

So when Flash was first made accessible by its manufacturers, the Window-Eyes screen reader from GW Micro could read it from day one. Another screen reader, JAWS (from Freedom Scientific), raced to catch up because so many websites were Flash-based, so Flash support was a selling point. As all software manufacturers know, to fall behind is to die slowly. The same has happened with support for JavaScript, PDF, and the Firefox browser.

It seems that when a technique or technology becomes popular, the screen readers will vie for each other to support it. Whether that means that it is legitimate to use a technology like Ajax and wait for the assistive technologies to catch up is not something I can decide for you.

"Until User Agents ..."

Some of the WAI checkpoints are obsolete or badly worded—so do we have to follow them? For example, checkpoint 10.1 commands, "Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear." Now, some browsers do allow me to turn off spawned windows, but others don't. Do I need to follow this checkpoint or not?

This book generally assumes that if the majority browser (currently Internet Explorer 6 for Windows) is one of the user agents that doesn't do what the checkpoint is primarily concerned with, then it may not be safely disregarded.

Fortunately, WCAG 2.0 is desperately trying to avoid using terms like "until user agents." See Chapter 14 for more information about WCAG 2.0.

Cognitive Disabilities

Cognitive disabilities are a tricky and emotive area. It's relatively straightforward to ensure your animations won't trigger photosensitive epilepsy, or to design a typography that is accessible to people with dyslexia. But will the plain, non-distracting design hold the attention of those with an attention deficit disorder?

To what extent can you make your pages accessible to those with cognitive disabilities? Can someone with Alzheimer's disease navigate your site? Is there a technique to make your site appealing to autistic people? There's an entire book to be written about cognitive accessibility; this book isn't that book.

What This Book Will Do

We'll show you how to make your websites as accessible as possible, to the broadest range of people as possible, in a way that should—at a minimum—make sure you're in compliance with the law.

We'll do that in the most modern way possible, using semantic markup, CSS for presentation, and valid code—except for those rare occasions in which accessibility is better served by invalid code. We'll show you how to make sure that the behavior layer of your page is accessible, too, using the emerging techniques of "unobtrusive" JavaScript.

We'll be pragmatic, too. Many of us, whether by choice or requirement, need to use Adobe PDF or Adobe Flash. There are techniques to enhance the accessibility of those technologies, and we'll show you those and examine the advantages as well as the pitfalls in the chapters dedicated to accessible PDF, Flash, and JavaScript.

Conventions Used in This Book

To keep this book as clear and easy to follow as possible, the following text conventions are used throughout (you've already seen many of these in this introduction):

Introduction by Bruce Lawson