Don't Make Me Think, Second Edition: A Common Sense Approach to Web Usability | WebReference

Don't Make Me Think, Second Edition: A Common Sense Approach to Web Usability

Don't Make Me Think, Second Edition: A Common Sense Approach to Web Usability

Excerpted from "Don't Make Me Think, Second Edition: A Common Sense Approach to Web Usability" by Steve Krug. Copyright © 2006. Used with the permission of Pearson Education, Inc. and New Riders.

Chapter 11: Accessibility, Cascading Style Sheets, and you


When a cat is dropped, it always lands on its feet, and when toast is dropped, it always lands with the buttered side facing down. I propose to strap buttered toast to the back of a cat; the two will hover, spinning, inches above the ground. With a giant buttered-cat array, a high-speed monorail could easily link New York with Chicago.


People sometimes ask me, "What about accessibility? Isn't that part of usability?" And they're right, of course. Unless you're going to make a blanket decision that people with disabilities aren't part of your audience, you really can't say your site is usable unless it's accessible.

At this point,1 everyone involved in Web design knows at least a little bit about Web accessibility, even if it's only that there's something special about the number 508.2 And yet almost every site I go to fails my three-second accessibility test—increasing the size of the type.

Why is that?

1 2005 AD
2 In case you've literally been hiding under a rock for the past few years, "508" refers to Section 508 of the 1988 Amendments to the Rehabilitation Act, which specifies accessibility standards for information technology (like Web sites) that must be met by any vendor that wants to do business with the U.S. government.

What developers and designers hear

In most organizations, the people who end up being responsible for doing something about accessibility are the people who actually build the thing: the designers and the developers.

When they try to learn about what they should do, whatever books or articles they pick up inevitably list the same set of reasons why they need to make their sites accessible:

There's a lot of truth in all of these. Unfortunately, there's also a lot that's unlikely to convince 26-year-old developers and designers that they should be "doing accessibility." Two arguments in particular tend to make them skeptical:

> Since their world consists largely of able-bodied 26-year-olds, it's very hard for them to believe that a large percentage of the population actually needs help accessing the Web. They're willing to write it off as the kind of exaggeration that people make when they're advocating for a worthy cause, but there's also a natural inclination to think, "If I can poke a hole in one of their arguments, I'm entitled to be skeptical about the rest."

> They're also skeptical about the idea that making things more accessible benefits everyone. Some adaptations do, like the classic example, closed captioning, which does often come in handy for people who can hear.3 But since this always seems to be the only example cited, it feels a little like arguing that the space program was worthwhile because it gave us Tang.4 It's much easier for developers and designers to imagine cases where accessibility adaptations are likely to make things worse for "everyone else."

The worst thing about this skepticism is that it obscures the fact that there's really only one reason that's important:

> It's the right thing to do.

And not just the right thing; it's profoundly the right thing to do, because the one argument for accessibility that doesn't get made nearly often enough is how extraordinarily better it makes some people's lives. Personally, I don't think anyone should need more than this one example: Blind people with access to a computer can now read the daily newspaper on their own. Imagine that.

How many opportunities do we have to dramatically improve people's lives just by doing our job a little better?

And for those of you who don't find this argument compelling, be aware that there will be a legislative stick coming sooner or later. Count on it.

What designers and developers fear

As they learn more about accessibility, two fears tend to emerge:

> More work. For developers in particular, accessibility can seem like just one more complicated new thing to fit into an already impossible project schedule. In the worst case, it gets handed down as an "initiative" from above, complete with time-consuming reports, reviews, and task force meetings.

> Compromised design. What designers fear most is what I refer to as buttered cats: places where good design for people with disabilities and good design for everyone else are going to be in direct opposition. They're worried that they're going to be forced to design sites that are less appealing—and less useful—for the majority of their audience.

3 Melanie and I often use it when watching British films, for instance.
4 A powdered orange-flavored breakfast drink, invented for the astronauts (see also: freezedried food).

In an ideal world, accessibility would work like a sign I saw in the back of a Chicago taxi. At first it looked like an ordinary sign. But something about the way it caught the light made me take a closer look, and when I did, I realized that it was ingenious.

The sign was overlaid with a thin piece of Plexiglas, and the message was embossed in Braille on the Plexiglas. Ordinarily, both the print and the Braille would have been half as large so they could both fit on the sign, but with this design each audience got the best possible experience. It was an elegant solution.

I think for some designers, though, accessibility conjures up an image something like the Vonnegut short story where the government creates equality by handicapping everyone.5

5 In "Harrison Bergeron," the main character, whose intelligence is "way above normal," is required by law to wear a "mental handicap radio" in his ear that blasts various loud noises every 20 seconds "to keep people like George from taking unfair advantage of their brains."

Created: March 27, 2003
Revised: November 22, 2005