From Joe Clark’s Building Assessable Websites:

Mobility impairment
The requirements of someone who cannot readily type or use a mouse (or press a switch, or engage any other hardware interface) are the easiest for accessibility neophytes to understand. Why? Because the adaptive technology they use generally takes the form of alternative keyboards and mice, and hardware of that sort makes for tidy photographs. You can immediately see the necessary modifications, if not actually understand every detail of their operation.

For the purposes of this book, “mobility-impaired” people have trouble using the hardware of their computers rather than understanding or interpreting information.

So what’s the solution? There are actually tons of options; only some have a bearing on writing accessible Websites, but as in every sphere of understanding, you need to know more than the bare minimum to be considered civilised.

Keyboard guards and overlays: A sheet of thick plastic with holes lets you guide your fingers to just the right key. Useful if you have cerebral palsy or a tremor that makes you depress more than one key at a time, or if too many errant keystrokes precede or follow a correct keypress.
Slow keys and onscreen keyboards: Software can automatically discard keystrokes typed in too quick a sequence, and can show you a picture of a keyboard that you can actuate with a switch or a mouse. (The really good onscreen keyboards predict the words you’re trying to type, and the next word or phrase after that. It’s surprisingly efficient.)
Replacement mice: Everything from foot pedals to gigantic trackballs are used as direct mouse surrogates. An ordinary off-the-shelf trackball can be a good adaptive technology for some people.
Switches and scanning software: If you can take one action reliably (blinking an eye, flexing your wrist, jostling your knee, or, in the best-known case, sipping and puffing on a straw), then you can acutate an on/off switch. Since computers are binary devices, that’s all the ability you need. While still laborious, switch access is now much less so than, say, back in the mid-1980s, when quadriplegics’ use of sip-and-puff switches began to be covered as a human-interest story in newspapers. (Just as people seem to know the phrase “carpal-tunnel syndrome” but nothing about repetitive-strain injuries in general, the use of personal computers by blowing on a straw seems to be a fact widely known in the absence of other disability knowledge.) Note, though, that the days of sip-and-puff switches are largely behind us. In the 21st century, “switch access” may still rely on a single on/off signal, but hardware switches are now more sophisticated (requiring, say, a simple head nudge). Software now does a better job of interpreting and predicting the intent behind that signal: Your onscreen keyboard may divide and subdivide itself into quadrants for you until the right letter appears under your cursor and also predict the words you wish to type.
How does this adaptive technology relate to accessible Web design? Page navigation becomes the big issue. If you the Website visitor are using particularly primitive adaptive technology (or none at all – some disabled people are too poor, or too proud and stubborn, to modify their machines), you may be stuck pressing the Tab key repeatedly to move from link to link, from link to image, from field to image, and every other combination within a Web page. If your site loads up three dozen (or a hundred, or 200) navigational links in a left-hand table cell, a visitor with this disability has to tab through them one at a time.

Just how long would you put up with that, if you don’t already?

Fortunately, there are solutions – usually not great and often not really enough, but solutions nonetheless. I’ll get to those in Chapter 8, “Navigation.”

Hearing impairment
The access requirements of deaf and hard-of-hearing people are quite modest given that, even in a post-Napster demimonde, computers are largely silent devices that communicate visually. You can, for example, simply turn the alert-sound volume to zero, which might cause the menubar to flash as a replacement for an audible beep.

Adaptive technology? There really isn’t any. A hard-of-hearing person may use amplified headphones or a particularly high-powered speaker, but those are off-the-shelf additions with no bearing on Web design or programming.

Visual impairment
Of all the disabilities affected by computer use, visual impairment is the most significant. As we have seen with devices varying as widely as the Palm (and the Newton – remember the Newton?) and a range of tablet computers and Internet refrigerators and whatnot, in real-world use a computer is mostly a display. And if you can’t see a display, how do you use a computer?

Well, if you have a relatively modest visual impairment, all you may need is screen magnification. You can blow up the size of text, menubars, icons, and everything else to any necessary size. (That really means everything else. Your whole system, including menubars, has to be made accessible, not just the text in a single window in a browser.) Software designed just for this purpose can also scroll text horizontally for you within a window of fixed position, alter foreground and background colours, and turn the mouse cursor into a moving magnifying glass.

(Don’t underestimate the issue of screen colours. Many visually-impaired people find dark text on a brilliant white background unbearable. Such settings are quite easy to change for Web sites, as we’ll see in Chapter 9, “Type and colour,” but it’s a process of trial and error, and if you, as a Web author, don’t code your pages properly, your text might just disappear altogether!)

If you’re blind enough that you can’t really see a monitor, you need something called a screen reader – a program that reads aloud onscreen text, menus, icons, and the like.

(They’re not called “talking browsers,” “text readers”, or “speech browsers.” There’s one and only one generic term for the technology: Screen reader. Having made this categorical declaration, I note that there are programs that do nothing but provide voice output for Web browsers to the exclusion of all other software on a computer, like IBM Home Page Reader and pwWebSpeak, and I suppose we could call those talking browsers, but I am eliding that distinction for the purposes of this book.)

Screen readers don’t simply spit out a monotonous sequential verbal itemization of a Web page. Developed in the late 1970s on character-mode platforms like Apple II and MS-DOS, screen readers have evolved out of view of the rest of the computer industry, like some form of underground dance music beloved by recherché klub kidz worldwide but unknown to their parents. Screen readers are sophisticated enough to use multiple voices and (limited) sound effects to interpret Web sites. It’s quite commonplace to listen to screen-reader speech at speeds no human being, not even an auctioneer, could produce. At 300 words a minute (twice the speed of a vibrant human conversation), you can zip through even a verbose Web page pretty efficiently, though that is no excuse for you to produce verbose Web pages.

