by Steve Krug

  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 redish.net/images/stories/PDF/InteractionsPaperAuthorsVer.pdf. 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:

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

  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:

  Add appropriate alt text to every image. Add an empty (or “null”) alt attribute () 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 webaim.org. The folks at WebAIM have written excellent practical articles covering the nuts-and-bolts details of almost every accessibility technique.

  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

for the page title or main content heading,

for the major section headings,

for subheadings, and so on, and then use CSS to redefine the visual appearance of each level.

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

  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.

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

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

  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.

  Sigh.

  Hopefully we’ll have better luck this time.

  Chapter 13. Guide for the perplexed1

  1 The Guide for the Perplexed (the real one) is a seminal commentary on the meaning of the Talmud written in the 12th century by Rabbi Moshe ben Maimon (better known as Maimonides). I’ve just always thought it was the best title I’ve ever heard.

  MAKING USABILITY HAPPEN WHERE YOU LIVE

  I am the Lorax. I speak for the trees.

  —THE LORAX, DR. SEUSS

  I get a lot of email from people asking me some variation of this question:

  OK, I get it. This usability stuff is important, and I really want to work on it myself. How do I convince my boss—and his boss—that they should be taking users seriously and allow me to spend time making it happen?

  What can you do if you find yourself in an environment where your desire to “do usability” isn’t supported?

  Ya gotta know the territory

  First, a little background about how the place of usability in the world has changed.

  Back in the late 1990s, Usability and User Centered Design (UCD) were the terms most people used to describe any efforts to design with the user in mind. And there were essentially two “professions” that focused on making Web sites more usable: Usability (making sure things are designed in a way that enables people to use them successfully) and Information Architecture (making sure the content is organized in a way that allows people to find what they need).

  Now the term you hear most often is User Experience Design, or just User Experience (UXD or UX, for short), and there are probably a dozen specialties involved, like Interaction Design, Interface Design, Visual Design, and Content Management—and, of course, Usability and Information Architecture—all under the UX umbrella.

  One difference between User Centered Design and User Experience Design is their scope. UCD focused on designing the right product and making sure that it was usable. UX sees its role as taking the users’ needs into account at every stage of the product life cycle, from the time they see an ad on TV, through purchasing it and tracking its delivery online, and even returning it to a local branch store.

  The good news is that there’s a lot more awareness now of the importance of focusing on the user. Steve Jobs (and Jonathan Ive) made a very compelling business case for UX, and as a result usability is an easier sell than it was even a few years ago.
