Accessibility and you - Larger Concerns and Outside Influences - Don’t Make Me Think, Revisited: A Common Sense Approach to Web Usability (2014)

Don’t Make Me Think, Revisited: A Common Sense Approach to Web Usability (2014)

Part IV. Larger Concerns and Outside Influences

Chapter 12. Accessibility 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, everyone involved in Web design knows at least a little bit about Web accessibility. And yet almost every site I go to still fails my three-second accessibility test—increasing the size of the type.1

1 If you’re about to send me email reminding me that Zoom has replaced Text Size in most browsers, thanks, but you can save those keystrokes. Every site gets larger if you use Zoom, but only sites that have moved beyond fixed-size fonts (usually a good indicator of effort to make things accessible) respond to Text Size.




After (no difference)

Why is that?

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 22-year-old developers and designers that they should be “doing accessibility.” Two arguments in particular tend to make them skeptical:

Image ___% of the population has a disability. Since their world consists largely of able-bodied 22-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 one of their claims is so clearly untrue, I’m entitled to be skeptical about the rest.”

Image Making things more accessible benefits everyone. They know that some adaptations do, like the classic example, closed captioning, which does often come in handy for people who can hear.2 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.3 It’s much easier for developers and designers to imagine cases where accessibility adaptations are likely to make things worse for “everyone else.”

2 Melanie and I often use it when watching British films, for instance.

3 A powdered orange-flavored breakfast drink, invented for the astronauts (see also: freeze-dried food).

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

Image 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 almost any newspaper or magazine 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 even if you haven’t already encountered it, 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:

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

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

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

4 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.”

The truth is, it can be complicated

When people start reading about accessibility, they usually come across one piece of advice that sounds very promising:


The problem is, when they run their site through a validator, it turns out to be more like a grammar checker than a spell checker. Yes, it does find some obvious mistakes and oversights that are easy to fix, like missing alt text.5 But it also inevitably turns up a series of vague warnings that youmay be doing something wrong and a long list of recommendations of things for you to check that it admits may not be problems at all.

5 Alt text provides a text description of an image (“Picture of two men on a sailboat,” for example), which is essential for people using screen readers or browsing with images turned off.

This can be very discouraging for people who are just learning about accessibility, because the long lists and ambiguous advice suggest that there’s an awful lot to learn.

And the truth is, it’s a lot harder than it ought to be to make a site accessible.

After all, most designers and developers are not going to become accessibility experts. If Web accessibility is going to become ubiquitous, it’s going to have to be easier to do. Screen readers and other adaptive technologies have to get smarter, the tools for building sites (like Dreamweaver) have to make it easier to code correctly for accessibility, and our design processes need to be updated to include thinking about accessibility from the beginning.

The four things you can do right now

The fact that it’s not a perfect world at the moment doesn’t let any of us off the hook, though.

Even with current technology and standards, it’s possible to make any site very accessible without an awful lot of effort by focusing on a few things that will have the most impact. And they don’t involve getting anywhere near a buttered cat.

#1. Fix the usability problems that confuse everyone

One of the things that I find annoying about the Tang argument (“making sites accessible makes them more usable for everyone”) is that it obscures the fact that the reverse actually is true: Making sites more usable for “the rest of us” is one of the most effective ways to make them more effective for people with disabilities.

If something confuses most people who use your site, it’s almost certain to confuse users who have accessibility issues. (After all, people don’t suddenly become remarkably smarter just because they have a disability.) And it’s very likely that they’re going to have a harder time recovering from their confusion.

For instance, think of the last time you had trouble using a Web site (running into a confusing error message when you submitted a form, for example). Now imagine trying to solve that problem without being able to see the page.

The single best thing you can do to improve your site’s accessibility is to test it often, and continually smooth out the parts that confuse everyone. In fact, if you don’t do this first, no matter how rigorously you apply accessibility guidelines, people with disabilities still won’t be able to use your site. If it’s not clear to begin with, just fixing code problems is like [insert your favorite putting-lipstick-on-a-pig metaphor here].

#2. Read an article

