USER-CENTERED, PRINCIPLE-DRIVEN
WEB DESIGN - MOVING BEYOND ACCESSIBILITY CHECKLISTS AND VALIDATORS
Presenter(s)
Jared Smith
WebAIM - Web Accessibility in Mind
6807 Old Main Hill
Logan Utah 84322-6807
Day Phone: 435-797-7024
Email: jared@cpd2.usu.edu
Presenter #2
Jonathan Whiting
WebAIM - Web Accessibility in Mind
6807 Old Main Hill
Logan Utah 84322-6807
Day Phone: 435-797-8284
Email: jonathan@cpd2.usu.edu
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:
* Perceivable
* Operable
* Understandable
* Robust
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.
Perceivable
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.
Operable
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!
e.
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.
Understandable
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.
Robust
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.
RESOURCES
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/
Go to previous article
Go to next article
Return to 2006 Table of Contents