Usable Accessibility: Making Web Sites Work Well for People with Disabilities

“Accessibility often gets pigeon-holed as simply making sure there are no barriers to access for screen readers or other assistive technology, without regard to usability.”

When people talk about both usability and accessibility, it is often to point out how they differ. Accessibility often gets pigeon-holed as simply making sure there are no barriers to access for screen readers or other assistive technology, without regard to usability, while usability usually targets everyone who uses a site or product, without considering people who have disabilities. In fact, the concept of usability often seems to exclude people with disabilities, as though just access is all they are entitled to. What about creating a good user experience for people with disabilities—going beyond making a Web site merely accessible to make it truly usable for them?

In the spirit of the column Ask UXmatters, I spoke to a number of leading advocates for accessibility to find out what they think about usable accessibility.

“It’s really about the user experience. That means more than just removing barriers. We have to think about the personas for different types of disabilities and how to give them as good an experience as anyone else.”—Mike Paciello

I started with Mike Paciello of The Paciello Group. He was a co-chair for the Access Board’s committee making recommendations for how to update the US “Section 508” accessibility regulations. I had thought he might focus on standards that ensure sites meet basic requirements. However, what he said was that, although good standards are important, “It’s really about the user experience. That means more than just removing barriers. We have to think about the personas for different types of disabilities and how to give them as good an experience as anyone else.”

“Many times focusing on standards and guidelines puts the focus on the technical aspects of accessibility, and the human interaction aspect is lost. This problem can be avoided by adopting the broader definition of accessibility as a guiding principle. Instead of focusing only on the technical aspects of accessibility, it is important to recognize that usability is also an important aspect of accessibility. Consciously addressing ‘usable accessibility’ helps clarify the difference between what meets minimum accessibility standards and what is usable by people with disabilities.”

Mary Theofanos and Ginny Redish make a similar point in two articles about their work on the user experience of blind and low-vision users. They raised questions about how we can create “experience equity” for people with disabilities by making a site flexible. But, they went further, claiming, “Improving accessibility improves usability for all users.” Clayton Lewis made much the same point at a presentation to the Access Board advisory committee. He pointed out that many features that make Web sites accessible to people with cognitive disabilities also improve the general usability of sites, because such disabilities can amplify mild annoyances into absolute barriers.

“Many features that make Web sites accessible to people with cognitive disabilities also improve the general usability of sites, because such disabilities can amplify mild annoyances into absolute barriers.”

Kate Walser, a member of the Access Board committee, provided a good example of how accessibility and usability can work together. “To make complex applications and forms accessible, you need to think through ways to promote keyboard access, label all fields, and make it clear what the ordering and dependencies are. By doing so, now you’ve made it a little easier for power users who use the keyboard to get through the applications and clarified how someone should complete the form.”

If this connection between usability and accessibility is true, I wondered why accessibility sometimes has a bad reputation among designers. Mike’s answer to this question was, “Mindset. Accessibility isn’t the norm for software engineering, so it’s still seen as something extra or hard to do. Instead, we should think of it as a challenge to our own creativity.”

Both Shawn and Kate brought up another problem: If designers don’t understand how people with disabilities use the Web, they can implement accessibility features in ways that make a site less usable and less accessible. Here are some examples of such mistakes:

in the alt text for images, including information a screen reader already provides—For example, using the alt text “image of a down arrow that links within this Web page” on an anchor link is not only a long set of words to listen to, it duplicates the information the screen reader provides—that it’s an image and a link. The simple alt text “down arrow” would let the screen reader say “Image: down arrow. Internal link.” For people who scan with their ears, this is both more accurate and faster.

misusing the tabindex attribute—This makes a form even more difficult to navigate by confusing the order in which the Tab key moves between the controls in a form. This often occurs as the result of coding errors, in which some elements are included in the sequence, but others are left out. Another problem that negatively impacts those with visual impairments is a Tab order that makes it hard for someone listening to a Web page to know what section of the page a control or link is in. (For more details, see “Too Much Accessibility—TABINDEX.”)

overdoing the use of access keys and creating conflicts with keyboard shortcuts—The idea of adding access keys to a site seems helpful, but assistive technology often relies on keyboard shortcuts, which users know well. Conflicts between access keys and the keyboard shortcuts of either the browser or assistive technology create user confusion at the least and unexpected outcomes at the worst.

“Problems often come from trying to make a Web site accessible without understanding how people with disabilities actually use the Web.”

