eBethInk

Accessibility Heuristics

Introduction

Note: this post was created from research and work done while I was a:

• User Experience Specialist at DeVry University


• Student at DePaul University


• User Interface Designer at SPSS Inc., an IBM company

“The situation today with the existing guidelines for making new technology and information accessible (for example World Wide Web Consortium) reminds much about the state of HCI or Usability Engineering in the late 1980s”. (Fredrik Winberg)

Current accessibility guidelines are difficult for user experience designers and engineers to use. They need a simple, plain English, set of guidelines they can use during the development process to insure the applications they are developing are accessible.

I first became exposed to accessibility while at SPSS Inc. My team lead there was the accessibility expert. When he left the company I started getting calls from developers and other designers with questions about accessibility. I needed to learn fast; there was a product that was about 60% complete and they needed an accessibility expert to look at it. I learned, and a few months later we had a fully accessible, drag and drop, data mining product. And it was written in JAVA. (The engineers on the product were amazing. They learned JAWS, explored the accessibility features in JAVA, and then programmed the application.)

As a graduate student at DePaul University, I expanded on the knowledge I gained at SPSS. Accessibility was my topic of choice in independent study courses. In my capstone course I wrote a set if accessibility heuristics that I will publish and expand on here in this post and in future posts.

The Heuristics

Honor display settings – A user sets the display properties for a reason. Make sure your application knows what they are and displays all its interface elements with those properties.


Provide a tab order -- Provide a well thought out tab order and include every actionable interface element. Do not include un-actionable items, for example disabled controls. For users who use the mouse, the tab order is not as important as to the user who navigates via the keyboard. When there is a potential conflict, choose the tab order that makes the most sense to the keyboard user.


Indicate focus and selection -- Every interface element must indicate that it has focus, and, if applicable, which items are selected within that element. This information needs to be indicated onscreen and passed textually to the Operating System. Additionally, only the user has the right to change the current focus.


Provide textual information -- Provide text information for every interface element, even if that information doesn’t appear in the display. A Screen Reader cannot describe an interface element that it knows nothing about.


Follow the standard -- Use standard interface elements as they are meant to be used. There is no such thing as a single button radio group. Pattern custom control behavior on standard control behavior and identify them as such.


Use the keyboard – Every interface element must be actionable via the keyboard. Take advantage of standard keyboard shortcuts to provide functionality. Provide application specific keyboard shortcuts but never overwrite standard shortcuts.


Color is for enhancement only -- Don’t use color as a sole indicator of functionality, state or mode.


Identify images -- When using images and animation, be consistent, provide textual information, and avoid flashing.


Test, then test again -- Test to assure the application works with the assistive technology included in the Operating System as well as a third-party Screen Reader.

References

Below is a collection of references I've used in past projects.

Barnicle, Kitch. Usability Testing with Screen Reading Technology in a Windows Environment. Arlington, Virginia, USA. (CUU’00).

Henry, Shawn Lawton. (2007) Just Ask: Integrating Accessibility Throughout Design (lulu.com)

Kinash, Shelly. (2006) Seeing Beyond Blindness (IAP-Information Age Publishing)

Mueller, John Paul. (2003) Accessibility for Everybody: Understanding the Section 508 Accessibility Requirements. (apress).

Nielsen, J. Ten Usability Heuristics. http://www.useit.com/papers/heuristics/heuristic list.html.

Nielsen, Jakob. (1994) Heuristic Evaluation. In J. Nielsen & R.L. Mack (Eds.), Usability Inspection Methods (pp 25-62), New York: John Wiley & Sons Inc.

Paddison, Claire & Englefield, Paul. (2003). Applying Heuristics to Perform a Rigorous Accessibility Inspection in a Commercial Context. Vancouver, British Columbia, Canada. (CUU’03)

Seale, Jane K. (2006) E-Learning and Disability in Higher Education (Routledge)

Section 508. http://www.section508.gov.

Sloan, David & Gregor, Peter & Rowan, Murray & Booth, Paul. (2002). Accessible Accessibility. Arlington, Virginia, USA. (CUU’03).

Theofanos, Mary Frances & Redish, Janice. (2003). Guidelines for Accessible – and Usable – Web Sites: Observing Users Who Work with Screen readers. Interactions. 10, (6), 31-51.

Web Content Accessibility Guidelines http://www.w3c.org/WAI/

Winberg, Fredrik. (1999). Discount Accessibility Engineering: Haven’t we Met Before. INTERACT 99 Workshop: Making Designers Aware of Existing Guidelines for Accessibility.