Web Accessibility Principles

Question 1

The Web Content Accessibility Guidelines

Answer 1

The Web Content Accessibility Guidelines (frequently referred to as WCAG, pronounced “WICK-ag”) are an internationally accepted set of technical standards that explain how to make web content more accessible to people with disabilities.

The standards are created by the World Wide Web Consortium (W3C) through its Web Accessibility Initiative. They are intended for web and application developers and designers, content creators, policymakers, purchasing agents, teachers, and students.

The most current version is WCAG 2.2.

WCAG 2.0 remains approved as ISO standard ISO/IEC 40500.

The WCAG standards are organized into principles, guidelines, and testable success criteria.

Question 2

Web Accessibility Principles

Answer 2

The Web Accessibility Initiative at the World Wide Web Consortium outlined four main web accessibility principles in the Web Content Accessibility Guidelines, version 2.1. In order to be accessible, web content must be Perceivable, Operable, Understandable, and Robust.

The first letters of these principles form an acronym—POUR—which may help you remember them.

Question 3

WCAG Principles

Answer 3

Web pages and applications must be:

• Perceivable
• Operable
• Understandable
• Robust

You can remember the principles by the acronym: POUR.

Question 4

3 Levels of the WCAG

Answer 4

The success criteria are categorized into three levels:

• A: Minimal accessibility.
• AA (“double A”): Accessibility for most people. Most commonly used.
• AAA (“triple A”): Highest level of accessibility.

Question 5

Perceivable

Answer 5

Perceivability is about making the output of web content available through multiple sensory modalities.

Question 6

Biological Pathways to Perception

Perceivable

Answer 6

You have to be able to perceive web content through at least one of your biological senses for it to be accessible at all. Of these, we’re really only concerned about the first three: sight, sound, and touch. Someday someone may invent a way to taste or smell the web, but until then, we can safely assume that we don’t need to worry about the flavor or scent of our web pages.

Question 7

(Perceivable)
Seeing Web Content

Answer 7

Most people perceive web pages by looking at them. Your eyes focus the information onto photo-receptors in your retina, and your brain translates that raw visual stimulus into meaningful information. This works well for everyone who has good vision, but not so well for those who do not. The majority of web developers and web designers are relatively young and able-bodied, so they design web content that works for people just like themselves. Often developers and designers don’t even realize that some people can’t see the content at all, so they don’t build in other ways to perceive the content into the designs.

Question 8

(Perceivable)
Hearing Web Content

Answer 8

People who cannot effectively perceive visual information—because they are partially or completely blind—need to perceive web sites some other way. Most blind people can hear, so sound is the most effective alternative method of perceiving web content for the majority of people who are blind. Screen reader software converts the digital text into synthesized speech, allowing blind people to listen to web content. Listening to web content is a fundamentally different experience from looking at web content, just as hearing someone describe an event is fundamentally different from watching it, but different does not necessarily mean bad, unless the experience is not parallel, or functionally equivalent. People who are blind are used to listening rather than seeing, so listening to web content is a logical and natural approach for them.

Question 9

(Perceivable)
Feeling Web Content

Answer 9

For those who cannot see or hear adequately to view or listen to web pages, there is one more sensory modality available: touch. Digital text can be converted to three-dimensional braille characters that a person can feel with the hands. Traditional braille is printed on sturdy paper, with raised dots configured in an alphabet of characters and symbols. Modern refreshable braille devices use the same raised dots, but bypass the hassle and expense of the paper printing process. Refreshable braille devices present a line of text at a time, and allow the user to feel it, then move on to the next line of text. The screen reader software to convert the digital text to braille is essentially the same as the screen reader software that converts digital text to speech, and allows for nearly identical functionality. It’s just that the output is perceived through touch rather than through sound. For people who are both deaf and blind, tactile/touchable output is the only way for them to access web content at all.

Question 10

Why Perceivability Matters

Answer 10

If you can’t perceive web content, it may as well not exist.

The good news is that you don’t have to cure blindness or deafness to make images or sounds accessible to people with sensory disabilities. You just have to provide an acceptable alternative that works for their available sensory modalities. To make an image accessible, provide a digital text description. Screen readers can convert this text description into speech or braille to make it available by sound or touch. To make an audio recording accessible, provide a digital text transcript that deaf people can see with their eyes, and that people who are both deaf and blind can feel with their fingers when it is converted into braille. Web accessibility can get more complicated than these simple examples, but the principles are still the same. Everything has to be perceivable to be at all useful.

