POUR

The guidelines and success criteria of building WCAG 2.0 accessible web applications are organized around the POUR principle. POUR stands for Perceivable, Operable, Understandable, and Robust. Following these guidelines allows us to build websites and applications that are usable by all. Let’s take a closer look at each of these guidelines:

Perceivable

Information and user interface components must be presentable to users in ways they can perceive.

Perceivable means that a user should be provided the opportunity to perceive the content of our web applications. To do this, we must ensure that the information being presented is perceptible to their senses. When we limit content to a single sense, we run the risk of alienating users.

One common use case of perception is providing written transcripts of audio material or captioning video material. Perhaps a less obvious example is the style of links across the Web. A link that is only a different color from the text would be imperceptible to color-blind users.¹ Instead, we should be sure to alter the color as well as provide an underline to the link, as illustrated in Figure 3-1. This provides a perceptible option to color-blind users.

Figure 3-1. Retaining the default link behavior of including an underline allows links to be perceptible to color-blind users

Operable

User interface components and navigation must be operable.

When a web application is operable, all users are able to operate and navigate its interface. Perhaps a simple example of this is providing users the ability to easily “tab through” our sites, by navigating through the page using only the Tab keyboard key. A user who is unable to operate a mouse or trackpad may navigate sites using only the keyboard. Ensuring that our sites are keyboard-accessible is one way to ensure that they are operable by all users.

Understandable

Information and the operation of user interface must be understandable.

When we build understandable interfaces, we follow common development patterns of hierarchy and user interaction. When working with a team, these may often fall in the domain of a designer, but as developers we make choices about how we develop these patterns.

