Accessibility in User-Centered Design: Design Phase
After the Analysis Phase is the Design Phase. The Background: Accessibility & UCD chapter lists Design Phase steps and shows how they fit into a User-Centered Design (UCD) process. This chapter discusses:
- Importance of Multiple Approaches in Design
- Understanding the Range of Functional Limitations
- Standards and Guidelines
- Techniques Guides
- Evaluate Example Products
- Evaluate throughout Design
This chapter describes approaches to covering accessibility in the Design Phase. It doesn't include design solutions or guidance on specific accessible design issues. When possible, employ an accessibility specialist with first-hand experience with how people with different disabilities interact with your product, and proven experience designing accessible products. It's also best if everyone on the project team has some basic understanding of accessibility issues.
Accessibility is most effectively and efficiently incorporated into product design when it is addressed with different approaches from the beginning of design. Common pitfalls to avoid in design are focusing only on limited standards and not considering accessibility until the end of the design process.
Product designers who are required to follow specific accessibility standards often jump right into the technical standards without understanding accessibility issues. Trying to follow accessibility standards without an understanding of accessibility is both frustrating and ineffective.
Here's an example: A web developer who doesn't know what
it's like to use a screen reader comes to the web accessibility guideline “Provide text
alternatives for all non-text content.” To meet this guideline, the developer
provides the alt text:
"This image is a line art
drawing of a dark green magnifying glass. If you click on it, it will take you
to the Search page for this Acme Company website." He writes
similarly verbose alt text for hundreds of different images on his website... He
has just wasted a whole lot of time and effort on an ineffective
solution. For the image that takes you to the search page, the alt text
“Search” is all that was needed.
His overly descriptive text throughout the site will be extremely frustrating for people who need alt text, because they will have to wade through all the extraneous information. If he had some basic understanding of accessibility issues and had watched someone use websites with a screen reader, he would not have made that mistake. See the Involving People with Disabilities in Your Project chapter for guidance on understanding accessibility issues and learning how people with disabilities use your product.
This chapter provides approaches and resources beyond basic standards. They apply in the Design Phase steps in the following areas:
- When developing the conceptual/mental model, metaphors, design concepts, and navigation design, ensure that the range of functional limitations is considered.
- Specific standards and guidelines apply to navigation design and detailed design.
- Techniques guides provide detailed instruction on specific accessible design aspects for detailed design.
- Evaluating example products is one way to get ideas for detailed design.
- Evaluating throughout design particularly applies to paper prototypes, low-fidelity mockups, and functional prototypes.
A first step in understanding accessibility issues is incorporating people with disabilities in the Analysis Phase, as described in the previous chapter, Analysis Phase. Because of limited resources, the Analysis Phase often focuses on limited accessibility issues; for example, only doing three personas, each with one disability. Ensuring that the designers understand the wide range of functional limitations at the beginning of the Design Phase helps avoid costly changes later.
Several resources provide information that can serve as guidance on understanding the range of functional limitations:
- Section 508 of the U.S. Rehabilitation Act, Subpart C -- Functional Performance Criteria §1194.31 is listed in the "Heuristic Evaluation" section of Evaluating for Accessibility, the next chapter
- Section 255 of the U.S. Telecommunications Act, Subpart C: Requirements for Accessibility and Usability is listed below:
§ 1193.41 Input, control, and mechanical functions.
Input, control, and mechanical functions shall be locatable, identifiable, and operable in accordance with each of the following, assessed independently:
(a) Operable without vision. Provide at least one mode that does not require user vision.
(b) Operable with low vision and limited or no hearing. Provide at least one mode that permits operation by users with visual acuity between 20/70 and 20/200, without relying on audio output.
(c) Operable with little or no color perception. Provide at least one mode that does not require user color perception.
(d) Operable without hearing. Provide at least one mode that does not require user auditory perception.
(e) Operable with limited manual dexterity. Provide at least one mode that does not require user fine motor control or simultaneous actions.
(f) Operable with limited reach and strength. Provide at least one mode that is operable with user limited reach and strength.
(g) Operable without time-dependent controls. Provide at least one mode that does not require a response time. Alternatively, a response time may be required if it can be by-passed or adjusted by the user over a wide range.
(h) Operable without speech. Provide at least one mode that does not require user speech.
(i) Operable with limited cognitive skills. Provide at least one mode that minimizes the cognitive, memory, language, and learning skills required of the user.
§ 1193.43 Output, display, and control functions.
All information necessary to operate and use the product, including but not limited to, text, static or dynamic images, icons, labels, sounds, or incidental operating cues, shall comply with each of the following, assessed independently:
(a) Availability of visual information. Provide visual information through at least one mode in auditory form.
(b) Availability of visual information for low vision users. Provide visual information through at least one mode to users with visual acuity between 20/70 and 20/200 without relying on audio.
(c) Access to moving text. Provide moving text in at least one static presentation mode at the option of the user.
(d) Availability of auditory information. Provide auditory information through at least one mode in visual form and, where appropriate, in tactile form.
(e) Availability of auditory information for people who are hard of hearing. Provide audio or acoustic information, including any auditory feedback tones that are important for the use of the product, through at least one mode in enhanced auditory fashion (i.e., increased amplification, increased signal-to-noise ratio, or combination). For transmitted voice signals, provide a gain adjustable up to a minimum of 20 dB. For incremental volume control, provide at least one intermediate step of 12 dB of gain.
(f) Prevention of visually-induced seizures. Visual displays and indicators shall minimize visual flicker that might induce seizures in people with photosensitive epilepsy.
(g) Availability of audio cutoff. Where a product delivers audio output through an external speaker, provide an industry standard connector for headphones or personal listening devices (for example, phone-like handset or earcup) which cuts off the speaker(s) when used.
(h) Non-interference with hearing technologies. Reduce interference to hearing technologies (including hearing aids, cochlear implants, and assistive listening devices) to the lowest possible level that allows a user to utilize the product.
(i) Hearing aid coupling. Where a product delivers output by an audio transducer which is normally held up to the ear, provide a means for effective wireless coupling to hearing aids. 
Using standards and guidelines helps ensure that you address all issues, and involving people with disabilities helps you address them efficiently and effectively.
Most of this book describes approaches for including people with disabilities throughout product design. While there are many benefits, that alone will not lead you to develop an accessible product, because even large projects cannot include the diversity of disabilities, adaptive strategies, and assistive technologies that would be necessary to sufficiently cover all the issues. For most products there are standards that do cover the diversity.
In some cases, meeting accessibility standards is a legal requirement; in others, it's just a smart thing to do.
There are accessibility standards and guidelines for different types of products from international standards bodies, governments, and organizations. Many of these are available on the Web.
There are different types of standards and guidelines, and the terms for each are used interchangeably in some cases. For example, the "guidelines" developed by W3C WAI (WCAG, ATAG, UAAG) are international Web standards. They are developed following a formal process to ensure broad community input from people with a wide range of perspectives, from industry, disability organizations, accessibility researchers, government, and others interested in accessibility.  The W3C WAI guidelines/standards cover the entire range of disabilities and situations.
There are other types of guidelines that have a much narrower scope and do not involve multi-stakeholder consensus and public review. For example, some people have published informal guidelines for websites based on limited usability testing with participants using websites with certain types of assistive technologies. Some of these guidelines provide useful suggestions; however, they are not sufficient to address the broad range of issues. Therefore, these limited guidelines should be used in conjunction with comprehensive formal standards.
It is generally best for governments and organizations to adopt existing international accessibility standards when they are available, rather than develop their own different standards. For example, several governments have adopted WCAG, as listed in the online resource International Policies Relating to Web Accessibility. Why Standards Harmonization is Essential to Web Accessibility focuses on web, yet it explains benefits to harmonized standards that apply to all types of products.
International accessibility standards include:
- For web pages and web applications: W3C WAI Web Content Accessibility Guidelines, see WCAG Overview, WCAG 1.0 (May 1999)
- For web authoring tools: W3C WAI Authoring Tool Accessibility Guidelines, see ATAG Overview, ATAG 1.0 (February 2000)
- For web browsers: W3C WAI User Agent Accessibility Guidelines, see UAAG Overview, UAAG 1.0 (December 2002)
- For software: ISO 16071 Ergonomics of human-system interaction: guidance on accessibility of human-computer interfaces.
In the U.S., accessibility regulations have the following accompanying standards and guidelines:
- Electronic and Information Technology Accessibility Standards for Section 508 of the Rehabilitation Act, which includes sections on:
- Software applications and operating systems
- Web-based intranet and Internet information and applications
- Telecommunications products
- Video or multimedia products
- Self contained, closed products such as information kiosks and transaction machines
- Desktop and portable computers
- Documentation and support
- Telecommunications Act Accessibility Guidelines (TAAG) address the accessibility, usability, and compatibility of telecommunications, broadcast, and cable products and services.
"Standards and Guidelines" in the Appendix: Resources lists other accessibility standards and guidelines.
An international company needed their e-learning products to meet Section 508 for U.S. government markets and WCAG 1.0 Priorities 1 and 2 Checkpoints for European markets. They also decided to meet some but not all of the WCAG 1.0 Priority 3 Checkpoints. They set timelines for when each product would be redesigned to incorporate accessibility.
While standards may be the guiding force in your accessibility efforts, be careful to keep them in perspective. The goal of accessibility is not to check off a standards list; the goal is to make your product accessible. An approach to using accessibility standards follows:
- Determine what standard(s) applies to your product
- Determine your goal for meeting all or some of the standards, and target dates
- Review the standards early in product design, along with the other approaches throughout this chapter
- Evaluate if prototype designs meet the standards as you go along, as described in the next chapter
Most accessibility standards and guidelines by nature need to be broad enough to cover a variety of technologies, situations, and future developments. Techniques guides provide more specific guidance on implementing standards and guidelines and most include examples and illustrations. Techniques guides follow less formal development and approval processes and therefore can provide more specific design advice and be updated more frequently.
Several standards and guidelines have associated techniques guides, including:
- For websites and web applications: Techniques for Web Content Accessibility Guidelines 1.0, WCAG 2.0 Quick Reference, Understanding WCAG 2.0, and Techniques for Web Content Accessibility Guidelines 2.0
- For web authoring tools: Techniques for Authoring Tool Accessibility Guidelines 1.0 and Implementation Techniques for Authoring Tool Accessibility Guidelines 2.0
- For web browsers: Techniques for User Agent Accessibility Guidelines 1.0
The Section 508 Tutorial Developing Accessible Software has some similar information as a technique guide. It uses the development of a software calculator to illustrate the application of the accessibility requirements of Section 508, Part 1194.21.
Some techniques guides are less directly associated with a standard, such as the Product Design Ideas Browser, a design resource for hardware, from the Trace R&D Center. The Ideas Browser is a reference tool that provides strategy and technique suggestions for designing hardware so that it is accessible to as many people as possible, including people with disabilities. While most of the design ideas apply generally to all hardware, the Ideas Browser is organized under Telecommunications Act Accessibility Guidelines (TAAG) headings. The Ideas Browser includes examples and photos.
In addition to the examples provided in techniques guides such as those listed above, another way for designers to get ideas for accessible design is to evaluate other product designs. Sources for design ideas from other products include:
- Similar mainstream products, particularly products that are reported to be accessible
- Different mainstream products, particularly products designed for constrained situations and environments; for example, a mobile phone designer could evaluate a handheld device designed to be used by repair crews outside wearing gloves
- Assistive technologies specifically designed for people with disabilities
For pointers on where to look for mainstream products that claim to be accessible and for assistive technologies, see "Accessible Products Lists" in the Appendix: Resources.
One way to find websites that claim to be accessible is to use the reverse linking feature of a search engine. In some search engines, searching for "link:www.w3.org/WAI/WCAG1AA-Conformance" returns a list of sites that claim to meet WCAG 1.0 Priority 1 and 2 Checkpoints.
Keep in mind that not all products that claim to be accessible are indeed accessible. Also, it is common for products to be accessible in some ways and not accessible in other ways. It's important to evaluate specific design features that claim to be accessible before using similar designs. The next chapter, Evaluating for Accessibility, covers techniques you can use to evaluate designs.
As mentioned above, if designers focus only on meeting the minimum requirements of a limited standard, the resulting product can have accessibility problems that impede usability for people with disabilities. Understanding how people interact with the product in limiting conditions is a start to avoiding unusable accessibility features; evaluation provides confirmation.
I've seen many cases where developers try to apply good practice in their projects, but they don't check to see if it worked or not. For example, I've seen many websites that include "skip links" for accessibility, but they don't work due to browser bugs, misunderstandings of CSS (Cascading Style Sheets for web design), and such. Simple evaluation would have shown the problem within minutes.
Evaluate early and throughout the Design Phase. Evaluating early design prototypes helps you validate design aspects that work well, and find potential accessibility barriers while it is still relatively easy and inexpensive to fix them. Several of the evaluation methods covered in the next chapter, Evaluating for Accessibility, can be conducted early in the design process.
- Telecommunications Act Accessibility Guidelines, Subpart C: Requirements for Accessibility and Usability, 1998.
- Henry, S.L., ed. How WAI Develops Accessibility Guidelines through the W3C Process: Milestones and Opportunities to Contribute, W3C (MIT, ERCIM, Keio), 2006.
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.
- Henry, S.L., Martinson, M.L., and Barnicle, K. Beyond Video: Accessibility Profiles, Personas, and Scenarios Up Close and Personal. Proceedings of UPA 2003 (Usability Professionals' Association annual conference), 2003.
- Henry, S.L., Law, C., and Barnicle, K. Adapting the Design Process to Address More Customers in More Situations. Proceedings of UPA 2001 (Usability Professionals' Association annual conference), 2001.