Question 11

(Perceivable)
The Universal Format: Digital Text

Answer 11

You may have noticed that digital text solves the perceivability problem for people who are blind, for people who are deaf, and for people who are both blind and deaf. Digital text is the most universally accessible format available, because it can be converted into all of the other useful sensory formats. That’s something to make note of, and to keep in mind as you learn more about web accessibility.

Question 12

Making Dynamic Content Perceivable

Answer 12

You can also make dynamic interactions accessible using digital text. You can use ARIA (“Accessible Rich Internet Applications”) to announce when a tab is “expanded” or “collapsed”. You can use an ARIA live region to announce new content as it is inserted into the DOM (Document Object Model). There are lots of possibilities. And yes, you do need to announce these kinds of things. Blind users won’t know when tabs expand or collapse unless this change of state is announced to them. If new content is injected into a page—such as an error message or a confirmation message—blind users need to hear this new information. ARIA live regions can be used for this purpose, or you can move the browser’s focus to those areas to force screen readers to read them. Either approach can be appropriate, depending on the circumstances and overall functionality of the interface.

Question 13

Make Sure Users Know What’s on the Web Page

Perceivable

Answer 13

One way to summarize the need for perceivability is to say that users can’t access content unless they know it’s there. Make sure your users know what’s on the web page. This means making the content and functionality available through sight, sound, and touch. Digital text—whether visible or hidden (using valid accessibility techniques)—is the most universal method of accomplishing the broadest perceivability.

Question 14

Operable

Answer 14

Operability is about making the input methods of web content functionally available to a wide range of input devices, including:

• mouse or touchpad
• keyboard
• touchscreen
• voice recognition software
• other specialized input devices (most of which emulate the keyboard or mouse)

Question 15

(Operable)
Everything Has to Work

Answer 15

The goal of operability is to ensure that web components work. All features—particularly navigation and dynamic or interactive components—must be functional, no matter what input device a person is using. If any part of the web content is not available with a given input device, the content is essentially broken for that user, even if the features are available through other input devices.

Question 16

(Operable)
In, Within, Through, and Out

Answer 16

You have to be able to navigate into web components, use the features within them, navigate through them, and navigate out of all of them, no matter what input device you’re using. If any of these aspects of operability does not work with an input device, some users will be unable to use the web component.

Question 17

Scripting for Device Independence

Operable

Answer 17

Plain web content without any scripting or dynamic features is mostly device-independent by default. You don’t have to do anything special to make standards links or form elements work with multiple devices. If you leave them alone, they’ll work just fine. It gets trickier, though, when you start creating dynamic interactions with scripts. Scripts are powerful, and they can override the default behaviors of pretty much any native component. You can even create your own components from scratch. That gives you a lot of power and flexibility. It also creates a lot of liability, because you can break the functionality of native components or create device-specific custom components that are unusable with the input methods that you didn’t take into account. To the extent possible, you should use device-independent event handlers (such as onfocus, onblur, and onselect), rather than device-specific event handlers (such as onmouseover, onmouseout, and ondblclick). Sometimes, though, you need to use both. You may need to supply a mouse-specific event handler and a redundant keyboard-specific event handler in some circumstances. Be sure to test it both ways, and to also test on touchscreens.

Question 18

Control the Focus

Operable

Answer 18

When you create dynamic interactions, always pay close attention to the location of the programmatic focus. Usually the programmatic focus is the same as the keyboard focus. Most browsers will highlight the programmatic focus with a dotted line or glowing colored line around the element. When you create a popup modal dialog, ensure that the focus automatically lands on the modal dialog. When a user exits the modal dialog, ensure that the focus returns to the previous focus location. Don’t let the focus get lost, because when that happens, usually the focus reverts back to the top of the document, and the user is forced to navigate back down to the previous location, wasting the user’s time and efforts.

Question 19

Timing

Operable

Answer 19

In addition to ensuring that things work with various devices, you have to ensure that people have enough time to interact with the content. A detailed form—such as a mortgage loan application, a college admissions application, or tax forms (yikes!)—can take a long time to fill out, even if you are completely physically able. You wouldn’t want to force an automatic session timeout when a user is in the middle of filling out a form like this, because there is a chance that the user might lose all of the data entered and have to start over again. Session timeouts are allowable as long as you give the user sufficient warning, for example in a popup notification. Just ensure that the notification is accessible! (Users need to get into, within, through, and out of the notification.)

Question 20