One common anti-pattern is using form-label placeholder text in the place of a form label (see Figure 3-2.

Here is a form element, properly marked up with a label and placeholder text:

<label for="password">Password:</label>
<input type="text" name="password">

Here is one that uses the placeholder to replace the label:

<input type="text" name="password" placeholder="Password">

Figure 3-2. Avoid using form placeholders in place of labels

The use of placeholder text in the place of labels raises several potential usability and accessibility concerns due to low contrast, extra cognitive burden as users must recall the purpose of the field, and unreliable screen reader support. By making solid development decisions such as proper form markup, we can develop more understandable sites.

Robust

Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

By building robust web applications, we build future-friendly sites that are device and browser agnostic. When we develop without a specific platform in mind and do not limit our browser support, we are able to build sites that are accessible to any user. This is a topic that we will cover in depth in a future title, Building Web Applications that Work Everywhere.

WCAG Conformance

WCAG 2.0 is separated into three levels of conformance, based on success criteria that is defined in the WCAG 2.0 specification:

Level A

Level A provides basic web accessibility support. This meets all Level A success criteria, or provides an alternate content version that does.

Level AA

Level AA addresses the most common accessibility issues. This meets all Level A and Level AA success criteria or provides an alternate content version that does.

Level AAA

Level AAA provides the highest level of web accessibility support for users. This meets all Level A, Level AA, and Level AAA success criteria, or provides an alternate version.

It is worth noting that the W3C does not recommend that Level AAA conformance be required for entire sites, as it is not possible to satisfy all Level AAA success criteria for some content. If you choose to put an accessibility policy in place for your organization, I recommend aiming for Level AA support.

WCAG 2.0 Guidelines

The WCAG 2.0 guidelines are classified according to the POUR principle. Guideline 1 encompasses areas of perception, Guideline 2 covers areas of operation, Guideline 3 is directed at ensuring understanding, and Guideline 4 is targeted at the robustness of the application. The following are the specific guidelines from WCAG 2.0:

• Guideline 1.1 Text Alternatives: Provide text alternatives for any non-text content
• Guideline 1.2 Time-based Media: Provide alternatives for time-based media
• Guideline 1.3 Adaptable: Create content that can be presented in different ways (for example, simpler layout) without losing information or structure
• Guideline 1.4 Distinguishable: Make it easier for users to see and hear content including separating foreground from background.
• Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard.
• Guideline 2.2 Enough Time: Provide users enough time to read and use content.
• Guideline 2.3 Seizures: Do not design content in a way that is known to cause seizures.
• Guideline 2.4 Navigable: Provide ways to help users navigate, find content, and determine where they are.
• Guideline 3.1 Readable: Make text content readable and understandable.
• Guideline 3.2 Predictable: Make Web pages appear and operate in predictable ways.
• Guideline 3.3 Input Assistance: Help users avoid and correct mistakes.
• Guideline 4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies.

WebAIM provides a helpful checklist of recommendations for implementing HTML-related principles and techniques for WCAG 2.0 conformance, along with the associated support level.

Further Reading

• W3C’s “Techniques for WCAG 2.0”
• W3C’s “WCAG 2.0”
• W3C’s “Understanding WCAG 2.0”

Keep or Add :focus Style

When a user navigates to an element with the Tab key, it is visually indicated using a :focus style. By default, in most browsers this is either a thin dotted line or a blue highlighted border around the focused element. Unfortunately, it has become a fairly common trend to remove this focus style by applying an outline:0 or outline:none in CSS. This can be avoided by either retaining that default behavior or adding a custom focus style with CSS:

a:focus { 
  background-color: #01FF70;
}

Further reading

• The A11Y Project’s “Quick Tip: Never Remove CSS Outlines”

Navigation Order and Length

When a user navigates through a site using the keyboard, the order and length of keyboard-navigable items become critically important. Imagine the frustration of a user pressing Tab through every link presented in a sidebar (such as Twitter or Facebook’s “trends”) before being able to access the main content of the application. By using a “skip to content” (or “skip navigation”) link in our applications we can provide an extra guidepost that directs our users to the most valuable content.

Skip navigation links, or skip links, are hidden links which, when “tabbed” to or read by a screen reader, allow the user to skip to the main content of the page, rather than needing to navigate through navigation and other content that occurs earlier in the document order. These can be visually hidden, appearing only when a user presses the Tab key.

To begin, add a skip navigation link at the top of the document, linking directly to the main content of the page:

<body>
  <a href="#main" class="skip-link">Skip to main content</a>
  …
  <main id="main" role="main">
    <h1>Page Content</h1>
    …
  </main>
</body>

For styles, we can first hide the skip link visually while keeping it visible to screen readers:

.skip-link {
  position: absolute;
  width: 1px;
  height: 1px;
  margin: 0;
  overflow: hidden;
  clip: rect(1px, 1px, 1px, 1px);
}

Then make it appear visually when the link receives focus with the Tab key:

.skip-link:focus {
  top: 0;
  z-index: 1;
  width: auto;
  height: auto;
  clip: auto;
}

Further reading

• The A11Y Project’s “How–to: Use Skip Navigation Links”
• WebAIM’s “‘Skip Navigation’ Links”
• NCZOnline’s “Fixing ‘Skip to content’ Links”

Default Navigation Elements

By default, links, buttons, and form items are navigable using the Tab key. However, there are times that we may want to include additional items that are tabbable by our users. To do this, we can set a “tab index” value on an HTML element:

<h3 tabindex="0">This heading is tabbable</h3>

The approach should generally be to set a tabindex value of zero. A number greater than 1 sets an explicit tab order, and should be avoided.

Further reading

• WebAIM’s “Tabindex”
• WebAIM’s “Keyboard Accessibility”
• Nielsen Norman Group’s “Keyboard-Only Navigation for Improved Accessibility”

Other Screen Readers

Though ChromeVox is great you may want to explore the use of more commonly used screen readers. Here are the most popular screen readers, according to the WebAIM screen reader survey:

• JAWS
• ZoomText
• Window-Eyes
• NVDA

Additionally, most operating systems ship with built-in screen reader support. This can be particularly useful for testing web applications on mobile devices.

• VoiceOver for Mac: CMD + F5 to enable
• Narrator for Windows
• VoiceOver for iOS
• Google Talkback

ARIA

In addition to writing clear and semantic markup, we can make use of ARIA to provide additional guideposts to screen reader users. Accessible Rich Internet Applications (ARIA) is a specification designed to make modern web application experiences more accessible. ARIA provides additional attributes that can be added to our markup to provide screen reader users with additional information to describe the role, state, and properties of elements on our page.

Perhaps one of the most immediately useful aspects of ARIA is the use of ARIA roles. ARIA roles allow us to provide specific information to screen readers about the context of HTML elements. Doing this allows screen reader users to quickly navigate to these subsections of our pages. I’ve found that watching videos of screen readers using ARIA roles can be a really helpful exercise in understanding the usefulness of ARIA.

To use an ARIA role, we add a role attribute to an HTML element and provide it with an ARIA value:

<div class="main-content" role="main">

There are two categories of ARIA roles that may commonly be used by web application developers:

Landmark

Landmark roles define content areas that a screen reader user may want to quickly navigate to, such as navigation menus and the main content of the page.

Widget

Widget roles are used for common interactive UI patterns such as tooltips, tabs, and progress bars.

The W3C provides a list of all of the possible ARIA role definitions. Here are some common ARIA role values that are useful to web application developers:

application

Content that is declared as a web application rather than a web document

banner

Typically the header of the page with the site name

search

Indicates a search input

main

The main content of the page

navigation

Defines any navigation area of the page

contentinfo

An area that contains information about the page such as author or organization title and copyright information; this is often the footer

group

A collection of UI elements that are not intended to be included in a page summary or table of contents by assistive technologies

menu

A list of user choices

toolbar

A collection of commonly used functions “represented in a compact visual form”

ARIA is more than just roles, however. ARIA can be used to define values on progress bars, hidden states, dynamic content updates, and more that are outside of the scope of this introduction. I’ve provided additional links and tutorials in the “Further Reading” section that detail the usefulness of these additional values.

Browser Extensions and Bookmarklets

Browser extensions and bookmarklets allow us to test the accessibility of a page as we are interacting with it. These are a great option for quickly doing spot checks for things like ARIA role usage, color contrast ratios, descriptive alt text, and form-label usage.

The following are some useful browser extensions and bookmarklets:

• tota11y
• WAVE Chrome Extension
• Chrome Accessibility Developer Tools
• aXe

Command-Line Tools

In addition to browser extensions or bookmarklets, we can automate common accessibility checks from the command line. This allows us, as developers, to integrate accessibility checks into our workflow. Typically these tools run our sites in a headless browser—one that doesn’t have a graphical user interface—and test for accessibility concerns such as color contrast, heading order, link content, and alt text.

The following are some useful command-line accessibility tools:

• pa11y
• a11y
• node-wcag

Automating Accessibility Tests

We can also integrate those command-line tools into an automated build process. Here are a couple of simple examples of how we might do that.

As an npm script in package.json, we could automate the running of accessibility steps with a11y against our localhost server:

"scripts": {
  "accessibility": "a11y localhost:3000",
}

We could also run those tests as a Gulp task. This is a simple task that will log the accessibility audit checks and failures to the console:

var exec = require('child_process').exec;

gulp.task('accessibility', function (){
  exec('a11y localhost:3000', function(err, stdout, stderr) {
    console.log(stdout);
    console.log(stderr);
  });
});

When paired with a continuous integration system, such as Travis CI, we could run these accessibility checks against every build, failing if there are accessibility errors. This would ensure that our codebase remains accessibility-compliant when new code is added.

Accessibility Checklists

While we may aim to build our applications with accessibility in mind throughout the development process, it is possible to overlook an accessibility issue. I’ve found it useful in to reference an accessibility checklist prior to launch of a new project. This allows me (and the team I’m working with) to add a final check for accessibility into the workflow of the project. The A11Y Project’s Web Accessibility Checklist provides a concise checklist of accessibility best practices; for a more thorough check of WCAG compliance, there is WebAIM’s WCAG 2.0 Checklist. Both of these lists allow you to quickly check for possible accessibility oversights.

Additional Resources

• W3C’s “Web Accessibility Initiative”
• W3C’s “Web Accessibility Guidelines”
• W3C’s “Web Accessibility Tutorials”
• The A11Y Project
• WebAIM
• Matt Long’s “It’s Tired In Here: Web Accessibility”