Web Accessibility Principles Flashcards
(32 cards)
The Web Content Accessibility Guidelines
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.
Web Accessibility Principles
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.
WCAG Principles
Web pages and applications must be:
- Perceivable
- Operable
- Understandable
- Robust
You can remember the principles by the acronym: POUR.
3 Levels of the WCAG
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.
Perceivable
Perceivability is about making the output of web content available through multiple sensory modalities.
Biological Pathways to Perception
Perceivable
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.
(Perceivable)
Seeing Web Content
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.
(Perceivable)
Hearing Web Content
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.
(Perceivable)
Feeling Web Content
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.
Why Perceivability Matters
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.
(Perceivable)
The Universal Format: Digital Text
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.
Making Dynamic Content Perceivable
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.
Make Sure Users Know What’s on the Web Page
Perceivable
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.
Operable
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)
(Operable)
Everything Has to Work
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.
(Operable)
In, Within, Through, and Out
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.
Scripting for Device Independence
Operable
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.
Control the Focus
Operable
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.
Timing
Operable
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.)
(Operable)
Keyboards: The (almost) Universal Input Device
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.
Understandable
Understandability is about making content and interfaces that people can comprehend.
(Understandable)
Specify the Language
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>).
Simplify the Reading or Vocabulary level
Understandable
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.
Limit or Avoid Terminology or Concepts that are Unfamiliar or Complex
Understandable
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.
