WebAIM - Web Accessibility In Mind

Constructing a POUR Website
Putting People at the Center of the Process

Motivations to Create Accessible Web Content

There are at least three main kinds of reasons that might motivate people to create accessible web content:

  1. To improve the lives of people with disabilities (human-centered motivations)
  2. To capitalize on the a wider audience or consumer base (marketing or economic-centered motivations)
  3. To avoid lawsuits and/or bad press (public relations and punishment-centered motivations)

All of these can be good reasons. Accessible web sites will accomplish all of these goals. The motivations are listed in order of most altruistic to least altruistic, but as long as the web site is accessible in the end, perhaps it does not matter what the developers' motivations were to begin with.

No matter which motivation works for a particular developer, one principle will always hold true: web accessibility is most easily achieved when people are at the center of the process. Even those who are simply trying to avoid lawsuits will sooner or later realize that the needs of the target audience—people with disabilities—must be carefully considered and addressed.

  • Understanding the user's perspective and needs
  • Moving beyond technical accessibility
  • Focusing on the principles of accessibility

Understanding the User's Perspective and Needs

The techniques and guidelines of web accessibility were not invented to make life hard for web developers. They were invented to make life easier for people with disabilities. Like everyone else, people with disabilities want and need to access the kinds of resources offered on the web. Many services and goods once available only by visiting brick-and-mortar offices and shops are now available online, from the comfort of one's home. Nothing could be more perfect in terms of making the world more accessible to people with disabilities.

The web is not a barrier to people with disabilities, it is the solution. The web has the potential to revolutionize the day-to-day lives of millions of people with disabilities by increasing their ability to independently access information, communication, entertainment, commerce, and other aspects of life that most people take for granted. However, for the web to reach its full potential for people with disabilities, web developers must commit to always designing with accessibility in mind. Failure to do so risks turning a revolutionary solution into yet another barrier in the lives of people with disabilities.

This is why web accessibility was invented. This is the perspective to keep in mind when developing web sites. After all, people with disabilities are people. They just want to make the most of life. An accessible Internet is not a magic bullet or panacea to every obstacle faced by people with disabilities, but it is at least a step in the right direction.

Moving Beyond Technical Accessibility

Techniques and guidelines are 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 guidelines 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.

(See effective alternative text for more information.)

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.

Focusing on the Principles of Accessibility

Version 1.0 of the Web Content Accessibility Guidelines focused heavily on the techniques for accomplishing accessibility, especially as related to HTML. WCAG 2.0 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. Each of these principles is discussed more in depth in the sections that follow. For now it is sufficient to say that putting the POUR principles helps put people at the center of the process, which, in the end, is the whole reason for even discussing the issues.