The Basics: Involving People with Disabilities in Your Project

The primary focus of Part II of this book is to assist usability professionals in incorporating accessible design practices into User-Centered Design (UCD) processes. However, you don't have to be a usability professional and you don't have to do UCD to benefit from the information in this book. This chapter leads you through shortcuts to involving people with disabilities in design projects.

For most products there are accessibility standards or guidelines available that provide a primary guide for ensuring that your product is designed to be accessible. For example, the W3C WAI Web Content Accessibility Guidelines (WCAG) are comprehensive standards for websites and web applications. The Design Phase chapter discusses the importance of using accessibility guidelines in design.

However, standards and guidelines are only part of the equation for effectively developing accessible products. The other part is understanding accessibility issues; and the best way to do that is to work with people with disabilities to learn how they interact with your products.

A Little Background and an Example

For a brief introduction to product accessibility, see "What Is Accessibility?" in the Background: Accessibility and User-Centered Design (UCD) section. For a comprehensive introduction to web accessibility specifically, see Understanding Web Accessibility.

Some people with disabilities use assistive technologies, which are software and hardware that people with disabilities use to improve interaction with products. Examples of assistive technologies include screen readers that read aloud what's on the computer screen for people who cannot see or read text, and voice-input software and switches for people who cannot use a keyboard or mouse. An official definition of assistive technologies is: Any item, piece of equipment, product, system or software, whether acquired commercially off the shelf, modified, or customized, that is used to increase, maintain, or improve functional capabilities of individuals with disabilities.

Next, a little background to help you understand the next anecdote. When a screen reader comes to an image on a web page, it reads the "alt text", which should provide the same information in text as the image provides visually. The web developer writes the alt text when she creates the web page.

"Chainsaw squirrel cycling? That sounds horrible," exclaimed a screen reader user while testing the parks section of a website. Three images in a row had the alt text "chainsaw", "squirrel", and "cycling". Below the images were "forestry", "wildlife conservation," and "outdoor activities".

The alt text for these images passed accessibility standards; however, they certainly did not provide a good user experience. This chapter helps you develop a good user experience by involving people with disabilities in your project.

High ROI (Return on Investment)

Including people with disabilities on your project team may seem like a daunting proposition. While it may not be feasible for some small projects, if you can do it, it will be well worth the effort. From a little effort to include people with disabilities in your web development, you will get a lot of benefit, including:

Motivation: When product designers, managers, and other project stakeholders see people with disabilities use their product, most are highly motivated by a new understanding of accessibility issues.
Efficiency: Including users with disabilities early in a project helps designers be more efficient in addressing accessibility, thus maximizing the results from investment in accessibility. You can more quickly develop accessibility solutions, and spend less time guessing and having to go back and fix problems.
Effectiveness: The better you understand the issues, the better you can implement more effective accessibility solutions.

Getting Started

Start by learning a bit about how disabilities impact the way that people use your product. You can find many free resources on the Web. For example, for people developing websites, How People with Disabilities Use the Web describes in detail how different disabilities affect web use and includes scenarios of people with disabilities using the Web, and Introduction to the Screen Reader is a short video.

Organizations that can afford it might want to get training from an accessibility consultant or employee who has first-hand experience with how people with different disabilities interact with products.

We have a short interactive workshop where designers learn the basics of how people with disabilities use their products. It includes videos, hands-on activities, and a chance to talk with people with disabilities. It's eye-opening and fun, and designers get really jazzed up about addressing accessibility in their products.

See also "Understanding Computer Use by People with Disabilities" in the Appendix: Resources for a list of videos and documents.

Finding People with Disabilities

The next step is finding a few people with disabilities. See "Recruiting Participants with Disabilities" in Planning Usability Testing for a list of places to contact when looking for people with disabilities. Find people close to your target users. For example, for a website to apply for college loans, it would be better to get 18-year-olds rather than 80-year-olds.

Find people who are fairly experienced using products like yours. If people use assistive technologies with your product, you probably want people who are skilled with their assistive technology. Later in testing you might want to include some novices, but early on you want people who can teach you well.