Such problems often come from trying to make a Web site accessible without understanding how people with disabilities actually use the Web. The challenge for UX designers is to find ways of including real people with disabilities throughout the design process, starting with initial user research and going all the way through final usability testing. This gets back to the issue of familiarity. The more we include people with a range of disabilities, the easier it will be to anticipate effective ways to design for them.

The WAI offers guidance for ways to involve users in Web accessibility evaluation, and Shawn’s book Just Ask: Integrating Accessibility Throughout Design provides detailed information about how to work with people with disabilities. Shawn points out, “People with disabilities generally find the same usability issues as people without disabilities.” Because accessibility needs can magnify usability problems, “when your usability testing participants are carefully chosen users with different types of disabilities—for example, people with low vision or people with cognitive disabilities—you will get better results than with participants without disabilities. By using a range of participants with disabilities, you can cover both accessibility and general usability more effectively.”

“With modern technologies, you can make almost all designs fully accessible.”—Shawn Henry

A question I often get asked is How much harder is it—how much more time will it take—to make a Web site accessible? Kate’s reply to this question is that it “only seems harder if you don’t typically think through how you’ll build the site first. For non-Flash sites, following generally accepted Web standards and best practices will get you a long way toward meeting the accessibility standards.” Shawn picked up that theme as well, “While many years ago accessibility limited design choices, because many Web technologies did not support accessibility, that hasn’t been the case for some time. With modern technologies, you can make almost all designs fully accessible, and you can make accessible alternatives for design aspects with inherent accessibility barriers.”

Part of the equation rests with the companies that make software tools. Kate and Mike both commented on the importance of having tools that assist with accessibility and having assistive technology that can keep up with new techniques. Kate gave one good reason to make core tools accessible. “It’s more expensive and more hassle to maintain two products—the Section-508-ready one and the non-accessible one. Besides design and development, you have expenses for training, product support, and marketing, which will cut into your profits.”

“One approach to making a site accessible is to provide user control and flexibility. This means you can start from a well-designed, usable default design, but let users adjust the interface to fit their needs.”

Finally, I wanted to know whether it really is possible to design a Web site that works for everyone. Doesn’t accessibility limit design choices? Everyone rushed to contradict that as a myth, making two important points.

First, one approach to making a site accessible is to provide user control and flexibility. This means you can start from a well-designed, usable default design, but let users adjust the interface to fit their needs.

“Design always includes trade-offs,” Shawn pointed out. “In Web design, you can optimize for the most common users and configurations and also provide flexibility for user control. Then the Web site will work with users’ accessibility
settings, adaptive strategies, and assistive technologies.” An accessible site doesn’t need be ugly or restricted to HTML basics.

Second, if you have planned your design well, much of what makes a Web site accessible happens under the covers, with good code, and does not affect the visual design at all. In fact, sometimes making a site accessible can give you benefits you might otherwise have missed, according to Kate—like better search engine optimization and the added flexibility you get when you take the time to start from accessible templates in application frameworks like .NET.

“Creating a good user experience for people with disabilities can give us better usability for everyone.”

Mike has a particularly proactive and positive attitude, “If someone comes to me and says something can’t be done, my answer is that we just haven’t figured it out yet. The time it takes before a new technology becomes accessible is getting shorter and shorter. It took a decade to make Windows accessible; the Web took five years. New applications are taking less and less time. Look at how fast the WAI-ARIA guidelines have progressed.”

When we add everything up, creating a good user experience for people with disabilities can give us better usability for everyone, a more flexible design, and kudos from people who have come to expect modern Web design and the accessibility benefits it brings. This makes it seem well worth the effort to include people with disabilities in your user experience process.

Event—If you are interested in learning more about usable accessibility and how to evaluate user experience for people with disabilities, Knowbility and UPA are running a two-day training program on Web Accessibility Evaluation at Access U, on May 11–12, in Austin, Texas.

5 Comments

Absolutely brilliant article. I am currently developing an incredibly rich Internet application, but am incorporating all of the ARIA suggested usage. So far, I have been successful in creating usable and accessible ToolTips, slideshows, and even modal windows. Of course, ARIA relies on a user’s having a supported browser and a particular version and type of screenreader, but ultimately we must start somewhere.

I agree that this was a helpful and informative article—primarily because it contained so many useful references. Other authors may consider redoubling their effort to include references and useful links in other articles.

Just came across your great article. Mike’s answer, “Mindset. Accessibility isn�t the norm for software engineering, so it�s still seen as something extra or hard to do. Instead, we should think of it as a challenge to our own creativity,” struck a chord with me. Better accessibility, better usability, and better security are simply software quality aspects, not something you should sprinkle on top later.