(Operable)
Keyboards: The (almost) Universal Input Device

Answer 20

You can accomplish near-universal operability of your web content by making it keyboard-accessible. People without disabilities use keyboards. Blind people use keyboards instead of mouse or touchpad devices because they can’t see where the mouse pointer is on the screen, making the mouse rather useless. People with some kinds of motor disabilities use keyboards (in some cases special adaptive keyboards) because they can’t control the movements of a mouse or touchpad. Even most touchscreens have onscreen keyboards, and they allow navigation through interface components in a way that emulates using the tab key, arrow keys, enter key, and/or escape key on a keyboard. What’s more, most specialized input devices emulate the functionality of the keyboard. Devices that sense simple movements in a person’s cheek or elbow or other body part, for example, can be adapted to emulate keystrokes for typing text or for navigating the interface. The input process is often slower with these special hardware and software combinations; given enough time, users of these technologies can do all that non-disabled users can do, as long as the content and interface have been made keyboard-accessible.

In saying that the keyboard is the near-universal input device, don’t take this to mean that you should ignore mouse users. You still need to make content accessible to them, and you still need to test for mouse accessibility. In fact, there are some specialized input devices that emulate mouse functionality, such as through eye gaze tracking or other means. You wouldn’t want to write scripts that only allowed keyboard access, for instance. It just means that you don’t need to test with every conceivable hardware and software combination to ensure that you’ve taken into account all of the possibilities. If you can use web content with a keyboard and with a mouse, chances are very high that you can use it on most every other device. There are exceptions, as you might imagine, but those exceptions are uncommon.

Question 21

Understandable

Answer 21

Understandability is about making content and interfaces that people can comprehend.

Question 22

(Understandable)
Specify the Language

Answer 22

Screen readers convert digital text into synthesized speech—they read the text aloud—or into braille output for use in a refreshable braille device. If language of the web page is not designated in the markup (for example: <html lang="en">), the screen reader will read using the pronunciation rules of whatever language is specified in the user’s default settings. That’s fine if a user speaks only one language and visits pages in only that language, assuming that the user correctly sets the default language in the screen reader. If a user speaks two languages, though, and visits web sites in both languages, the screen reader will not automatically switch between languages unless the web page itself specifies which language to use. If the screen reader uses the wrong pronunciation rules, it will sound awful, and will not be understandable. In order to hear the web content read correctly, the user will have to change the language setting every time when going back and forth between this page and other pages in other languages. That’s an inconvenience that web developers can prevent, by specifying the language in the markup. It is also possible to mark words, phrases, or passages of text within a page as a different language (for example: <span>Je parle français</span>).

Question 23

Simplify the Reading or Vocabulary level

Understandable

Answer 23

Reading is hard for some people. Reading disorders are quite common, so even though it can actually be quite hard to simplify your writing, it can be worth it for people with reading disabilities. The kinds of things that are difficult include:

• long or unfamiliar words
• long sentences
• complex sentence construction
• unclear wording
• long passages of text (it’s usually best to break up text into sections with headings, shorter paragraphs, and lists, where appropriate)
• lines of text that are too close to each other (it’s usually best to include some blank visual space between lines of text)

There are other considerations as well, but these are a good start.

Question 24

Limit or Avoid Terminology or Concepts that are Unfamiliar or Complex

Understandable

Answer 24

Unfamiliar technical jargon or slang can be confusing. Culturally-specific words or concepts can also be confusing or easily misunderstood because the person does not have the necessary cultural heritage or education to understand the context. Some people with more generalized cognitive disabilities are unable to understand complex ideas and abstractions. The more you can simplify the content, the better for these individuals.

Question 25

(Understandable)
Provide Supplemental Formats

Answer 25

Some people can’t read at all. No amount of simplifying of the reading level of the text will make the text any more readable to people whose brains can’t process text. For these people, you need to provide alternative formats, such as images, audio, or video, and those alternative formats would need to present the content as directly and as simply as possible. If creating all of those alternative formats sounds like it would take a lot of work, that’s because it would. If your main audience is people who can’t read, then you would need to do this, but for general audiences you would not. Accessibility guidelines don’t require you to go to this level of extreme accessibility. It’s true that some people need it, but we have to be realistic and acknowledge that converting all text to images, audio, or video would be an undue burden on most organizations. Even so, the principle remains valid: providing supplemental formats can benefit people with various kinds of cognitive disabilities. In fact, there is some evidence that people have different styles of learning based at least partially on different sensory modalities. Those with a verbal or linguistic style of learning will likely process text well. Those with a visual or spatial style of learning will benefit from pictures and video content. Those with an aural or auditory-musical style of learning will benefit from audio versions of content, or from multimedia videos.