Include people with different disabilities and characteristics. People with disabilities are as diverse as any other people. They use diverse interaction techniques, adaptive strategies, and assistive technology configurations. People have different disabilities: visual, auditory, physical, speech, cognitive, and neurological—and many have multiple disabilities.

Because of this diversity, ideally you would include several users with different disabilities. In reality, the number of users will be limited by time and money constraints. That's why it's important to also use comprehensive guidelines or standards that cover the diversity.

Even if you can only include one person, do. See "Individual Differences" in the Analysis Phase chapter, which says to avoid assuming that one user represents all and that feedback from one person with a disability applies to all people with disabilities.

For more guidance on selecting people with disabilities to help with your project, see "Determining Participant Characteristics" in Planning Usability Testing. While that section is focused on usability testing, most of it also applies to including users early in a project:

"Careful with categorization" gives examples of the differences in disabilities.
"Assistive technology (AT)" explains the impact of people's skill with their assistive technology.
"Identifying a realistic range of participants" helps figure out which disabilities to include in your recruiting based on target users and highest impact.

Assistive Technology and Location

When recruiting people with disabilities and planning work with them, remember that if a person uses assistive technology to interact with your product, you'll need to arrange for it during your work together. If she can bring her own assistive technology to your site, that's probably best. If not, you could get the assistive technology for your site. However, many assistive technologies are very expensive and demo versions are limited.

In some cases, it might be best to go to the user's work or home, rather than having the user come to you. A downside to this is that fewer people from your project team get direct interaction with the user. See "Choosing the Best Location" in the Planning Usability Testing chapter for more considerations.

Learning from People with Disabilities

Once you're sitting down with the user, make sure he has a chance to get things (such as chair, computer, and assistive technology) set up how he likes. Then start out by having him show you some similar products that work well for him. It's important to do this first, so you get an idea how things can work well, and he can confirm that the setup is as he expects. Ask a lot of questions to learn how things work.

Then you can have him show you things that don't work. Keep in mind that any problems are probably because of the product design; however, if he is using assistive technology and is a novice, there is a chance that he doesn't know how to get his assistive technology to work well with your product.

If you're redesigning an existing product, have him show you how he uses it. If you already have an idea of how you might redesign your product, ask him to use products that have similar designs. See also "Evaluate Example Products" in the Design Phase chapter.

Tell your users ahead of time what you'll want them to do. Tell them what type of products you'll have for them to use. Ask if they have similar products that they can bring with them to show you examples of good and bad accessibility. Tell them if there are areas you want to focus on, such as button design or menu navigation. The better prepared they are, the more you all will get out of it.

Maximizing Benefits

To maximize the benefit of this time with users, encourage several people from your project to participate, including designers and managers. Consider recording it to share with those who couldn't be there. Of course, make sure you find users who are comfortable with this and have the users sign a consent form before recording. Some people will appreciate a large audience learning about accessibility; others would be uncomfortable with several people watching them or with being recorded.

In addition to involving users early in a project to help you understand accessibility issues, include users with disabilities throughout the project as you develop prototypes. When you have an idea that you are considering, have users test it. That way you can make any necessary fixes before you get too far along the development process.

See the Usability Testing for Accessibility chapter for more information on including people with disabilities. It is written for formal usability testing so some of it won't apply to informal interaction early in project development. Much of it does apply, such as ensuring that the facility is accessible, setting up the room, and interacting with people with specific disabilities.

While there are many things to consider when involving people with disabilities in your project, you don't need to worry about getting everything just right. As long as you are respectful, most people with disabilities will appreciate your efforts and not be bothered by any blunders.

When we first started inviting people with disabilities into our projects, we mentioned that we were new to it and that we were very open to advice. We received lots of great information, as well as patience when things didn't go smoothly.

The next chapter gives you some guidance on interacting with people with disabilities comfortably.

References

Some of the information in this chapter was previously published in:

Henry, S.L. "Understanding Web Accessibility", Web Accessibility: Web Standards and Regulatory Compliance. Berkeley, CA: friends of ED/Apress, 2006.