WEB DESIGN - MOVING BEYOND ACCESSIBILITY CHECKLISTS AND VALIDATORS
WebAIM - Web Accessibility in Mind
6807 Old Main Hill
Logan Utah 84322-6807
Day Phone: 435-797-7024
WebAIM - Web Accessibility in Mind
6807 Old Main Hill
Logan Utah 84322-6807
Day Phone: 435-797-8284
This session presents the next generation of web accessibility work in which principles and individuals, rather than techniques, take the center stage.
The next generation of web accessibility work is one in which principles and individuals, rather than techniques, take the center stage. It takes some effort to switch from a techniques-centered to a principle-centered mindset, but the end result is a site that is more usable by people with disabilities and not just "standards-compliant." User-centered web sites focus on the end user's abilities and go well beyond accessibility guidelines.
Techniques and guidelines are still important because they represent an attempt to define and standardize what Web accessibility means. They represent a consensus, or at least a majority opinion, about the best practices and methods for achieving Web accessibility. The Web Content Accessibility Guidelines (WCAG) are the most widely-accepted set of recommendations, and were developed over several years of collaborative involvement by a panel of experts and interested individuals. The rigorous process is purposefully slow and methodical, in an attempt to consider a wide variety of viewpoints and issues. Still, none of the participants in this process would ever claim that the guidelines are the last word on accessibility, or that conformance to the guidelines will guarantee Web content accessibility. The guidelines are an excellent foundation upon which to build accessible Web content, but unless the developers understand the reasons behind the guidelines, they might apply the g!
uidelines incorrectly or ineffectively.
For example, one of the best-known guidelines is to provide alternative text for images in the alt attribute of the <img> tag. If Web developers learn only the guideline, but not the reason for the guideline, they may provide alternative text that is not helpful to users who need it. They may even create, rather than solve, accessibility barriers.
When developers focus on technical specifications, they may achieve technical accessibility, but they may not achieve usable accessibility. To make a comparison, a large office building may be technically accessible to a person who is blind - meaning that this person may be able to walk through all the hallways, use the elevators, open the doors, etc. - but without an explanation (or perhaps a tactile map) of how the building is arranged, where the elevators and doors are, and which offices are on which floors, the building will be quite difficult to navigate, especially at first. The person may try to find locations through a process of trial and error, but this is a very slow and cumbersome process. The building is accessible, but not very usable.
In a similar way, Web developers can create Web sites that are possible for people with disabilities to access, but only with great difficulty. The technical standards are important, but they may be insufficient on their own. Developers need to learn when and how to go beyond the technical standards when necessary.
Version 1.0 of the Web Content Accessibility Guidelines focused heavily on the techniques for accomplishing accessibility, especially as related to HTML. Version 2.0 (not yet an official recommendation of the W3C at the time of this writing) takes a different approach - it focuses more heavily on the principles of accessibility, and presents some techniques in separate documents. By focusing more on principles rather than techniques, version 2.0 of the guidelines is more flexible, and encourages developers to think through the process conceptually. The four main guiding principles of accessibility in WCAG 2.0 are:
Conveniently, these principles spell out an acronym that is relatively easy to remember: POUR. The idea is to create a POUR Web site, so to speak. The pun may be a bad one, but if it helps developers memorize the principles, then it has served its purpose.
Any discussion of Web accessibility is based upon the assumption that people need to be able to perceive Web content. They need to be able to input the information into their brain so that they can process it. If the information cannot get into the brain, it is inaccessible. As obvious as that statement may sound, it is a principle which is frequently ignored by developers. Too many sites contain Web content that cannot even be perceived by some of the people who would like to access it.
Not everyone uses a standard keyboard and mouse to access the Web. Some people use adaptive devices or alternative devices that accommodate their disabilities. Some people simply prefer to use the alternative technologies. Mouse-dependent Web content will be inaccessible to a person who cannot use a standard mouse - due to tremors, insufficient fine motor control, or even a lack of hands altogether. A person in this situation is likely to use an adaptive technology of some sort, such as a mouth stick, to manipulate the keyboard. In some cases, the person may be able to use a trackball mouse (e.g. with a mouth stick), but others need to rely on the functionality of the keyboard. People who do not have use of their vision usually rely on the functionality of the keyboard as well. They may be able to manipulate a mouse just fine, but it doesn't do them much good because they can't see where to click on the screen. The keyboard is much easier for a person who is blind to manipulate!
Keyboard accessibility is one of the most important principles of Web accessibility because it cuts across disability types and technologies. Most of the alternative and adaptive devices used by people with disabilities emulate the keyboard in terms of functionality. Content that is accessible to the keyboard is operable by the devices that emulate keyboard functionality, no matter how radically different those devices are in appearance from standard keyboards.
Let's say that Web content is perceivable and operable by all kinds of users of all abilities, but it is understandable to none of them. Is the Web content accessible? Of course not. Understandability can be just as big a barrier to accessibility as any of the more technical issues. Talking about understandability moves the discussion into the broader realm of usability. Unfortunately, too many people still separate usability and accessibility into two separate disciplines. Trying to separate principles into mutually exclusive categories of "usability" versus "accessibility" would be pointless. There is too much of an overlap between the two. After all, could an unusable site ever be considered an accessible site? Not if accessibility means anything.
Not everyone uses the same technologies now, nor will they in the future. People use different operating systems, different browsers, and different versions of browsers. Some people have advanced features enabled. Others have these features turned off. Some people are early adopters of new technologies. Others are slow to adapt to rapidly-changing technological advances.
Users should be allowed to choose their own technologies to access Web content. This allows the users to customize their technologies to meet their needs, including accessibility needs. Web content that requires a certain technology, such as a certain browser, may exclude some types of users who either don't want to use that technology or can't use it because of their disability. As a general rule, the more control the user has, the more likely the user will be able to access the content effectively.
WebAIM - http://www.webaim.org/
Content Accessibility Guidelines (WCAG) 1.0 - http://www.w3.org/TR/WCAG10/
Web Content Accessibility Guidelines (WCAG) 2.0 Working Draft - http://www.w3.org/TR/WCAG20/
Section 508 - http://section508.gov/