AUTHOR’S NOTE – You’re reading the HTML version of a chapter from the book Building Accessible Websites (ISBN 0-7357-1150-X). Copyright © Joe Clark, 2002 (about the author). All rights reserved. ¶ Back to Contents
Let’s run through some typical objections to providing accessibility, blowing them out of the water one after another. Then I’ll give you a few reasons, some of them unexpected, why you actively should do it.
Access is poorly understood, and a range of myths has taken hold.
Yes, it is – for a large site and if you do it after the fact. Retrofitting always costs more, even at the level of adding a dimmer switch in your house. In all other cases, access may cost, but it is not necessarily expensive. In compensation, you gain a new audience.
You need to know that your concern for cost is shared by everyone in all areas of the field of accessibility. Why? Accommodating people with disabilities usually costs something. Disabled people could be the only minority for whom equality costs money. It doesn’t cost you extra not to discriminate against blacks or women. (If you think I’m picking on blacks and women – my editors did – or somehow think I am assuming you the reader are not black or a woman, note that blacks and women are merely listed as groups who have suffered discrimination in the workplace. If you dislike the term “blacks,” note that this book has an international audience and the accepted American liberal substitute, “African-American,” applies only to Americans. And I personally know Africans who aren’t black.)
It may cost you to accommodate religious practices at work (e.g., observant Jews who must leave work early on Fridays to be home before sundown), and pay-equity legislation may increase payroll costs for female-dominated occupations, but those are the exceptions.
In general, equality requires a change in attitudes, not a cash outlay. Disability is very often different. Automatic doors; sign-language interpreters; adaptive technology; attendant services; wheelchair-accessible housing, buses, and trains – they all cost money. In the field of employment, human-rights legislation and decisions by courts and tribunals have held that treating disabled and nondisabled employees exactly the same (which would in fact cost nothing) does not always constitute equality.
However, most accommodations in the workplace are low-cost. Here is some evidence:
In the same vein, accessible Web design is usually also cheap.
In the infamous Sydney Olympics case (described in detail in Appendix A, “Accessibility and the law”), the Sydney Organizing Committee for the Olympic Games purported that adding simple access features to its thousands of database-generated pages would cost $2.8 million in Australian dollars. No one with any real-world access experience, including the expert witnesses testifying in that case, believed or confirmed that figure. The expert witnesses did, however, concede that post-facto accessibility would cost the Committee tens of thousands above the existing project expenditures, a fact that is about as surprising as telling us night follows day.
On the other hand, building accessibility into the project from the word go would have added 2% to the cost, according to the experts. That figure could have been built into the original budget. You’re still spending more money, but here you’re planning for it. And even that cost compares favourably with the billable staff hours – and expensive legal advice – associated with fighting a human-rights complaint.
Note that I am not attempting to snow you with magical claims that accessibility is free. It isn’t. However, the graduated approach provided by this book makes access inexpensive, or at least reasonable in cost, for small, medium, and large Web projects – and for small, medium, and large Web shops. The cases in which accessibility is hugely expensive tend to limit themselves to Websites that are already expensive anyway. This book’s access techniques scale with your project, your staff, and your own abilities.
In fact, Basic accessibility as described in this book is generally so cheap it can only be measured in pennies. If you think that typing the letter C costs twice as much in staff time as the letter c because you have to press the Shift key to do it, then you’re pretty much the only kind of developer who will be able to pin a dollar value on basic accessibility. If, on the other hand, you recognize that adding five alt texts of ten words each to a 50 K Web page takes minutes and is about as taxing as typing out your name, address, and phone number, you may be persuaded that Basic accessibility isn’t expensive after all.
Let’s consider priorities. Developers think nothing of custom-coding JavaScript, ASP and other database back ends; designing graphics, including navigation buttons and rollovers; optimizing and slicing graphics for faster loading; creating animated GIFs; drawing custom page backgrounds, including dithered Web-safe colour combos; and writing complicated nested tables for precise page layout.
How many visitors do those tasks benefit? Most? Some? It doesn’t matter how many. The fact is that the developers, and presumably the client, decided those activities were worth it – worth doing, worth the time, worth the money.
If you’re willing to go to all that trouble, what’s wrong with incorporating access techniques into your development cycle? Using this book’s graduated approach, you will find an access technique your project budget can afford. You won’t be able to use the cost argument ever again.
You also gain a new audience, or at least you cease to antagonize part of your existing audience, as you’ll see next.
Accessibility is about accommodating minorities. So of course it serves small numbers – in each individual group. Add the groups up and suddenly the numbers aren’t so small. But be mindful of the real people hiding behind small percentages. So-called minorities have a way of expanding as your site does: If 1% of your audience can’t see graphics, and all of a sudden your site becomes popular and moves from 20,000 hits a month to two million, does the change from 200 to 20,000 affected users influence your opinion that “too few people” might benefit? Even with 200 affected users, can you justify ignoring the inexpensive basic accessibility advice in this book?
Can’t you readily imagine three city buses totaling 200 passengers, none of whom can actually use your Web site? The issue is a tad less abstract when you look at it that way, isn’t it?
The available figures on numbers of people with disabilities online are sketchy at best.
Figures with greater scientific credibility are rare and limited to the U.S., but they exist.
The Survey on Income and Program Participation (SIPP, 1999, carried out by the U.S. Department of Commerce, Economics and Statistics Administration, National Telecommunications and Information Administration) found the following basic statistics on disability groups:
The number of people with certain disabilities and “access” to the Internet was also surveyed. What “access” means is ambiguous, though, by the researchers’ own admission: It could simply mean a computer exists in the home or workplace that can be connected to the Internet, or it could refer to active Internet use by the person in question. Even with this ambiguity, the figures are still helpful:
By contrast, 56.7% of nondisabled people have Internet access. The disparity is considerable.
(Throughout this section, by the way, I’ll omit statistics relating to disabilities that have no bearing on using the Web, like trouble with walking.)
A University of California, San Francisco study from the year 2000 [PDF ¶ HTML] uses a broader definition of disability (“work” disability, which, for this topic, does not break down specific disability categories, like blindness or deafness). In that study, “[o]nly one-tenth (10%) of people with disabilities connect to the Internet, compared to almost four-tenths (38%) of those without disabilities.... Of the 21 million Americans with work disabilities... only two million ever use the Internet.”
This same study also finds very low usage rates of adaptive technology other than white canes: “A very small number of people (3% of blind persons and 0.1% of those with low vision) specifically [mention using adapted] computer equipment.” It is likely that many low-vision people do not need adaptive technology, but these numbers are still surprisingly low. (Adaptive technology is described in detail in Chapter 13, “How do disabled people use computers?”)
But let’s approach this quantitative objection qualitatively. To use the old terminology from modems, the Web is about feature negotiation. You program a Web page and my browser attempts to render it, and there are many provisos. But if you publish a print brochure or shoot a TV commercial, you can be quite sure every reader or viewer has the same experience, disability notwithstanding. That isn’t true online. A page using anything other than 1994-era plain-Jane HTML will look noticeably different in different browsers. In effect, the Web forces developers to accept multiple fragmented audiences.
Indeed, you’re dealing with two audiences: The technical device (the browser) and the person at its controls. Large shops working on large sites will pull their hair out trying make layouts work more or less similarly in Explorer and Netscape. In so doing, they acknowledge the diversity of the audience.
The claim that access serves too few rests on the assumption that it serves only a few disabled people, chiefly the blind and visually-impaired. And here we need to expand our discussion to the real world. Web developers are visual people. It is hard for them to imagine being blind. With rare exceptions, they don’t know any blind people, and haven’t even exchanged E-mail with a visually-impaired person.
Underlying all this is a very human kind of fear: To imagine your site as experienced by a blind person is to imagine you are blind yourself. You would have a hard time finding more than a handful of sighted people in the history of the world who willingly wished to become blind. The fear of blindness is natural and understandable. It is also quite irrelevant, and it is something you have to get over.
Disability advocates point out that any nondisabled person could become disabled at a future time. While this veiled threat–cum–guilt trip is obviously true, it is unlikely to happen to any specific Web designer or developer. You are not adapting your Web site for a nightmarish hypothetical future in which you yourself cannot see. You’re doing it because, deep down, you accept that the Web is attractive to people who aren’t exactly like you. It’s a mature, worldly approach, one that comes with education and practice, both of which this book will provide.
In all honesty, some forms of accessibility are exceedingly difficult – captioning, subtitling, dubbing, and audio description (described in Chapter 13, “Multimedia”) are so complicated that, save for short one-off applications, only experts in the field should attempt them, and even they flub it a lot of the time.
Still, making Web sites usable by disabled visitors is generally straightforward even for beginner Web developers. Only a couple of access tags, like longdesc and a few dealing with HTML tables, are head-scratchers. But they aren’t included in the Basic level of accessibility you’ll learn from these pages. Intermediate and Advanced access levels are the sort of thing that only intermediate and advanced developers would attempt for pages of intermediate to advanced complexity, and for them even the obscure and difficult access tags aren’t necessarily all that obscure or difficult. These are the guru developers, after all.
The complaint that access is difficult camouflages another complaint: No one teaches accessibility in an understandable way. No surprise, then, that accessibility is hard to understand and unfamiliar. And that’s quite a fair complaint, actually. Bookstore shelves groan under the weight of JavaScript, Python, ASP, SQL, Oracle, and HTML programming books, among dozens of other well-covered topics, but accessibility remains obscure and unexplained. This book attempts to do it right, explaining not only how to make online media accessible but why.
If the canonical reason to make a Web site accessible is to make it usable by a blind person, just what is a blind person going to get out of a Web site? With rare exceptions, the Web is a visual medium, right?
Well, so are TV and the movies, and studies have repeatedly shown that blind and visually-impaired people have the same basic desire to watch TV and film. Blind and sighted viewers even have similar tastes in film and TV programming. The blind live in the same world as the sighted. Both groups understand that the Web is a useful medium of information, entertainment, communication, and community.
(Television, film, and home video are already being made accessible to blind viewers, by the way, through audio description. It isn’t a theoretical issue. Chapter 13, “Multimedia,” explains it for you.)
There’s a pragmatic reason, rooted in technological history, why visually-impaired people are into the Web: The blind are avid computer users. Back in the days of DOS and the earliest Macintosh systems, a range of mom-and-pop vendors had already invented screen readers, screen magnifiers, Braille displays and keyboards, and other adaptive technology that made computers usable by someone with limited vision. When the Web came along, it was merely a question of updating the adaptive technology, though the level of complexity involved in making DOS accessible is nothing compared to a graphical user interface.
If you’re not interested in making your pages accessible because you think the main audience is blind people and blind people just aren’t your market, the question to ask yourself is: Are you sure?
It is self-evident that some products and services are intrinsically inaccessible to blind and visually-impaired people – military service, for example, or driving schools. On the other hand, blind people have friends and relatives. If you’re a low-vision person and your nephew is considering joining the army, you may wish to check the relevant Web site to learn what he’s getting into, or to double-check a few facts he found on that site. Is it really true that the blind person is not your customer in such a case? Does the concept of “customer” relate strictly to lone individuals? If so, what about word-of-mouth?
This reasoning is particularly dangerous at E-commerce sites. For the canonical accessibility audience (blind and visually-impaired people), getting around town and navigating inside retail stores are real barriers. Shopping online assists in independence: You can find out about a sweater or a book or a refrigerator without having to ask a salesclerk to guide you to the right section of the store and to verbally explain the range of options available and exactly how each one differs.
If anything, shopping in the real world – in meatspace – is enough of a bother that shopping in cyberspace becomes particularly attractive for the blind consumer. In effect, online retailers can boast a new audience that traditional retailers, who are nominally the competitors of online stores, could reach only with difficulty.
Actually, there are a couple of unspoken undercurrents in the objection that visitors who require accessibility aren’t the desirable market. There’s the discomfort and ignorance of contemplating a group with a disability you yourself hold in fear. There’s also the classist assumption that, for example, blind people are too poor to deserve access to your site. As with so many stereotypes, there’s a grain of truth at work there: As a group, blind and visually-impaired people are underemployed and rarely are high-wage earners.
The U.S. SIPP survey aforementioned found that, among people with disabilities (though not necessarily only those disabilities relevant to Internet use), income distributions are as follows:
The University of California, San Francisco study aforementioned found that people with work disabilities (again, a broad definition), use the Internet less often than nondisabled people. Only 5% of people with work disabilities with low incomes (less than $20,000 a year) use the Internet; the figure is 17% for people with work disabilities with higher incomes. (On this question, the study had only those two categories – below $20,000 and above.)
But let’s approach this from a moral angle, which, you’ll note, I am at pains to avoid in this book. If it were technically possible to create a Web site that excluded Jews, women, Albertans, or men over 60, would you do it? Even if that were the unintended effect, once alerted to it, would you leave it in place? The unpalatable truth is that a Web site developed without due regard to minimal accessibility is a slap in the face to an entire category of people. History is replete with insults applied to categories of people.
In most cases access is required due to a characteristic the audience cannot change. I doubt you would countenance racism, sexism, or anti-Semitism on your Web site. Ask yourself if you really want to be complicit in a similar social ill.
Now that I’ve exploded some myths and provided counterarguments for typical excuses, here are a few active reasons to provide accessibility.
Antidiscrimination legislation in most Western nations, including the U.S., Canada, Australia, and the U.K., forbids discrimination or unequal treatment on the basis of disability. In most cases, accommodation is actively required: You have no legal basis to sit around and wait for someone to request accommodation or to file a complaint alleging discrimination or unequal treatment.
Are you legally required to provide an accessible Website? The answer is often a clear yes. At time of writing, I was able to find only one court or tribunal ruling that specifically addresses accessibility of Web sites. In the year 2000, Bruce Maguire, a blind person in Australia, filed a complaint with the Human Rights and Equal Opportunity Commission alleging that the inaccessibility of the Web site of the Sydney Organizing Committee for the Olympic Games constituted discrimination on the basis of disability. He won.
If you aren’t a resident of Australia, you mustn’t think the Maguire decision has no bearing on your country. When it comes to disability, antidiscrimination laws are broadly comparable in countries that have them. The basic legal principle of accommodating a person who requires accessibility provisions is exactly the same in the U.S., Canada, the U.K., Australia, and elsewhere. Human-rights law is international by definition (think of the war-crimes tribunal in the Hague), and precedents need not be drawn from within a country. Quite simply, the Maguire case constitutes a worldwide precedent.
The legal issues are clear-cut enough that a single blind person could take on the mighty Olympic “movement” and win. (The whole case is documented, and explained in layperson’s terms, in Appendix A, “Accessibility and the law.”)
In the U.S., the Americans with Disabilities Act unequivocally does apply to Web sites. At press time, no complaints or lawsuits had been filed under the ADA. Moreover, for U.S. government agencies, so-called Section 508 regulations require accessibility of Websites and a great many other areas. Again, no complaints had been filed at time of writing.
In Canada, no complaints have been filed under legislation covering federally-regulated industries, which encompasses Websites. However, the Canadian Human Rights Tribunal did rule in 2000 that an absence of captioning on a television network constituted discrimination on the basis of disability. (Similar rulings were brought down in unrelated cases in Australia. There are many provisos in the Australian cases, but the effect is the same.)
The parallel here is not exact: Television is not the Web, but both are media, and captioning is one means of making the medium of television accessible. The parallel, however, doesn’t need to be exact. We have various means of making the Web accessible (including, as it turns out, captioning). A complaint lodged on the grounds that a Website failed to provide accessibility is likely to be well-grounded.
Unless you worked for the Sydney Organizing Committee for the Olympic Games, which in any event had been legally dissolved by the time this book was published, there is next to no chance at all that you would have been served with a human-rights complaint or a lawsuit over your inaccessible Website. Plainly, it is unlikely in the extreme that such a complaint would be served on you. Do not use that as an excuse to avoid accessibility.
Are there limits to legal requirements? Yes. Human-rights legislation, including the Americans with Disabilities Act, provide a number of exemptions; of particular relevance here is “undue burden” or “undue hardship.” Simply put, an entity is not required to provide accommodation if that provision would materially endanger the entity or alter its fundamental purpose.
In general, that exemption has been interpreted to mean “the accommodation would cost so much it would bankrupt the company – or nearly so.” Even if that condition holds, you may be required to find another way to provide accommodation that you can afford.
In the case of Websites, a small business may not be required to caption and describe online video, for example, if the cost might endanger the company’s ability to pay for the entire site itself. That doesn’t mean you are legally entitled to post online video with no access features whatsoever. Providing separate transcripts and text-only descriptions may be deemed appropriate accommodation under applicable laws.
Or a stock-photo agency may not be required to write long descriptions for tens of thousands of online photographs; to do so might alter the fundamental nature of the business. But that says nothing of adding accessibility to the general navigation and all aspects of the site other than the differences among the photographs available for purchase.
To reiterate this point: While there are limited exceptions to legal requirements, there is no blanket exemption.
You used to be able to get away with writing easy HTML version 1.0 in designing Websites. Then you had to learn tables and frames. But aren’t text-only pages boring? To add graphics, didn’t you need to learn Photoshop? Then JavaScript, then Java applets, then database back ends (what kind? Oracle? SQL? ASP?). Suddenly these were bigger and bigger projects, so you became a project manager. You had to wrangle text and images, verbally camouflaged as “content”; some jobs demanded PHP, others Perl, so you learned both. Browser-compatibility work went on forever, and still does. (Curse you, Netscape 4!) Stylesheets cascaded into your workday. Content management, the dark art. Usability and information architecture. The wireless Internet.
Not everyone in the biz needs to know every skill. But you can’t get by with a single skill anymore. In particular, if you are a Web programmer or a Web designer, you already boast a constellation of skills – HTML and JavaScript and Flash and basic usability, for example.
Accessibility, quite simply, is the next skill you have to learn. Due to its cross-disciplinary nature, if you know HTML or JavaScript or usability, even in small doses, you are already equipped to expand your repertoire of talents.
You have, in effect, another paragraph to add to your résumé.
You also have to know what you don’t know. Even if you do not wish to learn accessibility techniques well enough to do the work yourself, if you know the lay of the land you’ll be able to manage someone who does the actual coding, write an accurate job spec for a client, or at least sound halfway knowledgeable in a pitch meeting.
A founding principle of accessibility is providing alternatives – “When there’s an image, also give us text,” that sort of thing. It’s a form of beneficial redundancy.
Experienced Web designers already code for redundancy. Think of a typical commercial Web site. How does a visitor get around?
Take another example: Feedback. It is commonplace for sites to offer all of the following: A free-standing form that visitors can fill out to contact the site’s owners; individual contact E-mail addresses; and the owners’ postal address and fax and phone numbers. Nowadays sites offer discussion fora and/or set up entire Weblogs to which you are invited to contribute.
Redundancy, then, is a required practice in commercial Web design. Accessibility provides merely another form of redundancy.
Remember when the JavaScript rollover was invented? As you passed the mouse cursor over a graphic image, the image changed. Maybe the type turned red. Maybe a little ferret or a canary popped up over the link. Maybe an entire new picture, one-third the size of the whole browser window, flashed into being alongside the link.
Initially dismissed by purists like me, rollovers are now such an accepted practice that standard software creates them for you automatically; the concept has spread to the a:hover pseudoclass in cascading stylesheets; and the technique has spawned progeny in the form of DHTML menus.
A page with rollovers, or any of its related interface elements, is a richer page. It’s not quite “interactive” (though the twits from marketing would be the first to claim so), but rollovers hide little pockets of delight throughout a page like Easter eggs.
Speaking of which, I am honour-bound here to include a phenomenon I do not really get. Geeks and laypeople love to spend hours hunting down Easter eggs – cute messages and pictures hidden in software that appear when you take some obscure action, like selecting the Open command from the File menu with three modifier keys held down.
Easter eggs are fun and harmless and add an unexpected layer beneath the strait-laced surface of boring old software. The phenomenon is responsible for much of the appeal of movies on DVD: Don’t you feel cheated when a disc does not provide director commentary, deleted scenes, the movie trailer, Web links, and a video game based on the film? (Some DVDs include actual Easter eggs in the computer sense.)
For the developer, accessibility follows in this tradition. An accessible page provides pop-up balloons, secret alternative functions available only with a special key sequence, and unexpected variations that you unlock only when a page is spoken rather than displayed. With these features, you turn your entire accessible site into an Easter-egg hunt.
This rationale may seem a bit crass, but not every rationale need be high-minded. A Website built according to accessibility principles – better yet, a Website that conforms to published specifications like the Web Accessibility Initiative’s Web Content Accessibility Guidelines or U.S. government Section 508 requirements – has greater value than an inaccessible site. It becomes one of the many attributes to which you can attach a price should you wish to sell your site; ready-made accessibility represents work the buyer does not have to do. This advantage does admittedly assume the buyer is engaged in due diligence on the topic of accessibility, but nothing stops you from bringing it up yourself.
As I write this book in 2001–2002, a trend is sweeping the ranks of elite Web developers: Absolute standards compliance.
For half a decade we have put up with nonstandard extensions to World Wide Web Consortium HTML standards – blink, marquee, margin attributes on the body tag, selectable borders on tables. What’s much worse, we’ve put up with browsers and authoring tools that cannot render or produce standards-compliant code.
The days of hacking out ad hoc solutions to standards incompatibilities – the days, in other words, of doing anything special at all to accommodate the quirks of Netscape 4 or FrontPage or their ilk – are drawing to a close, at least if the trend toward absolute standards compliance is any indication. A chief advantage of standards compliance is the realization of the long-cherished goal known as “write once, read anywhere.” Instead of coding four different versions of a page (for Netscape and Internet Explorer on Windows and Macintosh, respectively – a real-life example), you write one page according to spec and each device displays the page accurately. Some differences, like the specific appearance of fonts, will remain, but designs should be flexible enough not to be broken by such details.
The “read anywhere” side of the argument has hitherto restricted itself to visual display in browsers, if only because Web designers are visualists. Yet if you truly believe in this philosophy, you need to accept that “anywhere” really means “anywhere,” including a screen reader, a printout, a Braille display, or a text-only variation, all of which can be produced by a visitor’s browser or device without a stitch of extra effort on your part if and only if you code to standards. (It’s true that adding access-specific tags is an extra effort, but not all pages require them.) Adapted variations of your page will come into being with little or no foreknowledge or involvement on your part. You will have given the world not merely a page that looks and acts analogously in whatever visual browsers you think are important but one that works with devices you cannot even test by yourself.
Standards compliance is a form of programming maturity. Perhaps it is time to grow up a little. You, esteemed reader, will have a conflict to resolve if you want to produce accessible Websites but still work around the quirks of noncompliance. One of them has to go.
To design for accessibility requires you to design for people who aren’t exactly like you. That’s true whether you, the designer or programmer, are or are not disabled yourself. Even if you act like it’s 1996 and you design pages “best viewed in Netscape Navigator,” people will defy your expectations and view your page in whatever browser or device they feel like using.
Of course, the norm these days is to design for multiple browsers. But do you run multiple browsers yourself? Do you do your actual day-to-day surfing in more than one browser? (I do, but I’m unusual.) You’re already designing for people not like you. The distinction? They’re using a different browser. A disabled visitor using adaptive technology, or using no such technology but relying on correct design and coding, falls into the same category.
One limited exception comes to mind – an Intranet where the number of users is small, you know absolutely all of them personally, and you are perfectly sure that none of them has a disability or ever will. Even so, designing to standards will save you time, and you might as well build in free Basic accessibility while you’re at it.
Further, I work from the premise that you would never presume to limit what your visitor can and cannot learn from your site. An inaccessible Website, in effect, tells visitors with relevant disabilites to get lost: “You have no business being interested in our site.”
To sum up these related “soft” arguments for accessibility, then: Once you learn accessible design techniques, you heighten your sophistication, and may then stand taller in the saddle. “You mean you don’t know about accessibility?” you may archly ask your inferiors, rolling your eyes and sharing a knowing grin with your compadres.