One crucial fact to understand about screen readers, though: They’re run from the keyboard. The mouse is still usable but in practice is not used. A mouse requires hand-eye coördination, and a blind person is missing half of that. Accordingly, anything you design that seems to require a mouse also has to work without one.

Another curious factoid: Some totally-blind people don’t bother installing a monitor at all. (Computers can often run “headless.”)

A deaf-blind person will rely exclusively on a Braille display: Nylon or metal pins controlled by software protrude upward through a grid, forming the cells used in Braille writing. Characters are replaced (“refreshed”) either automatically at intervals or after you press a switch. Typical Braille displays reveal two to four lines of text, but truly gigantic displays, almost equivalent to the 80-character-by-24-row screens of MS-DOS, can also be found, at prices rivaling the equivalent weight in platinum.

While a few blind people rely on Braille displays alone, without screen readers, of more interest are the few super-elite blind people who use a Braille display in tandem with a screen reader. One such use: The screen reader speaks onscreen text and interface elements, while the Braille display gives system and status-line messages. Practical for blind computer programmers especially.

Since the canonical group served by Web accessibility is indeed the blind and visually-impaired, the bulk of this book is devoted to documenting how to accommodate them.

Learning disabilities
Without a doubt the most neglected disability group online, and, not coincidentally, the very hardest to accommodate, learning-disabled Web surfers face frustrating barriers.

The issue here is comprehension of visible language in the broadest sense. Words are the biggest problem, one that is ostensibly alleviated by providing pictures and sounds. Yet even pictures and sounds may cause confusion, particularly if all the above are provided simultaneously. (I specifically advocate watching, listening, and reading simultaneously in Chapter 13, “Multimedia,” but that may be unsuitable for a section of this population.)

However, the essence of the Web is text. Almost no Websites lack text altogether, and that cohort tends to cluster around all-Flash experimentation (like Praystation.com); while the Web is the delivery mechanism for such experiments, it is debatable whether they actually are Websites at all rather than online cinema.

Text is not a feature of Websites; it is a primitive, a fundamental and unalterable component.

An existing requirement of the Web Accessibility Initiative’s Web Content Accessibility Guidelines (Nº 14, “Ensure that documents are clear and simple so they may be more easily understood”) makes a feeble and inconsequential effort at solving the inaccessibility of textual Websites for people who cannot read well. Checkpoint 14.1 tells us: “Use the clearest and simplest language appropriate for a site’s content.” Nowhere does this guideline explain how you will afford an editor for your site, or how you or that editor will know in specific how to write so that learning-disabled people can understand you. Are there proven techniques? And if so, how do they apply to the tens of thousands of topics discussed online?

As I write this book, the Web Accessibility Initiative is actively considering an update to its Web Content Accessibility Guidelines that would require all Web authors – everywhere and without exception – to add images or other “non-text content” to their Websites if they wish their sites to be certified as complying with the WCAG. Essentially every concept would require an illustration, irrespective of these undeniable facts:

Some concepts cannot be illustrated. (Remember the parlour game on The Simpsons in which the Simpsons’ neighbours, the Van Houtens, are asked to illustrate “dignity”? Luanne Van Houten actually does it, but we never see the actual drawing, rather proving the point. I hope it is not bathetic to suggest the WCAG learn from cartoons.)
Many Web authors are not professional illustrators; many do not own illustration software.
The requirement discriminates against other disabled groups: How do blind Webmasters draw pictures?
Similarly, each added image or multimedia file requires an equivalent (like an alt text or captioning). The addition of images implies the addition of more text, a tautology and a source of frustration for blind visitors.
Image and multimedia files cause page sizes, hence download times, to balloon, in turn harming usability.
The requirement naïvely assumes that all Websites are custom-created and continuously overseen by expert human beings; many Websites, like discussion fora and mailing-list archives, are autogenerated by software. Many pages at the World Wide Web Consortium’s own site, W3.org, fall into this category. How do we illustrate them?
There is no proof that illustrations will be as effective at guaranteeing comprehension for the learning-disabled as, say, alt texts are for the blind.
It is not at all clear that this proposed requirement will actually be ratified by the World Wide Web Consortium; it faces strong and reasoned opposition from people like me. The needs of learning-disabled Web visitors and everyone else with a mental impairment are real; they’re also ill-understood by Web designers and by Web-accessibility experts both.

Still, the proposed cure is worse than the disease. It is apparent that there is no practical way to make textual Websites genuinely accessible to people who cannot read well. Q.E.D.

So what are the real options? They don’t have a lot to do with your work as a designer or developer. The use of adaptive technology in accommodating learning disabilities is relatively uncommon, but the big surprise is how applicable the gear intended for the blind can be. Dyslexic kids and adults often find speech output useful, though usually at far slower speeds than blind users are accustomed to. Screen magnification is helpful. There’s certain limited evidence (included on this book’s CD-ROM) that audio description helps kids with dyslexia concentrate. Long descriptions, used for blind access to Websites, may work the same way, but there is no research on that topic.

There is no plan of action available to you in order to accommodate learning-disabled visitors in the way that plans of action are available for other disability groups, however contingent and fractured those latter plans might be. There are no simple coding or programming practices – or even complex practices, for that matter – in which you can engage to accommodate this group.

We are left with the knowledge that our sites are inaccessible to a known group with next to nothing we can do about it. However antithetical that may seem at first blush, in fact it responds to the real world. Recall that antidiscrimination legislation includes exemptions for undue hardship or burden. Recall also that some features of the physical world cannot be made accessible without destroying or fundamentally altering them – antique streetcars, for example, or the ancient pyramids. On all counts, these are unavoidable exceptions which we have no choice but to live with.