As I hope you’ve seen by now, the best way to learn how to make anything more usable is to watch people actually try to use it. But most of us have no experience at using adaptive technology, let alone watching other people use it.

If you have the time and the motivation, I’d highly recommend locating one or two blind Web users and spending a few hours with them observing how they actually use their screen reader software.

Fortunately, someone has done the heavy lifting for you. Mary Theofanos and Janice (Ginny) Redish watched 16 blind users using screen readers to do a number of tasks on a variety of sites and reported what they observed in an article titled “Guidelines for Accessible and Usable Web Sites: Observing Users Who Work with Screen Readers.”6

6 Published in the ACM magazine Interactions (November-December 2003). With permission from ACM, Ginny has made it available for personal use at Yes, it’s ten years old, but it’s still relevant.

As with any kind of user testing, it produced invaluable insights. Here’s one example of the kinds of things they learned:

Screen-reader users scan with their ears. Most blind users are just as impatient as most sighted users. They want to get the information they need as quickly as possible. They do not listen to every word on the page—just as sighted users do not read every word. They “scan with their ears,” listening to just enough to decide whether to listen further. Many set the voice to speak at an amazingly rapid rate.

They listen to the first few words of a link or line of text. If it does not seem relevant, they move quickly to the next link, next line, next heading, next paragraph. Where a sighted user might find a keyword by scanning over the entire page, a blind user may not hear that keyword if it is not at the beginning of a link or a line of text.

I recommend that you read this article before you read anything else about accessibility. In 20 minutes, it will give you an appreciation for the problems you’re trying to solve that you won’t get from any other articles or books.

#3. Read a book

After you’ve read Ginny and Mary’s article, you’re ready to spend a weekend reading a book about Web accessibility. These two are particularly good:

Image A Web for Everyone: Designing Accessible User Experiences by Sarah Horton and Whitney Quesenbery. (Their approach: “Good UX equals good accessibility. Here’s how to do both.”)

Image Web Accessibility: Web Standards and Regulatory Compliance by Jim Thatcher et al. (“Here are the laws and regulations, and we’ll help you understand how to meet them.”)


These books cover a lot of ground, so don’t worry about absorbing all of it. For now, you just need to get the big picture.

#4. Go for the low-hanging fruit

Now you’re ready to do what most people think of as Web accessibility: implementing specific changes in your pages.

As of right now, these are probably the most important things to do:

Image Add appropriate alt text to every image. Add an empty (or “null”) alt attribute (<alt="">) for images that screen readers should ignore, and add helpful, descriptive text for the rest.

To learn how to write good alt text—and in fact to learn how to do any of the things in this list—head over to The folks at WebAIM have written excellent practical articles covering the nuts-and-bolts details of almost every accessibility technique.

Image Use headings correctly. The standard HTML heading elements convey useful information about the logical organization of your content to people using screen readers and make it easier for them to navigate via the keyboard. Use <h1> for the page title or main content heading, <h2> for the major section headings, <h3> for subheadings, and so on, and then use CSS to redefine the visual appearance of each level.

Image Make your forms work with screen readers. This largely boils down to using the HTML <label> element to associate the fields with their text labels, so people know what they’re supposed to enter.

Image Put a “Skip to Main Content” link at the beginning of each page. Imagine having to spend 20 seconds (or a minute, or two) listening to the global navigation at the top of every page before you could look at the content, and you’ll understand why this is important.

Image Make all content accessible by keyboard. Remember, not everyone can use a mouse.

Image Create significant contrast between your text and background. Don’t ever use light grey text on a dark grey background, for instance.

Image Use an accessible template. If you’re using WordPress, for example, make sure that the theme you choose has been designed to be accessible.

That’s it. You’ll probably learn how to do a lot more as you go along, but even if you do only what I’ve covered here, you’ll have made a really good start.

When I wrote this chapter seven years ago, it ended with this:

Hopefully in five years I’ll be able to just remove this chapter and use the space for something else because the developer tools, browsers, screen readers, and guidelines will all have matured and will be integrated to the point where people can build accessible sites without thinking about it.


Hopefully we’ll have better luck this time.