/>   The bad news is that where usability used to be the standard bearer for user-friendly design, now it’s got a lot of siblings looking for seats at the table, each convinced that their set of tools are the best ones for the job. The worse news is that not many people understand the differences between the specialties or the unique contributions they can make.

  This is the field you’re playing on. So when someone tells you: “I’m in UX” or “Usability is so 2002—it’s all UX now,” smile graciously and ask them a few questions about how they’re learning about users, how they’re testing whether people can use what they’re building, and how they get changes to happen. If they don’t do any of those things, they need your help. If they do, learn from them. It’s not what we call ourselves that matters, it’s the attitude we bring and the skills we can contribute.

  The usual advice

  Here are the two suggestions I’ve always heard for convincing management to support (and fund) usability work:

  Demonstrate ROI. In this approach, you gather and analyze data to prove that a usability change you’ve made resulted in cost savings or additional revenue (“Changing the label on this button increased sales by 0.25%”). There’s an excellent book about it: Cost-justifying Usability: An Update for the Internet Age, edited by Randolph Bias and Deborah Mayhew.

  Speak their language. Instead of talking about the benefits for users, learn what the current vexing corporate problems are and describe your efforts in a way that makes it clear that they’re part of the solution: Talk about things like pain points, touch points, KPIs, and CSI, or whatever management buzzwords are trending in your organization.

  These are both fine ideas and worth doing if you can manage it. But making an ROI case tied to costs and revenues can be a lot of work, and unless it’s rigorously implemented there’ll always be someone who’ll claim that the added value was caused by something else. And learning to speak “business” can be challenging, too. That’s what MBA degrees are for.

  If I were you...

  ...I’d last about a week at your job. Every time I go to a client’s office I spend most of my time marveling at the fact that so many people can survive in the corporate world. I’m just not equipped for dealing with the office politics in a large (i.e., more than two people) organization and sitting in meetings all day.

  But I have spent a fair amount of time visiting corporate offices and getting managers to take usability seriously. So I do have some ideas about tactics that work, and people who have tried them tell me they’ve had some success. So here’s what I’d do if I were you:

  Get your boss (and her boss) to watch a usability test. The tactic that I think works best is getting people from higher up the food chain to come and observe even one usability test. Tell them that you’re going to be doing some testing and it would be great for the Web team’s morale if they could just poke their head in for a few minutes.

  In my experience, executives often become fascinated and stay longer than they’d planned, because it’s the first time they’ve seen anyone try to use the company’s site and it’s often not nearly as pretty a picture as they’d imagined.

  It’s important to get them to come in person. The difference between watching a usability test live and hearing a presentation about it is like the difference between watching a sporting event while it’s happening versus listening to a recap of it on the evening news. Live games create memorable experiences; the evening news not so much.

  If you can’t get them to come, then settle for second best: include clips of highlights from tests in your presentations. If you don’t get to do a presentation, post a short clip (less than 3 minutes) on your intranet and send out email with an intriguing description and a link to the video. Even executives like watching short videos.

  Do the first one on your own time. When you do your first test, don’t ask for permission; just keep it incredibly simple and informal, and find volunteers for participants so it doesn’t cost anything.

  And try to make sure that something improves as a result. Pick an easy target to test—something that you know has at least one serious usability problem that can be fixed quickly without having to get a lot of people to sign off on the change—renaming a poorly labeled button, for instance. Then test it, fix it, and publicize it.

  If you can find a simple way to measure the improvement, do so. For instance, you might test something that’s been causing a lot of support calls and then show how much the calls on that issue decreased after you fixed the problem.

  Do a test of the competition. I mentioned in Chapter 9 that it’s a good idea to test some competitive sites at the start of any project. But it’s also a great way to drum up support for testing. Everybody loves learning about the competition, and because it’s not your site being tested, no one has anything personally on the line. It makes a great brown bag lunch event.

  Empathize with management. A few years ago at the UXPA annual conference, I looked around and thought “What a nice group of people!” Then it dawned on me: of course they’re nice. Empathy is virtually a professional requirement for usability work. And if you’re interested in doing it, you’re probably empathetic too. I recommend that you apply that empathy to your bosses. Not in the “how can I figure out what motivates these people so I can get them to do what I want” way, but more in the “understand the position they find themselves in” way, having real, emotional empathy for them. You may be surprised by the effect.

  Know your place in the grand scheme of things. Personally, in the situation you’re in, I think a little bit of humility goes a long way. The reality is that in the business world almost everyone is just a very small cog in a huge collection of cogs.2

  2 Sorry. Try not to take it personally. Do good work. Enjoy your home life. Be happy.

  You want your enthusiasm for usability to be infectious, but it just doesn’t work to go around with the attitude that you’re bringing the truth—about usability, or anything else—to the unwashed masses. Your primary role should be to share what you know, not to tell people how things should be done.

  I’d also recommend two books that can help.

  First there’s Tomer Sharon’s It’s Our Research: Getting Stakeholder Buy-In for User Experience Research Projects. Tomer is a UX Researcher at Google, and I’ve never heard him say anything that wasn’t true, pithy, and actionable.

  Any book with section titles like “Become the voice of reason” and “Accept the fact that it might not work and that it’s okay” is obviously worth reading.

  Leah Buley’s The User Experience Team of One: A Research and Design Survival Guide is written specifically for people who are “the only person in your company practicing (or aspiring to practice) user centered design” or who “regularly work on a team where you are the only UX person.” Chapters 3 (Building Support for Your Work) and 4 (Growing Yourself and Your Career) are full of good advice and useful resources.

  Resist the dark forces

  Usability is, at its heart, a user advocate job: Like the Lorax, you speak for the trees. Well, the users, actually. Usability is about serving people better by building better products.

  But there’s a trend—which I first noticed about five years ago—for some people3 to try to get usability practitioners to help them figure out how to manipulate users rather than serve their needs.4

  3 [cough] marketing [cough]

  4 There’s even a book called Evil by Design: Interaction Design to Lead Us into Temptation by Chris Nodder that explains how an understanding of human frailties can guide your design decisions. Each chapter deals with one of the Seven Deadly Sins (Gluttony, Pride, Sloth, and so on).

  I have no problem with the idea of people asking for our help influencing users.

  If you want to know how to influence people, just read Robert Cialdini’s classic book on the subject, Influence: The Psychology of Persuasion. It’s brilliant and effective, full of time-proven ideas.

  Or read any of Susan Weinschen
k’s books about the useful lessons that neuropsychology research can teach us about human motivation and decision making.

  I don’t have a problem with helping to persuade people to do things, either, as long as it’s not deceptive. The think-aloud protocol in usability tests can often produce valuable insights into why attempts at persuasion succeed or fail.

  But I get anxious whenever I hear people talk about using usability tests to help determine whether something is desirable, because it’s just not something usability tests are good for measuring. You may get a sense during a test session that the participant finds something desirable, but it’s just that: a sense. Whether something is desirable is a market research question, best answered by using market research tools and instruments.

  The real problem is that these people often aren’t actually asking for our help determining whether something is desirable, or even for help in figuring out how to make what they produce more desirable. Instead, they’re looking to usability to tell them how to make people think it’s desirable, i.e., to manipulate them.

  Sometimes the intended manipulation is relatively benign, like using a slightly hidden checkbox checked by default to automatically sign you up for a newsletter.

  Sometimes it inches closer to the darkness, doing things like tricking people into installing an unwanted browser toolbar5 and changing their default search and Home page settings while they’re not looking. We’ve all been on the receiving end of this kind of deception.

  5 [cough] Yahoo [cough]

  You click on a link to download some free software.