Question 26

Consistency and Predictability

Understandable

Answer 26

Web sites with multiple pages or views should maintain a consistent look and feel across the pages or views. The visual layout and underlying reading order and tab order should not change radically from one page to another within the same context. The main navigation should generally contain the same links (though some links in submenus may be hidden in some views) and the text in those links should be consistent. Form controls, custom controls, and custom widgets should behave in standard ways, in accordance with common conventions. It is generally a bad idea to design a completely new and different way of interacting with web components unless there is a compelling reason, or as an experiment. Even then, you would probably need to provide some additional instructions to let users know how to use the new components.

Question 27

Provide Instructions, Hints, and Contextual Help

Understandable

Answer 27

When asking for user input, it is often appropriate to provide instructions at the beginning of the interaction, for example at the top of a form, explaining the purpose of the interaction, and what the user should do. If a field has any special constraints, these constraints should be visibly noted next to the field and should be communicated to screen reader users. Constraints can include such things as:

• A field is required
• A button is read-only or disabled
• The data must be in a certain format
• A password must be a minimum number of characters and/or it must consist of both numbers and letters, or must have an uppercase letter, or must have a special character, etc.
• The total number of characters cannot exceed a certain threshold
• And others

Question 28

Provide Feedback with Confirmation and Error Messages

Understandable

Answer 28

When a user submits a form or interacts with a component in a way that submits data to a server, confirm that the interaction has taken place, and tell the user whether it was successful or not. Always ensure that the confirmation and error messages are available to both sighted users and blind screen reader users. In most circumstances, the message should be read immediately to screen reader users, without requiring them to hunt for the message or to bypass long passages of navigation or text. You can notify screen readers by sending the focus immediately to the message or by placing the message in an alert dialog.

Question 29

Robust

Answer 29

Robustness is about ensuring compatibility with a broad range of user agents, including assistive technologies.

Question 30

(Robust)
User Agents

Answer 30

Different user agents (browsers and other web devices) parse web content differently. The differences are apparent across platforms (Windows, Mac, iOS, Android, Linux, etc.), and even across different versions of the same browser. For example, Internet Explorer 8 parses HTML quite differently from Internet Explorer 11, in part because of bug fixes and features added, and in part because of advances in support for newer web specifications, such as HTML 5 and CSS 3. Different versions of screen readers also handle content differently, with newer versions featuring better support for newer technologies such as ARIA. It would be impossible to support all possible combinations of all user agents. There are too many to take into account, and some of them simply aren’t robust enough themselves to handle the kinds of things that are necessary for ideal accessibility. You’ll have to draw a line in the sand somewhere and say that you’ll support Internet Explorer only back to version X, or that you won’t support browser Y because its user base is so small and/or because the browser doesn’t have a feature set that is rich enough.

Question 31

Use Standard Markup

Robust

Answer 31

One of the best ways to increase the likelihood of robust markup and code across user agents is to use standard markup. To the extent possible, the content should be validated using appropriate validators. You can validate the HTML, CSS, JavaScript, and other aspects of the markup. Valid markup doesn’t guarantee accessibility. And in fact, valid markup is not always necessary for accessibility; it is not a one-to-one relationship between validity and accessibility or robustness. Even so, valid code definitely helps eliminate some of the issues that can lead to problems in different user agents, making your job easier when it comes to narrowing down the causes of potential accessibility problems.

Question 32

Use ARIA (or other means) to Indicate the Name, Role, and Value of Interactive Components

Robust

Answer 32

In the old days of the web, web pages were basically static. They did not have much capability for interaction. These days, most major web sites are highly dynamic, often using custom widgets and scripts to create opportunities for interaction and dynamic display of information. This high level of interactivity demands careful attention to how objects are marked up. Screen reader users need to know that an item is expandable and whether it is currently expanded or collapsed (aria-expanded=”true” or aria-expanded=”false”). They need to know if a tab is selected or not (aria-selected=”true” or aria-selected=”false”). It’s not enough to set these properties once on a page. These properties need to be updated dynamically using JavaScript when their state changes. ARIA (“Accessible Rich Internet Applications”) provides a wealth of capabilities for dynamic content that were very difficult or impossible to achieve before. Learn ARIA and apply it.