The first thing to learn about WCAG 2.1 is its four principles. These principles are used to organize guidelines and potential barriers by common elements. Here, we’ll introduce the principles, and, in the next four units we’ll expand on the types of barriers each principle covers, along with examples you can experience for yourself.

The four WCAG principles are:

Web content must be:

1. Perceivable: Users must be able to process web content by seeing, hearing, or touching it (and someday maybe smelling it). If one sense is missing, such as sight, information must be perceivable through another sense, such as hearing.
2. Operable: In general terms, web content must operate with both a keyboard and a mouse but may also operate through voice or other alternative input devices like switches and a head-controlled mouse.
3. Understandable: Web content is presented in a consistent, predictable, readable form that reduces the likelihood of making errors and can be understood by a wide range of users.
4. Robust: Web content adopts standards that allow it to function or be understood across a wide range of technologies and will continue to function into the future as technologies evolve.

To help remember the principles, think of the acronym POUR.

The four principles are the top layer of guidance on producing accessible web content. Each principle includes:

• General guidelines
• Success criteria
• Sufficient and advisory techniques

Each of these elements will be covered in the pages that follow.

WCAG 2.1 groups guidelines by their level of importance and their relative impact on accessibility. It is helpful to think of these levels as things that must, should, and could be done to eliminate potential barriers. The levels are Level A, Level AA, and Level AAA.

Level A

Level A guidelines address barriers that will prevent some groups from accessing web content. They MUST be addressed or the content will not be accessible to some people.

An example of a Level A barrier is an image that is not described in text (Success Criteria 1.1.1). There is little a person who is blind can do, without the help of another person, to determine what is being presented in an image when it is not described.

Level AA

Level AA guidelines address barriers that may make it difficult to access web content, but it may still be possible through workarounds or added effort. They SHOULD be addressed, or the content will be more effortful to access than it needs to be.

An example of a Level AA barrier is keyboard focus that is not visible (Success Criteria 2.4.7). For someone with low vision who navigates web content with a keyboard, the inability to see when a link has focus, for instance, makes it difficult to know when to press Enter to activate the link. They may still be able to find their way to the link through trial and error, but a lot of unnecessary effort would be needed.

Level AAA

Level AAA guidelines address usability, more so than barriers. These items COULD be addressed to improve usability for everyone.

An example of a Level AAA usability issue is the lower-level high school reading–level requirement (Success Criteria 3.1.5). For instance, if someone reads in a second language, the use of simpler language, whenever possible, makes reading easier. The use of simpler language also improves accuracy when using automated translation tools. Even for typical readers reading in their first language, using simpler language is generally appreciated and easier to comprehend. For someone with a cognitive disability, simpler language will be easier to understand. In each case, however, the reading level does not prevent a person from accessing the content, but that content would be more usable if it were addressed.

Which Level Should Be the Goal?

Level AA is the generally accepted level of accessibility websites should aim to meet. If it is not possible to meet the requirements at this level, then Level A should be a temporary goal, while working toward Level AA over time. Very few websites will meet Level AAA requirements, and, in some cases, it may be counterproductive or undesirable to meet these guidelines. Take, for example, an online medical sciences book. If the Level AAA reading level guideline were followed, it would probably make the content unusable by the intended audience (medical students), if jargon and technical language is replaced with low level paraphrasing to meet this requirement. That said, most public websites that cater to a general audience should probably meet the lower-level high school reading–level requirement.

In addition to meeting Level AA requirements, websites can address some of the Level AAA guidelines, but meeting Level AAA should generally not be the goal.

There are 13 guidelines in WCAG 2.1 (e.g., Guideline 1.1), containing a total of 78 success criteria (e.g., Success Criterion 1.1.1), that represent basic goals web authors and developers should aim for. Compared with WCAG 2.0, WCAG 2.1 adds one additional guideline (2.5) and 17 additional success criteria. Guidelines provide a framework for organizing success criteria.

Examining a guideline below from WCAG 2.1, you can see the principle listed first (2. Operable), followed by a guideline associated with that principle (Guideline 2.1 Keyboard Accessible), followed by a success criterion associated with the guideline (Success Criterion 2.1.1 Keyboard).

Note: The guidelines themselves are not meant to be testable. Success criteria are testable. You may also notice that success criteria are technology-neutral. That is, they are not specific to HTML, JavaScript, Flash, or any other web technology. Instead, these technology-specific references are found in the Sufficient and Advisory Techniques, described on the next page. These techniques can be found by following the “How to Meet” link to the right of each success criterion. Additional information about the guideline can be found by following the “Understanding” link.

Normative vs. Informative

WCAG documents are classified as either “normative” or “informative.” Guidelines and success criteria are normative. That is, they are required for conformance. Elements of WCAG that are normative are also stable and do not change until at least a new version of the guidelines is released. For example, the guidelines and success criteria in WCAG 2.1 will not change until WCAG 3.0 (or whatever version number it is assigned) is released.

On the other hand, the Understanding and Techniques documents are “informative” (also known as “non-normative”), which means they are not required for conformance. These documents are evolving and change as new information and new techniques become available in between releases of stable, normative, specification documents.

For each success criteria in WCAG, there are supporting techniques available that provide potential solutions or strategies that can be used to ensure barriers are removed in web content. The techniques documents continue to evolve over time (i.e., informative). New techniques are added as technology and our understanding of barriers and solutions improve. This is unlike the WCAG specification itself, which stays stable (i.e., normative) until a new version of the specification is created.

While techniques listed in the WCAG supporting documents are recommended, strategies for eliminating barriers are not required per se. There may be several techniques available to address a success criteria, or there may be techniques available that are not listed in the supporting documents. As such, techniques are not a requirement; success criteria are. Any technique can be used that reliably removes barriers associated with a particular success criterion.

There are two types of techniques that can be used to remove barriers: sufficient techniques and advisory techniques.

Sufficient Techniques

Sufficient techniques are techniques known to reliably address particular barriers. They are typically technology-specific, particular techniques with a related prefix for resolving HTML accessibility (H), scripting accessibility (SCR), Flash accessibility (FLASH), or one of the other technologies outlined in the following list:

• General (G)
• HTML (H)
• CSS (C)
• Client Side Scripting (SCR)
• Server Side Scripting (SVR)
• WAI-ARIA (ARIA)
• Flash (FLASH)
• Failures (F)
• PDF documents (PDF)
• Silverlight (SL)
• SMIL (SM)
• Plain-Text (T)

An example of a sufficient technique for Guideline 1.1, Success Criteria 1.1.1 Non-text Content, is technique “H37 Using alt attributes on img elements.” Adding alt text to an image that requires a short description is sufficient to make the meaningful information in the image accessible. But also, “ARIA6: Using aria-label to provide labels for objects” is listed as a sufficient technique for this success criterion. While the latter technique may be sufficient for those using current technology, there is a possibility, for those using an older browser or assistive technology (AT), that the WAI-ARIA solution may not be supported by their AT. That is, despite being a sufficient technique, it is still a good idea to include some redundancy where newer solutions are being applied. An example of this backwards compatibility is using both alt text and aria-label to provide image descriptions. If aria-label fails, the alt text will be read in its place. This is sometimes referred to as “graceful degradation.”

Note: Don’t be too concerned about understanding WAI-ARIA techniques at this point. These are typically techniques web developers would apply, or it may be applied behind the scenes by authoring tools when creating web content. For example, consider the task of adding alt text to an image you should understand (i.e., an image that is not decorative). The alt text code will look like the example below when presented in the HTML of a web page. It may be added to images through a text, alt, or title field in the authoring tool used to insert the image into a web page.

<img src="mycat.jpg" alt="My cat Bob relaxing in the sun" / >

Advisory Techniques

Advisory techniques may not reliably address barriers as can sufficient techniques, but they do address a particular barrier for particular people.

An example of an advisory technique might be “C22: Using CSS to control visual presentation of text” for Success Criteria 1.3.1 Info and Relationships. While this technique can be used to style text with various sizes, fonts, or indentations to represent document structure (the appearance of headings and subheadings), the visual appearance of the content will not be sufficient for those who cannot see the visual presentation. As a result, this technique needs to be used in addition to a sufficient technique that adds the structural semantics provided by the HTML heading elements, H1 to H6 (H42: Using h1-h6 to identify headings).

A Third Category of Techniques

There is a third category of techniques called failures. These are not techniques that could be used to resolve potential barriers. Rather, failures are techniques that, when used, potentially introduce barriers. Techniques listed in this category should be avoided.

An example of a failure is “F43: Failure of Success Criterion 1.3.1 due to using structural markup in a way that does not represent relationships in the content.” In this case, a web author or developer uses HTML heading markup to make text larger. As a result, the large text becomes part of the document’s topic structure. When read by assistive technologies, the text is announced as a heading, which may result in confusion since a heading structure is presented where none is expected. In a case like this, the C22 advisory technique mentioned above should be used to size the fonts instead of using the structural markup and larger text provided by HTML headings.

Selecting a Level of Conformance

Each level of accessibility can represent goals with which organizations and websites should aim to conform. Depending on the website — whether it’s a site being retrofitted to improve its state of accessibility or if it’s a new website being developed — the conformance goal may vary.

As you’ll recall, Level A allows most people to access the content of a website. While Level A conformance is an honourable accomplishment, it is generally considered “minimal conformance.” If you are working with a limited budget (or no budget) this may be an acceptable level of accessibility. However, as mentioned earlier, it is generally accepted that most sites should strive for Level AA and, perhaps, should conform with a few of the Level AAA success criteria (defined below).

If you are working on a new website, Level AA should be the goal from the start. Assuming the developers know what needs to be done, there is very little extra effort required to jump from Level A to Level AA. If you are working with an existing site that is receiving an accessibility retrofit, then you may want to first aim for Level A, then with time resolve all Level AA issues. Generally, it is less costly to build a site to be accessible from the start than it is to build a site and retrofit it later to conform.

Level AAA conformance is unattainable for many websites. While it is possible to conform with some of the requirements at this level, they can often be counterproductive or unnecessary. Take for instance the reading level requirement (WCAG 2.0, SC 3.1.5). Public organizations will want to meet this guideline, reducing the reading level required to understand their website’s content and thereby reaching the broadest audience possible. But for other sites that focus on a particular or highly educated audience, it may be impossible or even inadvisable to comply with this requirement. Imagine an advanced book in biomechanics written at the lower secondary school reading level required to satisfy this guideline. If it were possible, replacing the advanced terminology and jargon with low-level paraphrasing would likely make the content unusable by the intended audience.

Other Conformance Considerations

In addition to meeting all the Level A, AA, or AAA requirements, there are other conformance requirements to consider before being able to claim conformance at one of these levels:

• Full pages: Conformance applies to full web pages only. It cannot apply to parts of pages.
• Complete processes: When a conformance claim is being made on a collection of pages that make up a web application, for instance, all pages in the collection must conform. If one were to claim “the discussion forum conforms at Level AA,” then all aspects of the forum must conform — logging in, reading posts, posting new messages, and so on.
• Accessibility supported: Techniques to implement accessibility requirements are done in a way that is supported by assistive technologies. For example, there is a linked image, which when clicked, opens a feature. The linked image does not have alt text to describe the function of the image but does include text nearby that says “click the button to open the feature.” This example would not be accessibility supported. Even though the image has been described with text, it has not been described in a way that assistive technologies can make use of it. In this case, by adding alt text to the image, it would be considered accessibility supported because assistive technologies can read alt text. Accessibility support is a very complex issue with many grey areas. Read through “Understanding Accessibility Support” for a discussion of other things to consider when assessing accessibility support.
• Non-interference: When non-accessible technologies are used and accessible alternatives are provided, the inaccessible version must not interfere with access to the accessible version. For instance, an embedded Flash object may have a link to an accessible HTML version on the page following the object. If, while navigating through the page by keyboard or using assistive technology, the cursor becomes trapped in the Flash object, it is interfering with the accessible version that follows. In this case, even though an accessible version is provided, it cannot be accessed; thus, the page does not conform. If a bypass link were provided to skip over the Flash object, and users were able to back out of the object, the page would then conform. Ideally, the Flash object should be created in a way that does not trap the cursor.

Making Conformance Claims

Once a website has addressed all the issues required for a certain level of conformance, it may be desirable to “claim” conformance, though there is no requirement that a claim be made in order to conform.

Basic Conformance Claim

A basic claim must include the date the site was judged to be conformant. Since web content tends to change over time, conformance can typically only be claimed for a specific date (with exceptions such as numbered versions of web software). The basic claim must also include the specification or standard the site is claiming conformance with, and it must include the level of conformance. A basic conformance claim may look like the following:

A conformance claim can be more extensive than just a basic claim like that described above. It can also provide documentation about the accessibility features found on a website, so those accessing the site with assistive technologies can read about these features rather than having to discover them on their own. This documentation is often found linked prominently in the navigation elements of a website, usually near the start of a page so it is easily found by assistive technology users, and it is often labelled “Accessibility” or “Accessibility Statement.”

If the conformance claim does not apply to the whole site (e.g., there may be some older content that remains inaccessible), the scope of the claim should also be specified. For instance, add to the basic claim above, “…for any content added to the site after January 1, 2012.” The claim can also list known issues if there are areas of the site that are known to be inaccessible, perhaps because there isn’t a suitable accessible alternative to a particular technology being used. For example, “…the video conferencing area of the site remains non-conformant due to the lack of an alternative accessible conferencing system.”

Currently, there are two versions of WCAG that are considered stable specifications.

Initially released in 2008, WCAG 2.0 is the basis for many international accessibility rules and regulations, and it remains a stable W3C Recommendation. However, since it was developed when the first smartphones were only just emerging, there is little in the specification to address accessibility through mobile devices. Also, there was little in WCAG 2.0 to address accessibility for people with cognitive disabilities.

On June 5, 2018, WCAG 2.1 was released as a W3C Recommendation. It is intended to extend WCAG 2.0, adding 17 new success criteria and one additional guideline that addresses mobile accessibility, as well as aspects of accessibility for people with cognitive disabilities, among other additions.

A goal in creating WCAG 2.1 has been to ensure that sites that comply with it also continue to comply with WCAG 2.0. This ensures that any obligations to conform with WCAG 2.0 are compatible with WCAG 2.1 conformance, if it is used as the basis for creating accessible web content. Organizations and websites should be aiming to conform with WCAG 2.1 into the future but can continue to conform with WCAG 2.0.

We won’t go into the details and differences between WCAG 2.0 and WCAG 2.1 here, but we will point out the new success criteria, and the one guideline, when we get into the details in the units that follow this one. Look for the following to denote success criteria that fall into WCAG 2.1.

For those in Ontario who want to understand how WCAG 2.0 is related to the Accessibility for Ontarians with Disabilities Act (AODA), this is a brief discussion of how it applies. The AODA legislation outlines a gradual roll-out, initially adopting WCAG 2.0 Level A and working toward Level AA web content accessibility requirements with the exception of two success criteria.

These two exceptions are:

• Success Criteria 1.2.4 Captions Live (Level AA)
• Success Criteria 1.2.5 Audio Description (Prerecorded) (Level AA)

Though the rest of WCAG 2.0 is adopted verbatim, obligated organizations in the province (except the Ontario government that has until January 1, 2020) are not required to provide captions for live events or audio description for prerecorded video. Both of these are Level AA success criteria in WCAG 2.0. Depending on where you are in the world, other jurisdictions will often require these success criteria be met.

There are no plans currently to adopt WCAG 2.1 as the basis for web accessibility in AODA, though AODA is currently going through one of its periodic reviews. Whether WCAG 2.1 will be adopted as the new basis for web accessibility remains to be seen.

The Principle Explained

Sensing

As suggested in the first definition above, people must be able to perceive web content through one or more of their senses. When a person cannot see or hear, for instance, and an alternate means of perceiving is not available, then that content becomes inaccessible to them.

Content may not be perceivable if web authors:

• choose small or hard-to-read fonts;
• specify colours for fonts that do not provide sufficient contrast with the background;
• leave out a text description of a photograph;
• do not provide captions or a transcription for multimedia and audio content; or
• require timed responses.

Perceptual barriers occur when information is communicated entirely through one of the following:

• Sight
• Sound

Most people perceive web content through sight and sound. When content is communicated exclusively through one sense, such as sight, some people will not be able to perceive it.

These types of perceptual barriers are addressed through Guidelines 1.1, 1.2, and 1.4.

Comprehending

The second definition suggests people must be able to comprehend or grasp web content. The ability to comprehend web content can be affected by the structure, the relationships between elements, its complexity, or consistency in the presentation.

Perceptual barriers of this nature occur when:

• information is poorly structured;
• navigation or presentation is inconsistent;
• the focus ordering of content is illogical;
• functional elements are not effectively described or labelled;
• content operates only in a single display orientation; or
• instructions reference content solely through shape, colour, size, or visual location.

These types of perceptual barriers are addressed by Success Criterion 1.3.3 (sensory characteristics), described later in this unit.

Non-Text Content Explained

There is good reason why this guideline is the first. While barriers can affect a wide range of people, those who tend to face the most barriers are people whose visual senses are limited or absent. Given the visual nature of the Web, potential barriers are many. Anything visual that is not described in text is a potential barrier.

Why do I always need alternatives to images in my website?

If a website has photographs, artwork, drawings, or other graphic elements, adding text alternatives is an easy way to make the site accessible to people with certain disabilities. In addition, text alternatives benefit people who use text-based browsers, have slow Internet connections, or have limited data plans. Text alternatives also make it possible to search the Web for images.

1. Many people who are blind use a screen reader to access computers. But screen reading programs only understand text; they cannot interpret the content of images. By writing a description for each image on a web page, screen reader users gain access to the images. In most cases, the description need not be elaborate. The text alternative for a photograph of a sunset can be as simple as “sunset on Georgian Bay.” The text alternative for a reproduction of a Picasso painting might be: “painting of an old man with a guitar by Pablo Picasso.”
2. Text-based browsers do not display images. By providing text alternatives, people who use text-based browsers will see the descriptions displayed in place of the images.
3. Similarly, people with slow Internet connections or limited data plans sometimes set their browser to not display images (web pages load faster when images are not displayed, using up much less bandwidth). By providing text alternatives, users will see the descriptions displayed in place of the images, as opposed to seeing blank spaces where images would have appeared.
4. When search engines “crawl” websites to catalogue their content, they cannot determine what is contained in images (image content detection is in its early stages of development). Search engines only “understand” text. By including text alternatives, search engines are able to catalogue images, making them searchable.

The Art of Alt Text

One of the most common ways to remove barriers associated with visual content is to use the HTML alt attribute with images in web content. When people learn about web accessibility, “alt text” is often introduced first. Alt text for images is, in most cases, an easy accommodation. There is, however, an art to creating effective alt text.

Definition

Elements: Often referred to as HTML tags, these are the main features of HTML syntax. Examples include  <p></p>, <table></table>, or <div></div>, among many others.

What needs to be described in alt text must be done in 125 characters or less. Some screen readers will stop reading at this character length. There is often much more in an image (i.e., a picture is worth a thousand words) than can be described in alt text. Depending on the context, the same image may have different descriptions. Consider the following image in the two contexts described:

Context 1: In a statistics book

In a statistics book the actual data values in the graph may not be important. What may be important is the way that data is presented. Alt text in this case might read:

“When graphing population growth, population is presented on the y-axis, and years are presented on the x-axis.”

Context 2: In an article on global birth rates

In an article that talks about birth rates around the world, the data values will be more important, and the way the data is presented less so. Alt text in this case might read:

“Since 1950, population growth for less-developed countries has increased at 5 times the rate of developed countries. See below.”

Note the reference to additional description with “See below.” With the limitation on the length of alt text, it is commonly necessary to provide additional details about an image in a long description. This can often be accomplished by providing an extended description in the text surrounding the image and in the alt text referring to that description. This extended description can be placed before or after the image or perhaps in a caption for the image. These long descriptions can be beneficial for many people, including those that do not have a disability but perhaps are not sure how to interpret the graph.

A long description for context 2, might then read:

“In 1950, the ratio of population growth between less- and more-developed countries was approximately 2.5:1. Since then, the ratio has increased steadily. Today, that ratio is approximately 6:1. By 2050, that ratio is expected to increase to 9:1, with developed countries maintaining a close-to-zero population growth, compared to a nearly 600% increase in less-developed countries.”

Text Is Special

One important characteristic of text is its adaptability. As mentioned, text makes images searchable and enables search engines to index the alt text of images. Some of the many ways text can be adapted, include:

• Screen readers can convert it to audio
• Screen readers can convert it to Braille
• Text-to-speech software can convert it to audio
• Text can be spoken and accessed with speech recognition software
• It can be translated using translation software
• Tools can simplify text to make it more readable
• Text can be magnified without losing its crisp appearance, unlike images of text
• Text colour can be changed to make it more readable

In short, remember, providing text alternatives is usually a good way to make web content more accessible.

Why do I need to include alternatives for “time-based media” (multimedia)?

If a website includes a multimedia presentation like a movie or video, some people will be unable to perceive (or will have difficulty perceiving) the visuals and/or the audio. By providing alternatives, web content authors improve accessibility for a wide range of individuals with and without disabilities:

1. Individuals who have trouble understanding the visual track include people with visual impairments, certain cognitive disabilities, language disabilities, and learning disabilities. Text alternatives make the multimedia presentation accessible to these people.
2. Individuals who have trouble understanding the audio track include people who are hard of hearing or deaf or who have certain cognitive, language, or learning disabilities. Text alternatives and captioning are the two most common ways to enhance accessibility for people who have trouble processing the audio portion of a multimedia presentation.
3. People who are deaf and blind may have trouble (or be unable to) understand the visual track, the audio track, or both. A special type of text alternative, the alternative for time-based media, can make multimedia accessible to people who are deaf and blind.
4. Second-language learners benefit from text alternatives, especially those who understand a second language better when they read it rather than listen to it.
5. Some people are visual learners — they are “wired” to understand best by looking rather than by hearing or doing. Others are auditory learners — they learn best by listening rather than seeing or doing. Text alternatives help them all get the most from a multimedia presentation.
6. Text alternatives and captions are convenient. For example, a captioned video can be understood in a noisy environment (like a bar) or in a quiet environment (like a bedroom where one person is sleeping while the other is watching a movie).
7. Text alternatives make multimedia searchable. When search engines “crawl” websites to index their content, they cannot “read” movies and videos. Search engines only understand text (though image recognition technology is currently emerging).

Level A Success Criteria for Time-Based Media

1.2.1 Audio-Only and Video-Only (Prerecorded) Explained

When audio content is presented, people who are deaf or hard of hearing may not be able to access it. When video content is presented (without audio), people who are blind may not be able to access it. In both cases, equivalent alternatives are required. In both cases, text equivalents can serve this purpose by reproducing the content of an audio track as text or describing what is going on in the video in text.

A YouTube element has been excluded from this version of the text. You can view it online here: https://pressbooks.library.ryerson.ca/iwacc/?p=170

Video: KQED Captioned Audio (text presentation of an audio-based news story) by dralegalorg

A YouTube element has been excluded from this version of the text. You can view it online here: https://pressbooks.library.ryerson.ca/iwacc/?p=170

Video: Frozen Trailer (Video-only with audio description) by IMSTVUK

1.2.2 Captions (Prerecorded) Explained

Any video that contains meaningful spoken dialogue requires closed captions in order to make the audio portion of the video accessible to people who are deaf or hard of hearing. Captions should identify who is speaking and describe other meaningful audio elements that are relevant to comprehending the video.

Closed vs. Open Captions

Closed captions should be used instead of open captions. The latter type of captions are burned right into the video, cannot be hidden, and are not typically editable. In contrast, closed captions are contained in a text file and are presented over a video. Closed captions can be hidden away if they are not needed, and they are easily edited in a simple text editor.

Exceptions

Though captions are a Level A requirement in WCAG, they are not required when multimedia is being used as an alternative for text and is clearly identified as such. For example,  in the previous unit you saw an ordered list used to describe the steps required to install ChromeVox. For some people, they may prefer to see it done rather than reading instructions. The video that was included with the instructions is an example of a media alternative for text. That video was captioned, but it did not need to be.

Depending on the quality of the dialogue in a video, errors are likely to occur when captions are automatically generated. However, auto-generated captions can be used as an initial set of captions, which a human being can edit to improve accuracy, provided the error rate is less than about 25%. With error rates higher than that, one would be better off captioning manually from scratch.

Automatically generated captions can be used as a temporary measure, if, for example, a video release is time sensitive, and captions cannot be created in time for that release. Video producers should still caption those videos using human captioners, as soon as it is feasible.

A YouTube element has been excluded from this version of the text. You can view it online here: https://pressbooks.library.ryerson.ca/iwacc/?p=170

Video: Learn more about YouTube captions and subtitles by YouTube Spotlight

1.2.3 Audio Description or Media Alternative (Prerecorded) Explained

There are two approaches to this success criteria. Both describe elements of a video, such as actions, characters, scene changes, or on-screen text, among other important information that is not spoken in the dialogue.

1. Audio Description: A secondary audio track is added to a video. During breaks in dialogue of the video, this second audio track describes visual information not referred to in the dialogue.
2. Media Alternative: Important visual information not spoken in the dialogue of the video is integrated into the captions, typically enclosed in square brackets and inserted during breaks in dialogue.

Captions (Live) Explained

People who are deaf or hard of hearing can watch real-time presentations by reading captions.

Captions identify who is speaking and what they are saying, plus other information conveyed through sound effects, music, and other sounds.

At present, human transcribers type the captions for real-time presentations. In the future, speech recognition technology may make it possible to automatically generate captions in real time.

Audio Description (Prerecorded) Explained

This is a slightly more stringent version of SC 1.2.3, which gives authors the option to provide an audio description or a full text alternative in a synchronized media presentation. If authors do one or the other, they are conforming at Level A.

SC 1.2.5 tells authors how to conform at Level AA: they must provide an audio description, a requirement already met if they chose that alternative for SC 1.2.3.

To conform to Level AAA, authors must include an extended audio description. This is covered in SC 1.2.7.

No audio description is necessary if all video track information is already provided in the audio track.

Suggested Reading:

A YouTube element has been excluded from this version of the text. You can view it online here: https://pressbooks.library.ryerson.ca/iwacc/?p=171

Video: Audio Description on YouTube

© James Rath. Released under the terms of a Standard YouTube License. All rights reserved.

Sign Language (Prerecorded) Explained

American Sign Language (ASL) and other forms of sign language are languages in their own right. For one, they are not based on English. Much like French can be translated to English, ASL can also be translated to English. Some people who are Deaf (with a capital D representing a member of the Deaf community) may rely on ASL to communicate and may understand very little English. Hence, typical English captions may not always be understood effectively by a person who is Deaf.

Some people who are deaf grow up in hearing families and will often learn signed English, learn to read lips, and learn to write in English. As a result, they will understand English captions.

• Sign language allows people who are deaf or hard of hearing to understand the audio track of a synchronized media presentation.
• Sign languages are very rich and convey shades of meanings that are not captured in captions. For this reason, sign language interpretation of synchronized media is considered more equivalent than access via captions.
  • Example: A university makes a video of a visiting professor talking to students and faculty and decides to post it online. There is no sign-language interpreter during the original lecture. Afterwards, the university produces a second video of a sign-language interpreter interpreting the professor’s talk. The university “splices” the second video into the corner of the original video.
• Some people who are deaf or hard of hearing are not as fluent in written language as they are in sign language. Conversely, not everybody who is deaf or hard of hearing understands sign language. For this reason, access to synchronized media content is improved by providing sign language as well as captions.

Video: Adding Phosphate to Water (American Sign Language Translation)

A YouTube element has been excluded from this version of the text. You can view it online here: https://pressbooks.library.ryerson.ca/iwacc/?p=172

© GovSnyder. Released under the terms of a Standard YouTube License. All rights reserved.

Video: Obama Tribute to Nelson Mandela: U.S. President Barack Obama in American Sign Language by Real Interpreter

A YouTube element has been excluded from this version of the text. You can view it online here: https://pressbooks.library.ryerson.ca/iwacc/?p=172

© Real Interpreter. Released under the terms of a Standard YouTube License. All rights reserved.

Extended Audio Description (Prerecorded) Explained

• This is similar to SC 1.2.5, which states that authors include audio descriptions in synchronized media presentations. Sometimes there are no (or insufficient) pauses to allow audio descriptions. In these cases, provide extended audio descriptions to convey the sense of the video.
• Extended audio descriptions are done by freezing the presentation at key moments and playing additional audio material. The synchronized media presentation is then resumed.
• Because extended audio descriptions may disrupt viewing for those who do not need them, make it possible to turn the feature on and off. Alternatively, two versions of a presentation, one with extended descriptions and the other without, can be provided.
  • Example: An art school owns a film of an influential artist describing her approach, and she digitizes the film for posting online. She speaks rapidly, with few pauses. As she talks, she rapidly draws shapes on a flip chart. After completing each sketch, she flips the flip chart and starts a new drawing, talking all the while.
  • To make extended audio descriptions, the video is paused after she completes each drawing, and a narrator describes it and her gestures. The video then resumes.

Video: Vintage TV Commercial for Post GrapeNuts (with extended audio description)

A YouTube element has been excluded from this version of the text. You can view it online here: https://pressbooks.library.ryerson.ca/iwacc/?p=172

© AccessForEveryone. Released under the terms of a Standard YouTube License. All rights reserved.

Media Alternative (Prerecorded) Explained

• An “alternative for time-based media” is a method for making audio-visual materials accessible to people who do not see well enough to read captions and who do not hear well enough to listen to dialogue and audio descriptions.
• To create an alternative for time-based media, describe (in writing) all information in the synchronized media (both visual and auditory). This text is the alternative for time-based media. It reads like a book narrative — a running description of everything that happens.
• The alternative for time-based media contains a transcript of all dialogue; descriptions of all visual information (e.g., scene changes, actions, and facial expressions); and descriptions of all non-speech sounds (e.g., laughter, off-screen voices, and background music).
• If the presentation requires user interaction (e.g., buttons labelled “Go to next lesson” at the end of every section), include hypertext links to provide the same functionality.
• These techniques make it possible for people who are deaf-blind to access time-based media using a refreshable Braille display.

Audio-Only (Live) Explained

• To make live events (such as video conferencing, speeches, and radio webcasts) accessible to people who are deaf or hard of hearing, use text alternatives.
• The best text alternative is live text captioning. A trained human operator listens to what is being said and types a verbatim transcript in real time. The operator also adds non-spoken details, such as laughter and applause, that are essential to understanding what is happening.
• If an event follows a script, a transcript prepared in advance is a possibility. However, live captioning is preferred because the operator’s transcript plays out in real time, and the operator can adapt when deviations from the script occur.

Guideline 1.3 Adaptable Explained

Why should I make it possible to present content in different ways?

People need choices in how they use computers. One of the advantages of electronic documents over paper is flexibility. It is — or should be — easy to substitute one font for another or change colours, line spacing, margins, and dozens of other formatting characteristics. By following a handful of guidelines, web content authors make it easy for users to adjust the appearance and organization of web pages to suit users’ individual needs. For example:

1. An individual with low vision can read many web pages when the font is yellow, zoomed at 400% larger than normal, and displayed on a black background. If web content authors follow guidelines, users can substitute a custom style sheet to display pages in their desired format.
2. A screen reader user accesses an online article about Canadian weather. The content includes a data table that shows the number of hours of sunshine per year for every provincial capital. The user can navigate from cell to cell in the table, certain about which cells contain header information and which cells contain data. A user using a screen reader should be able to determine, for example, that Winnipeg receives an average of 2,372 hours of sunshine per year.
3. A lawyer accesses the Internet from a web-enabled cell phone. Despite the small screen, she can easily read the content on a law library site that conforms to WCAG 2.1 guidelines.

Info and Relationships Explained

If you look “under the hood” of a web page, you will find a document that consists of all the words that appear on the page (the “content”) thickly interspersed with words, non-words, numbers, and symbols (the “code”). The code describes how the content should be formatted and what purpose it serves. For example, you might find something like this on a recipe website:

<h1>Recipes for Whole Wheat Bread</h1>

The pair of <h1> and </h1> tags that surround “Recipes for Whole Wheat Bread” means that the phrase appears larger and bolder than the text that surrounds it, and the phrase is the most important heading on the page.

Within that page of recipes there may be several types of whole wheat bread. Each of those would be presented with an <h2> to indicate their relationship as subtopics to the main topic of the page presented in an <h1>. Likewise, within each recipe, there may be an <h3> used to present ingredients, another to present preparation instructions, and yet another for serving suggestions. Each of those <h3> headings has a relationship to the parent <h2> but not to the other <h2> headings that represent other types of whole wheat bread. The following shows a semantic structure (i.e., the relationships of topics and subtopics) associated with the bread recipes.

<h1>Recipes for Whole Wheat Bread</h1> //main topic
   <h2>Whole Grain Bread</h2> //type of bread
       <h3>Ingredients</h3> //recipe elements
       …
       <h3>Preparation</h3>
       …
       <h3>Serving</h3>
       …
   <h2>Multigrain Bread</h2> //type of bread
      <h3>Ingredients</h3> //recipe elements
      …
      <h3>Preparation</h3>
      …
      <h3>Serving</h3>
      …
   <h2>Sourdough Bread</h2> //type of bread
      <h3>Ingredients</h3> //recipe elements
       …
      <h3>Preparation</h3>
      …
      <h3>Serving</h3>
      …

The above semantic structure uses headings that represent topics, and subtopics could also be represented as a nested list. The following list maintains the same relationships defined by the headings above. In this case, there is a main list with one item, the main topic; three sublists with each type of bread; and one sublist under each of those representing the elements of a given recipe.

<ul> //main list of bread recipes
<li>Recipes for Whole Wheat Bread
   <ul> //type of bread
      <li>Whole Grain Bread
      <ul> //recipe elements
         <li>Ingredients
         …
         </li>
         <li>Preparation
         …
         </li>
         <li>Serving
         …
         </li>
      </ul> 
     </li>
  </ul> //End of Whole Grain type
  <ul> //type of bread
     <li>Multigrain Bread
     <ul> //recipe elements
        <li>Ingredients
        …
        </li>
        <li>Preparation
        …
        </li>
        <li>Serving
        …
        </li>
     </ul>
    </li>
  </ul> //End of Multigrain type
  <ul> //type of bread
     <li>Sourdough Bread
     <ul> //recipe elements
         <li>Ingredients
         …
         </li>
         <li>Preparation
         …
         </li>
         <li>Serving
         …
         </li>
     </ul>
     </li> 
   </ul> //End of Sourdough type
</li> 
</ul> //End of main list of bread recipes

SC 1.3.1 requires web content authors to use the right code to generate relationships and associate related information. When they do, browsers and assistive technologies automatically “understand” how content relates to other content on the page. (This is what is meant by “programmatically determined.”) For example:

• On a form with two fields, “Name” and “Email address,” using the correct code, in this case an associated <label> element, ensures that browsers and assistive technologies know that the first field contains the name and the second field contains the email address. In the example markup below, note that the for attribute with each label creates an association with the id attribute of the related input field. When an input field receives focus, the content of the associated label is read out.

<form>
   <label for="firstname">Name</label><input type="text" id="firstname"/>
   <label for="emailaddress">Email</label> <input type="text" id="emailaddress" />
…
</form>

• In a table that displays the population of Canadian provinces, using the correct code, in this case a table header cell represented with <th>, ensures that browsers and assistive technologies associate the data cell (i.e., <td>) that says “11.4 million” with the header cell (i.e., <th>) “Ontario” and the data cell that says “3.3 million” with the header cell “Alberta.”

<table>
  <tr><th>Ontario</th><th>Alberta</th>...</tr>
  <tr><td>11.4 million</td><td>3.3 million</td>...</tr>
   ...
</table>

Meaningful Sequence Explained

There are a range of scenarios where web content must be arranged in a particular order to be effectively understood. For example, when looking up the address for a company, we would expect to find information in this order:

ABC Company
123 Main Street
Suite 456
Toronto
Ontario
M7N 8X9

We might become confused if the information appeared in this order:

ABC Company
Toronto
123 Main Street
Ontario
Suite 456
M7N 8X9

The latter sequence is the presentation order to a screen reader user if the web content author were to use the following layout table to format the address in two columns. By default, screen readers read left to right and top to bottom, thus reading the left then right cells in the first row, left then right cells in the second row, and so on.

Sometimes content can be presented in any order without compromising comprehensibility. For example:

• If an online magazine article contains a sidebar, it usually does not matter whether a person reads the article first or the sidebar first.
• If CSS is used to position a main navigation bar, the content, and a secondary navigation bar, understanding the page does not depend on the order of the sections.

Another common sequencing error occurs with modal dialogs, like the one described below. For a modal dialog to comply with this success criteria, when a user clicks an element (in this case, the button labeled “Add Delivery Address”) to open the dialog, focus must be sent to a focusable element in the dialog. The cursor must then remain trapped in the dialog until the user explicitly dismisses it, either by pressing the escape key or clicking one of the buttons.

Modal dialog sequencing failures occur when:

• The cursor is not sent to the dialog when it opens, and keyboard navigation continues through the content in behind the dialog.
• While navigating through the dialog, the cursor does not loop back to the start of the dialog after reaching its last element. Navigation moves from the dialog back to the content in behind before the user has acknowledged or dismissed the dialog.
• When the dialog is acknowledged or dismissed, and the cursor’s focus returns to the start of the browser window rather than returning to the location the dialog was opened from.

Sensory Characteristics Explained

Some users with disabilities cannot perceive shape, position, colour, or location due to the nature of their disability and/or the assistive technologies they use.

Here’s an example: There are three buttons at the bottom of a survey form. The instructions read: “Click the brown button to exit the survey without saving. Click the square button to save in-progress survey results. Click the large button to submit your results.” A screen reader user cannot determine which button is brown, square, or large.

The form buttons in the example above can be made accessible by labelling the brown button “Exit without saving;” the square button “Save partial results;” and the large button “Submit your results.”

In addition to the button examples above, phrases like “make a choice from the menu on the left” will be more accessible as “immediately following the main menu near the top of the page, make a choice from the content menu on the left.” In the latter case, the user can find the main menu, assuming it is labelled as such, and, when it is announced, understand what follows will be the content menu.

When including instructions that describe how to interact with the content of a web page, do not state the instructions exclusively in terms of a single sensory characteristic. Instead, provide additional or alternate descriptions.

WCAG 2.1 added two new Level AA and one new Level AAA Success Criteria for Guideline 1.3.

Orientation Explained

When WCAG 2.0 was introduced in 2008, the first iPhone had only just been released. At that time there was no real consideration regarding device orientation because, typically, there was no need. Today, however, mobile devices have become as prevalent as computer screens, and orientation is a key characteristic of such devices. Even computer monitors these days typically have an orientation setting that allow a monitor to be turned to a vertical orientation.

It is common for people to mount a mobile device on their wheelchair arm, for instance. Depending on preference, the device may be positioned in either a portrait or landscape orientation. If web content is limited to a particular orientation, it can make content difficult to access effectively in cases like this.

There are occasions where orientation has to be limited to landscape or to portrait, but in general, such a limitation should be avoided.

Some examples where orientation may be restricted could include:

• A piano app, which would need to be in a landscape orientation in order for the piano keys to be wide enough to touch individually with a finger
• A cheque deposit function in a banking app, where landscape orientation would be required

Identify Input Purpose Explained

For people with cognitive disabilities, low vision, or some types of learning disabilities, it can be difficult to determine the purpose of a form field or the correct format for the data being entered. This success criteria indicates that browsers and assistive technologies must be able to determine the expected input.

While browsers have been able to do this for some time, it’s only recently that browsers have used their own strategies to automatically fill (autofill) forms with predefined data using technology-specific algorithms. For instance, Firefox will remember values entered into a field named “name” or “telephone.” So, the next time a field with the same name is encountered, it will offer up the values that were previously entered into a field with the same name. While this does provide some indication of the expected input, they are general and not exact. That is, “name” could refer to first or last name; “telephone” could include a country code, area code, and extension, and so on.

In HTML 5.2, the “autocomplete” attribute was added to help developers meet this requirement in WCAG 2.1. It can be used to provide specific descriptions about the purpose for form fields. For the name example, one could add autocomplete="given-name" and autocomplete="family-name" to make it clearer what name is expected for respective form fields. If these values have been previously saved, they would be offered to the user to choose from, so they are not required to type their name.

There is fairly good support for the autocomplete attribute across current browsers. Form developers are encouraged to use it to make it easier for people with disabilities to fill out forms. Consequently, it makes filling out forms more efficient for everyone, including frequent online shoppers, for example. For more about “autocomplete” see the suggested readings below.

Identify Purpose Explained

In addition to roles associated with various user interface elements that identify what an element is (e.g., role="link" for a link), this success criteria adds a purpose to that role (e.g., a link to the site’s home page).

These “purposes” are defined by the W3C’s Cognitive and Learning Disabilities Accessibility Task Force (COGA). It will likely be introduced with the next version of WAI-ARIA, which will provide standard ways to define purpose that will help make content on the Web easier to understand, particularly for those with cognitive disabilities.

For example, icons may be used to provide a visual representation of an element. The home link, for instance, might include a house icon, along with the word “home” to represent the link. Those who are then unable to read the word can make use of the visual representation. Being defined in a standard way (e.g., aria-function="home-link"), technology will be able to read (i.e., programmatically determine) these “purpose” attributes, making it possible for users to replace the icons with their own, perhaps using an arrow icon to represent home, for instance, which may be more meaningful to a particular person than a house icon.

Though standardizing how purpose will be identified is still a work in progress, there are already WAI-ARIA landmark roles that function to define the purpose of regions on a web page (e.g., banner, navigation, main, or complementary). This then makes it possible for technology to identify those regions. A user can potentially hide away everything except the main region on the page, which contains the primary content, so, for example, a person with an attention-related disability is not distracted by other elements on the page.

Personalization of this nature is an evolving area of research at W3C and elsewhere, which promises to optimize using the Web for each individual user in the not-too-distant future.

Use of Colour Explained

Most estimates suggest that about 8% of males and 0.5% of females have some form of colour-blindness, ranging from an inability to see colour at all to minor deficiencies seeing specific colours.

Use of colour becomes a barrier for some people when it is used on its own in a meaningful way. For example, “click the green button to start and the red button to stop” is going to be problematic for people who may have trouble seeing greens or reds (the majority of colour-blind individuals) not to mention problematic for people who are blind. A solution in a case like this might be to add the word “Start” to the green button and “Stop” to the red button. Or, in the instructions, suggest using the first/left/top button to start and using the second/right/bottom button to stop.

A common issue in web content occurs when error feedback messages are presented in red or success feedback is presented in green, without some other indicator of what the text represents. A simple fix might be to include a checkmark icon with the success feedback (with alt text of course), and an X icon with an error message. Or, just include the word “Error” with an error message and “Feedback” or “Warning,” and so on with other forms of feedback.

Whenever colour is used in a meaningful way, some other element with equivalent meaning is required. Text as an alternative to colour is often a good choice.

Audio Control Explained

When audio begins playing automatically when a web page loads, it can make it difficult for screen reader users to navigate. Since they rely on the output from their screen reader, other sounds playing at the same time can make it difficult to comprehend either audio stream. Even if there is a way to stop the automatically played audio, finding the stop control can be difficult if one has to distinguish between the audio and the screen reader output in order to find the control.

Though automatically playing audio when a web page loads is discouraged, in cases where it is necessary you must include a way to control the audio volume independent of the system’s audio controls, which also moderates the volume of the screen reader output. Users should be able to reduce the automatically playing audio volume or turn it off without affecting the volume of the screen reader.

Web content developers should avoid using the HTML autoplay attribute.

Try This: ChromeVox and YouTube Autoplay

Turn on ChromeVox. Then view this embedded YouTube video with your monitor turned off. Try to find the stop button using only your keyboard.

A YouTube element has been excluded from this version of the text. You can view it online here: https://pressbooks.library.ryerson.ca/iwacc/?p=175

Video: Accessible Employment Standard for Small Businesses by ONgov

Contrast Explained

For those with low vision or significant colour vision deficiency, low contrast between text colour and background colour can make reading difficult or impossible. These may be people with congenital (genetic) or acquired vision loss, including those with typical reduced visual acuity associated with aging.

Larger font (e.g., 18+ pt or 14 pt bold) is easier to read at lower contrast than typical text, like the text you are reading now, so the required contrast level (a.k.a., relative luminance) can be lower, at a contrast ratio of 3:1. Typical fonts (e.g., approximately 12 pt or less) require a higher contrast to be readable for some people, at a minimum contrast ratio of 4.5:1. These ratios are calculated based on the contrast required by someone with 20/40 visual acuity to effectively read text without the assistance of system or software contrast enhancements (see also: SC 1.4.6 Contrast Enhanced).

A common contrast issue occurs when the colour of link text has its typical underline removed using CSS styles. The resulting link text may not provide sufficient contrast with the surrounding text. In such cases, links that are embedded in a paragraph, for instance, become invisible to many users. The link text may only be discovered by inadvertently passing a mouse pointer over the link, causing the finger pointer to appear. Web content developers will often remove the standard link underline for aesthetic reasons, perhaps not realizing that this creates a barrier for some people. In contrast, for links in navigation menus, removing the underline is less of an issue, since the function of these links is usually obvious. Developers should distinguish between navigation links and links embedded in content, styling the latter with an underline. The underline for links is the default, so they have to be removed intentionally. Developers should avoid removing the underline in such cases.

Colour contrast is relatively easy to check. There are many tools available that take codes for foreground (text) and background colours, then calculate the contrast ratio. These colour codes can be found by using a tool like ColorZilla or by using a browser’s Inspect Element window. In order to use Inspect Element, try selecting an element in the HTML window to the left, then observing the associated colour code in the CSS window on the right, as seen in the figure below.

Figure: In a browser’s Inspect Element window, arrows pointing to an HTML element on the left and its associated colour in the CSS on the right.

Resize Text Explained

The goal of this success criteria is to ensure that people with mild visual disabilities can read content without the need for assistive technology to magnify text. This group of people includes the large population of individuals over 50 years of age, who tend to lose visual acuity with age and often need to increase text size just a little to make it readable.

Current browsers have a built-in zoom feature that will magnify the content on a web page, including images, regardless of how they have been sized. Typically, web content should be sized using relative measures (em or %) rather than absolute measures (pt or px) to ensure that elements throughout a page of web content magnify at the same rate. This includes container elements sized with absolute measures that have relatively sized text in them. If the container is sized with absolute measures, they run the risk of text magnifying but the container remaining the same size. This scenario may result in the magnified text presented one word per line, making it difficult to read. Or magnified text may float over or under adjacent text or other elements on the page, again making it difficult to read.

Relative sizing is also a requirement for responsive designs, which have become the norm for websites in recent years. Most websites are now developed in a way that adapt to the size of the screen they are being viewed on (i.e., they are responsive to screen size). Sizing text with relative measures thus accommodates people who need larger text to make it readable and ensures websites adapt effectively for a range of screen sizes.

Also see SC 1.4.10 Reflow for more about web content adapting to screen size.

Images of Text Explained

Most bitmap (or raster) images are made up of pixels or dots, which makes these images lose their crisp appearance when magnified. In contrast, vector-based images consist of points, lines, and curves and can adapt well to being resized. The vast majority of images on the Web are bitmap images (png, gif, or jpeg).

When bitmap images contain meaningful text and are magnified, the letters will typically pixelate, resulting in ragged edges around letters thereby making text more difficult to read for a person with low vision using browser-based zooming.

Images of text will also be inaccessible to people who are blind and using a screen reader to read web content. Screen readers are not able to extract text from images. While it is possible in some cases to reproduce the text in the alt text for an image or in a long description, this won’t accommodate people with low vision.

While there are some cases where images of text are necessary, generally web content developers should avoid using them. Wherever possible, actual text should be used. Actual text will magnify while keeping its crisp appearance, unlike the pixelated text in a magnified image.

Another reason why web developers may want text instead of images of text is for search engine indexing. Search engines can index text to make it searchable, while images of text cannot be indexed, apart from indexing the associated alt text. Text also uses much less bandwidth than an image of the same text, an important point for developers who are conscious of page loading times and bandwidth usage. By opting for smaller, faster-loading pages, websites can be considerate of data usage for visitors who may have limited data plans or who may turn off images to reduce their data consumption.

Contrast (Enhanced) Explained

This success criteria is a more stringent version of SC 1.4.3. While SC 1.4.3 is intended to accommodate readers with 20/40 vision without the need for assistive technology, SC 1.4.6 is intended to accommodate those with 20/80 vision without the need for assistive technology. These are typical low-vision users who do not use assistive technology. Those with vision loss greater than 20/80 tend to use assistive technology such as magnifiers or contrast-enhancing software. Also, see SC 1.4.3 Contrast Minimum.

Low or No Background Audio Explained

This success criteria is intended to ensure that people with mild to moderate hearing loss are able to distinguish between foreground speech and background sounds and still understand what is being said. The optimal approach is not to have background audio. In cases where background audio is necessary, users should be able to disable the background audio. Alternatively, you should ensure that there is at least 20 decibels between speech volume and the volume of the background audio.

Measuring the separation between foreground speech and background sounds requires audio editing software. Samples are taken from an audio track at two instances: when just the background sound is audible and when both speech and background sounds are audible. Then, the decibel output of each is compared.

Alternatively, someone with good hearing listens to the speech over the background sounds, and if there are any parts that require added attention to comprehend, there is likely less than 20 dB of separation. For someone with a hearing impairment, those parts will be even more difficult to comprehend.

Visual Presentation Explained

This success criteria essentially requires that the presentation of blocks of text be adaptable to the text/font preferences of the reader. This adaptability can benefit people with low vision and people with some cognitive or learning disabilities.

Some people find it easier to read with non-standard text and background colours (e.g., yellow on black). Some people with cognitive or certain learning disabilities will find it easier to read text with a little extra white space between lines. Others find text easier to read when spacing between words is consistent, as opposed to variable spacing in the case of justified text. While the text does not necessarily have to meet all these requirements by default, it must be possible to override the default presentation so readers are able to apply their own styles that meet their particular needs.

Plain text will generally comply with this success criteria. Failures occur when authors or web developers prevent text from adapting. Here are more examples of failures:

• Fonts are sized with absolute measures (e.g., px and pt).
• Text colours are defined with inline styles or older deprecated HTML attributes.
• Paragraph text is justified with inline styles.
• Text container widths are defined in absolute measures.
• Font colour is defined but background colour is not, or vice versa.

Images of Text (No Exceptions) Explained

While SC 1.4.5 allows the use of text in images in some cases (provided there is an actual text alternative available), SC 1.4.9 requires that no images of text are used, apart from logos, essential images of text, or images used only for decoration.

This requirement ensures that those who benefit from adaptable text presentation, as described for SC 1.4.8, are able to apply their text adaptations for all text. Images of text would not otherwise be adaptable to these individuals.

Reflow Explained

The aim of this success criteria has two parts: (1) Allow people with significant vision loss, who do not use screen readers or magnifiers, to magnify web content to 400% using only a browser’s zoom; and (2) allow content to adapt such that there is no need to scroll left or right (or to scroll up and down for vertical languages). When scrolling is required, it can be difficult to move from the end of one line of text to the start of the next. Also, when scrolling is required, there is also the risk that content that is not in the visible area of the screen may go unnoticed.

While reflowing content is very helpful for this group, it is also a prerequisite for responsive designs that adapt to various screen sizes and orientations.

In the figure below, you will see a standard desktop display of the Ryerson website on the left and a reflow version (responsive) on the right. Dragging the right side of the browser window to the left to narrow its width causes the elements on the page to reflow to fit the available space. Likewise, when using your browser’s zoom to increase the view to 400%, the content reflows into a single column, so it can be viewed with ease by someone who needs magnification but does not use an assistive technology.

Figure: A desktop display of a website on the left, adapted through responsive design to fit a narrow screen on the right.

Reflow Exceptions

There are a few exceptions to the reflow rule. Larger images, for example, that when viewed full width in a desktop browser window at 100% will flow off the side of the screen when magnified to 400%. Depending on the content of the image, developers may be able to set the maximum width of images to 100% of the browser window, so it increases in size until it reaches the width of the window. You may notice this happening on the Ryerson website in the activity above.

Data tables are another exception. Header cells and data cells have a particular relationship that cannot be changed without changing the meaning in the table. Both images and data tables are out of scope for this success criteria.

Non-Text Contrast Explained

This success criteria builds on SC 1.4.3 Contrast Minimum, which ensures text is readable over its background colour, extending the need for good contrast to functional elements in web content such as links and forms, as well as other visual elements such as icons, graphs or charts, and infographics, among other graphical objects.

Take links, for example. It is common for web content developers to remove the underline from links for aesthetic reasons. In some cases, removing the underline is okay, when the function of links, such as links in a menu, is obvious to the users. Often link text is blue by default, which over a typical white background will provide sufficient contrast to be readable. However, readers may not be able to distinguish between the blue link text (with the underline removed) and the surrounding black paragraph text. Such links may go unnoticed. The default contrast between the link colour and the surrounding text colour will fail this success criteria.

Another common non-text contrast issue occurs when disabled buttons are greyed out to indicate they are not functional. This may very well be desirable to de-emphasize the button until a particular task is complete or data entered, for example. But it may also create a barrier for low-vision users who may not be able to effectively see the disabled button to know that some task needs to be completed before continuing. In such a case, there are competing needs between those who can see and those who may have difficulty seeing. If higher contrast is required to make the disabled button more visible, it may make the disabled state less distinguishable for those who can see the buttons.

Readers should refer to SC 1.3.5 and SC 1.3.6 for more about potential solutions to competing needs. Icons, for example, might be used in the future with disabled elements, so those who may not be able to see the element have an alternative available through a preference setting that inserts an icon where a disabled element is present.

Text Spacing Explained

You were introduced to text sizing in SC 1.4.4 Resize Text and in SC 1.4.8 Visual Presentation, both of which ensure that readers are able to modify the presentation of text to make it more readable. SC 1.4.12 builds on customizing text properties, adding line height, paragraph spacing, letter spacing, and word spacing to that mix.

This success criteria does not require authors to set these text properties. It requires that they do not prevent users from setting them. It is users who are responsible for applying these properties though tools such as User CSS, introduced earlier. Much like sizing with relative measures (%, em), as discussed with SC 1.4.4, relative sizing should be used for line height and for paragraph, letter, and word spacing. In this way, all elements related to text presentation, including text containers, increase in size at the same rate, rather than floating over adjacent text or floating under an adjacent image or text container, for example.

Similarly, older HTML attributes, such as height and width, should be avoided, as well as inline styles controlling these properties when defining text sizes. The same is true for the four properties associated with this success criteria. HTML attributes and inline styles can make it difficult or impossible for users to adjust text presentation to their liking.

Content on Hover or Focus Explained

SC 1.4.13 Content on Hover or Focus applies to elements like tooltips, popup menus, and other non-modal dialogs (i.e., popups). Modal dialogs are covered under SC 1.3.2 Meaningful Sequence and should not open on hover or focus.

As described in the success criteria above, when a tooltip or small dialog window opens with a definition, for example, users must be able to dismiss the new content without having to move the mouse or having to move focus away from the element that triggered the popup content. This is typically accomplished by scripting the Escape key to dismiss the content. This allows a user who may have screen magnification set high (e.g., 400% or more) to dismiss a popup that is accidentally opened when a mouse pointer or keyboard focus inadvertently hits a trigger, without being forced to navigate away and potentially lose their place in the original content.

Users must also be able to move the mouse pointer away from the trigger to hover in the popup content, without losing the popup when focus on the trigger is removed. Users who have their screen magnified may need to drag their mouse pointer away from the trigger and off the side of the visible screen, in order to bring the whole popup into view.

Finally, popup content must persist until the user explicitly dismisses it. It can take longer for some people with disabilities to read content, so this tactic ensures there is enough time to read through the content of the popup before it disappears.

The Principle Explained

If you follow Principle 1 guidelines, visitors will be able to perceive the content of your website. Principle 2 takes things to the next level: Once visitors can perceive the content, they must be able to act on it. In other words, the content must be operable.

There are four “operable” guidelines:

1. Make it possible to perform all tasks with a keyboard in addition to a mouse.
2. Give users enough time to perform tasks.
3. Avoid information that flashes or flickers — it may trigger seizures.
4. Make it possible for users to navigate, find content, and figure out where they are.

Why must web pages be accessible without a mouse?

Some people cannot use or have difficulties using a mouse. For example:

1. The mouse is designed to be guided by eye. Users who are totally blind cannot see the mouse pointer.
2. Mouse pointers tend to be small. Individuals with low vision may have trouble spotting the mouse pointer on the screen.
3. Someone with a learning disability may find the movements of the mouse pointer distracting, or they may lack the hand-eye coordination needed to reliably use a mouse.
4. Some people have trouble remembering when to left-click, double-click, or right-click.
5. A person who has hand tremors may be unable to hold the mouse steadily enough to click small screen objects. Some seniors who do not have hand tremors report difficulties holding the mouse steady enough to double-click.

Keyboard Explained

The computer mouse is ubiquitous today, but before 1984 most computer users did not use one. The mouse only became pervasive during the mid–1990s. In recent years, other mouse-like devices have been introduced, including trackballs, touchpads, and trackpoints. Now, a mouse (or a similar pointing device) comes with every computer, and most people would be lost without one.

Yet some people cannot use — or have difficulties using — a mouse. For example:

• An individual with low-vision may have trouble locating the mouse pointer on a screen
• A person who is totally blind cannot see the mouse pointer at all
• Someone with a learning disability may find the movements of the mouse pointer distracting
• A person who has hand tremors may be unable to hold the mouse steadily enough to click on small screen objects

In addition, there are individuals who find that pressing a few keys on the keyboard is faster, easier, and more accurate than pointing and clicking. Many “average” computer users know a few keyboard shortcuts, and some “power users” rarely touch the mouse at all.

Many tasks that are typically done with a mouse can be (or should be) easily keyboard accessible, including “clicking” hypertext links, drawing straight lines and regular geometric shapes, and resizing windows. There are even keyboard equivalents for dragging and dropping. But when a task cannot be performed without a mouse, some people will be prevented from taking full advantage of a site.

WCAG 2.1 acknowledges that some tasks cannot reasonably be done with a keyboard, such as real-time flight simulations. Tasks that depend on continuous, time-sensitive movements that do not have start and end points are excluded. But the highest conformance level that such a website can attain for Guideline 2.1 is Level A. To achieve Level AAA, all content must be keyboard accessible. Also, see SC 2.1.3 Keyboard (No Exceptions).

Many of the assistive technologies that people with disabilities rely upon emulate the functionality of a keyboard. Content that is accessible by keyboard can also be accessed by devices that emulate keyboards. For this reason, the ability to interact with web content using only a keyboard is core to web accessibility.

No Keyboard Trap Explained

A “keyboard trap” is an area of a web page where a person gets stuck when navigating without a mouse. You can navigate to a spot by pressing a sequence of keystrokes, but you cannot leave — unless you use a mouse.

Keyboard traps usually occur when applications are embedded in web pages. The main culprits are text editors, spreadsheets, and media players. For example, on some online forums, it is possible to navigate to a built-in text editor by repeatedly pressing the Tab key but impossible to exit it without a mouse.

If there is a non-intuitive keystroke (or series of keystrokes) to escape a keyboard trap, let users know about it. One option would be to provide instructions within the embedded application: “To exit this spreadsheet, press Ctrl + W (Windows) or Command + W (Mac).”

Character Key Shortcuts Explained

This success criteria was introduced in WCAG 2.1 to take into account a growing awareness of the need for keyboard access on the Web, for both desktop and mobile applications. It is intended to address access via single, printable keyboard characters, including numbers, letters, and punctuation used to control websites and web application features. An example might be using the “F” key to open a File menu.

While these shortcuts can be very handy for keyboard-only users, they can be quite problematic for voice users, using speech recognition software to control their computer or mobile device. When using speech recognition software, it is typically possible to switch between command and dictation modes, which can be quite inefficient. Speech users will often use an all-encompassing mode, with pauses between dictation and commands. However, if the pause is too short, commands may end up being dictated into a form or document. These types of errors are typically easy to revert and are more an annoyance than a barrier.

Real problems occur when spoken words in command mode fire off a series of commands associated with the letters in a word. It can be even more problematic when spoken words are picked up in the background, especially from other speakers. The result can completely disorient a user. Watch the following video to see what happens when spoken words are interpreted as commands.

A YouTube element has been excluded from this version of the text. You can view it online here: https://pressbooks.library.ryerson.ca/iwacc/?p=189

Video: Single key shortcuts affecting speech input by Kim Patch

To prevent these types of occurrences, keyboard commands programmed into websites and web applications can include a non-printable character key as a modifier, much like Alt, or Ctrl, or Alt + Ctrl together as the ChromeVox modifier keys. Or, if single characters are to be used, a feature is available to disable character keys or remap them, which allows users to define their own key combinations for various controls.

Keyboard (No Exception) Explained

This is a more stringent version of SC 2.1.1 that states that everything, without exception, must be keyboard accessible.

A web page that has, for example, an embedded helicopter simulator that cannot be piloted without a mouse may conform at Level A. However, if the developers of the simulation devise a way to pilot the helicopter using the arrow keys, the space bar, the Enter key, and the Shift key, then the site may conform at Level AAA.

Why do some people need extra time on the Web?

Individuals who rely on assistive technologies often need time to find what they are looking for on a web page. For example, sighted users can understand a page at a glance, but screen reader users often need to explore a page before they understand how the page is organized.

As people age, they need more time to process information. In addition to helping seniors, flexible time limits benefit individuals who are not technically savvy, are new to electronic information systems, or are not native speakers of the language on the site.

Timing Adjustable Explained

People who have disabilities sometimes need more time to complete tasks than people who do not have disabilities. They may need longer to think, remember, read, react physically, or zero in on pertinent information. Or they may rely on assistive technologies that increase the time they need to write or read.

Additionally, as people age, they may need more time to process information. Flexible time limits help many people, not only seniors. It also benefits individuals who are not technically savvy or who are new to electronic information systems.

SC 2.2.1 lists three ways to ensure that people are not prevented from completing tasks due to lack of time:

• Allow users to turn off time limits
• Allow users to increase the default time limit
• Give users ample warning when their time is about to expire

Exceptions are allowed. For example, it may not be possible to change time limits for time-sensitive events, such as online auctions or tests that measure reaction speed.

In situations that are not time sensitive, 20 hours is given as an upper time limit.

Pause, Stop, Hide Explained

This section applies when content conveys a sense of motion or updates itself automatically. Content that moves or changes may distract some users.

Examples of content that conveys a sense of motion:

• Animations
• Movies
• Games
• Scrolling stock tickers

Automatically updating content is often confined to one area of a web page. Familiar examples include:

• Stock market updates
• Weather updates
• News updates
• Slide shows that automatically advance from one slide to the next

There are two requirements to keep in mind:

• When content conveys a sense of motion: If the moving content starts automatically, lasts longer than five seconds, and is presented in parallel with other content, include a mechanism that allows users to pause, stop, or hide the content.

• When content automatically updates itself: If content begins the update cycle automatically and is presented in parallel with other content, include a mechanism that allows users to pause, stop, hide the content, or control the update frequency.

Here are three examples of how to meet this requirement:

1. A website has an animation that demonstrates how to use a fire extinguisher. The animation has “pause” and “restart” buttons.
2. A website has an advertisement. To draw attention, the advertisement starts to blink when a page loads. But the blinking stops after five seconds.
3. A blog features a slide show of the author’s bicycle trip through the Alps. Next to the slide show is a control that lets visitors adjust the update speed, from zero seconds to 30 seconds per slide.

No Timing Explained

Many people need extra time to perform tasks. Some individuals take longer to think, remember, process information, react physically, or deal with the quirks of assistive technologies. If completing a task within a time limit is not essential, then give people all the time they need.

This requirement does not apply to events that occur in real time, such as fast-paced auctions, multiplayer gaming sites, and similar competitive events.

Examples of how this requirement can be met: 

1. An online test: Students can take as much time as they need to complete the questions.
2. A game: A game is designed to allow players to compete against the clock or to take turns. When they take turns, there are no time limits.
3. An online auction: Each bidder is allowed to submit one bid. Bids are accepted over 24 hours. Once the bidding is closed, the highest bid wins.

Interruptions Explained

Some websites feature late-breaking news, weather reports, stock quotes, and so on that update regularly. There are people, however, who are distracted by frequent updates or do not want them.

Let users postpone automatic updates by giving them the option to disable automatic content updates and/or to specify the frequency of automatic content updates.

For example, the homepage of a news service displays headline updates every 15 minutes. To meet this requirement, the web authors added a drop-down list so that visitors can choose how often to refresh headlines. It has four options: every 15, 30, 60 minutes, or never.

A common error that fails this success criterion occurs when developers use the refresh meta tag to reload the whole page at a set interval to update the content. This can be highly disruptive for some assistive technology users, and, for some people with a cognitive disability, causing them to lose their position in the content, forcing them to start over from the top of the page when it reloads.

It is okay to update the content in the event of an emergency, including threats to life, health, safety, or property.

Re-Authentication Explained

Completing forms, entering credit card information, and using web-based email programs are everyday activities on the Internet. For security reasons, websites usually limit the period of inactivity before a session expires. These time limits cause problems for people who need extra time to input information, especially when they are forced to begin “from scratch” every time.

Make it possible for visitors to continue a transaction after a session expires without losing the information they already entered. Doing this will allow more people to complete authenticated transactions.

Samantha Smith, who has limited use of her hands, logs in to a shopping site. She chooses groceries and proceeds to the checkout. It takes her so long to type her credit card number that the session expires. After logging in again, her grocery order is intact, and the check-out screen contains all of the information that she had entered up to the point that the session expired. No data was lost because the server stored her submission even though the session had timed out.

Timeouts Explained

This success criterion extends SC 2.2.1 Timing Adjustable in cases where a timeout is necessary and where other means of managing time limits described in SC 2.2.1 are not provided. In such cases, keep in mind the following:

• Requirement: Users must be informed at the start of a session about what period of inactivity will cause a timeout.
• Exception: When data is preserved for 20 hours or more after a timeout occurs.

This makes it possible for people with disabilities, as well as older users who may need to take breaks, to potentially complete online activities over multiple sessions without losing their data.

Shopping online is a good example where this success criteria can benefit many users, including people who do not have a disability. Users can typically add items to a “shopping cart” and return later to complete the transaction.

This success criteria does not apply to timeouts that are out of the control of the provider, such as a user closing a browser window or reloading it while it contains unsaved data.

What do I need to know so that content does not cause seizures?

People who have epilepsy can have seizures when exposed to flashing or flickering lights. There are three causes of flickering lights on computer screens:

1. Flashes can be caused by the display.
2. Flashes can be caused by the computer and how it renders images and other content.
3. Flashes can be caused by the content itself.

Although web authors have no control over the first two, they can ensure that flicker is not caused by the content, such as a movie of strobe flashes or an animation of rapid-fire explosions.

To conform at Level AA, WCAG 2.1 describes how to determine safe values for flashing content. To conform at Level AAA, a page must avoid all flashing content.

Three Flashes or Below Threshold Explained

People with a form of epilepsy called photosensitive seizure disorder have seizures when exposed to flashing or flickering lights. Many colours can cause these seizures, but flashing red lights are known to trigger seizures more readily than other colours, and the larger the area flashing, the greater the possibility of inducing a seizure.

To meet this requirement, web authors must ensure that flickering is not caused by the content itself, such as a movie of strobe flashes or an animation with rapidly switching colours.

SC 2.3.1 allows content to flash if it is dim enough and confined to a small area. W3C publishes formulas for determining safe values for “general flash” and “red flash” thresholds. But even these so-called safe values can trigger seizures. Research suggests the greatest sensitivity to flashing is between 10 hz and 25 hz. The next section, SC 2.3.2, is more stringent.

Try This: Flashing Screens

Humans can only detect flashing (i.e., the flicker rate) up to about 50 hz (or 50 flashes per second), after which a screen or content appears continuous. You may recall seeing computer or television screens flickering or the rolling bar that cycles across the screen in cases where a monitor is being viewed in a video or TV program. The cause is the difference in the flash rate of the monitor and the flash rate of the camera recording the monitor.

Even though you cannot see it due to the flash rate being faster than the eye can detect, all screens do flicker.

See the flash of a video recorded monitor:

A YouTube element has been excluded from this version of the text. You can view it online here: https://pressbooks.library.ryerson.ca/iwacc/?p=193

Video: How to make screens look good on camera by Kyle Lawrence

Movie and television producers are now quite aware of flashing screens. Technology is used to prevent it from occurring, which is why you may need to go back to fairly old movies or television programs to see it happening.

Three Flashes Explained

Some people are so sensitive that it is not possible to completely prevent them from having seizures. However, by eliminating all flashing between three and 50 flashes per second everywhere on the screen, the chances of a person having a seizure are reduced.

SC 2.3.1 Three Flashes or Below Threshold (Level A) allows flashing if it is dim enough or is confined to a small enough area. SC 2.3.2 (Level AAA) does not allow flashing at all between three and 50 flashes per second, regardless of brightness or size.

Even a single flashing pixel violates this criterion. The intent is to guard against flashing areas that are larger than a single pixel; but, since an individual may require magnification or high contrast settings, the prohibition is against any flashing.

Animation from Interactions Explained

While SC 2.2.2 Pause, Stop, Hide (Level A) addresses animation that is part of web content, SC 2.3.3 Animation from Interactions (Level AAA) addresses cases where movement occurs on the screen as a result of the user interacting with the content.

People with vestibular disorders, which affect eye movement and balance control, may become dizzy (vertigo) or experience nausea or headaches when encountering content of significant size moving across their visual field. Rapidly paging through an ebook mimics the effect. A similar effect is motion sickness caused by looking out a side window of a moving car. Effects can be quite severe, potentially causing vomiting and requiring bed rest to reduce the symptoms.

As a result, any user-initiated animation should be avoided, or users should be provided with a way to disable such animations.

This success criteria does not apply to essential user-initiated animation. Scrolling, for example, is essential. In this case, users are in control and can adjust their scrolling speed to avoid any motion-related symptoms.

One form of motion in web content that is known to initiate vestibular dysfunction is parallax scrolling. This occurs when, while scrolling, the foreground and background scroll at different rates. If there is a significant difference in the scrolling rate, vestibular symptoms can be brought on.

Why is it important to help visitors navigate?

Navigation on web pages serves two purposes:

1. To tell users where they are.
2. To let users know how to go somewhere else.

These tasks are often more difficult for people with disabilities. This section describes how to help visitors find content and keep track of their location. The same rules that simplify navigation for people with disabilities also improves navigation for users who do not have disabilities.

Bypass Blocks Explained

People who cannot use a mouse often use the Tab key to navigate around web pages: they press Tab to move “forward” through the content; Shift + Tab to move “backward”; and Enter to activate links and buttons. At best, Tab key navigation is a tedious way to get around, but for some non-mouse users, it is the best option.

Many web pages have content that is repeated on every page. For example, a site may have the same navigation links on the top of all pages. If there are 20 navigation links, a non-mouse user could be forced to press the Tab key 20 times just to reach the main content — and do this on every page.

By meeting this requirement, keyboard users can go directly to the main content without the need to press a lot of keys. A simple way to achieve this is to place a “Skip to Content” link as the first link on every page.

“Skip to Content” links also benefit people who use portable web-enabled devices, such as cell phones. Because the screens of these devices are so small, it may be more convenient to click a “Skip to Content” link than to scroll through many screens to reach the content.

There are a variety of ways to provide navigation elements that allow non-mouse users to navigate effectively and reduce or eliminate the need to navigate through web content in the sequence elements appearing on the page. These include:

• Bypass Links: Skip to Content is one type of bypass link, typically located in the top left corner of the page. When a bypass link is followed, focus moves to an anchor elsewhere on the page, skipping past content in between the link and anchor. Bypass links can also be used with other complex elements within the content of a page, such as skipping over a large data table or past an embedded object or application.
• Headings: When proper HTML headings are used in web content, assistive technology users are able to list them and navigate directly to any one of them, skipping over any content in between the location in focus on the page, and the heading farther down the page. Using proper headings is perhaps the easiest way to meet SC 2.4.1 (Level A), if the site already meets SC 1.3.1 Info and Relationships (Level A).
• Landmarks: With the introduction of WAI-ARIA, site developers can add specific roles to regions of the page that screen reader users are able to list and then use to navigate directly to a block with a navigation menu, to the main content area of the page, or to the footer area, among other potential regions. See the link in the suggested readings below for more about landmarks

All three of these strategies can be used together to accommodate a broad range of users. For instance, landmarks may work well for screen reader users but not so well for low-vision users who may not be using a screen reader. Bypass links may be a more effective means for the latter group.

Page Titled Explained

When a screen reader begins reading a page after it has finished loading, the first thing it reads is the page title. A descriptive title immediately tells the listener they are in the right place (or in the wrong place). Without the title, users have to navigate into the page before making that determination.

For most current browsers, holding a mouse pointer over a tab across the top of the browser window reveals the title of the page being viewed. The title is added to a web page using the HTML <title> element.

A good title summarizes a page in a few words, so users do not have to read an entire page to know what it is about. Many screen reader users take advantage of titles to keep track of where they are. A title may be based on the main heading on the page, then followed by the name of the site. If not the same as the main heading, the title should be equivalent in meaning to it. When linking to a page, the link text may be the same as the title of the page the link leads to, thus users can make a direct association between the link they clicked and the page that opens.

Descriptive titles also help people interpret search engine results. Many search engines, including Google, display search results as a list of page titles. Not using descriptive titles can also affect a website’s searchability, and its search ranking, whether it appears near the top of the results for a related search query or not.

When writing web page titles, it is recommended that each title:

1. Identify the subject of the page.
2. Identify the site.
3. Make sense.
4. Be short.
5. Be unique for each page.

It is advisable to position the subject of a page before the name of the site in a page title, just in case the title is truncated to fit available space. Placing the subject before the site/page title allows that unique topic to be informatively displayed in search results or in a browser tab, if the latter part of the title gets truncated.

Focus Order Explained

Content should make sense when navigating by keyboard. Many people who cannot handle (or have difficulty handling) a mouse rely on Tab-key navigation to interact with a web page. That is, they press Tab to move forward through the content; Shift + Tab to move backwards; and Enter to activate links and buttons. Knowing a handful of other hotkeys (keyboard shortcuts) makes it possible for non-mouse users to interact with any web page.

When navigating through a web page via keyboard, people should encounter information in a logical order. This is especially important for screen reader users, who cannot observe how pages are visually organized. When designing for the Web, strive to make the visual organization and the tabbing order correspond.

Link Purpose (in Context) Explained

Links that make sense by themselves enhance usability for everybody. The preferred way to meet the requirement is to write link text that clearly indicates what to expect if the link is followed.

For example:

While using meaningful words that describe the destination of a link is always recommended, this success criteria does allow the use of less meaningful words, provided there is context that adds meaning to those words. SC 2.1.4 refers to the phrase “programmatically determined,” which means essentially, assistive technologies are able to gather meaning from the context in which a link appears, giving the link meaning.

For example: Imagine a news website, like the one in the screenshot below, that presents a series of news headlines. Each headline is followed by a sentence or two to introduce the article, followed by a “continue reading” link that leads to the full article. The words “continue reading” on their own do not contain any useful information about the article; however, if the article title that precedes the meaningless link is also a link to the article, users navigating through the links on the page will hear the title followed by “continue reading,” in which case the article title gives meaning to the otherwise meaningless link, by answering “continue reading what?”

By meeting this requirement, a site conforms at Level A. To conform at Level AAA, see SC 2.4.9.

Multiple Ways Explained

Different people use different ways to focus in on particular content on a website: some prefer site maps; others like navigation links or breadcrumbs; still, others rely on site searches.

Make it possible for visitors to your site to find content in at least two ways. Choose from among these techniques:

• A site map
• A site search
• A table of contents
• Links on the homepage to all pages on the site
• Links to all other pages on the site
• Links to navigate to related web pages

An exception applies when content is not “findable.” A banking website, for example, lets customers transfer funds between accounts. The page that confirms the transfer is exempt because the page does not exist until the customer completes the transfer. WCAG 2.1 acknowledges that pages that are “the result of, or a step in, a process” do not need to conform to SC 2.4.5.

Headings and Labels Explained

When headings and labels are clear and descriptive, they help users understand what information is contained in web pages and how that information is organized. Much like meaningful link text describes the destination of a link, meaningful headings describe a section or paragraph that follows, and meaningful labels describe the purpose or function of a form field.

Focus Visible Explained

Keyboard focus is the one point within a window that receives information from the keyboard. Only one component can have focus at a time. When keyboard-only users press keystrokes, typically the Tab key, to navigate around a web page, they are moving focus from one component to another.

Whether it’s people with low vision who rely on a keyboard to interact with web pages or power users who use a keyboard to navigate more efficiently, each must know which component has focus. By complying with SC 2.4.7, keyboard users can tell at a glance exactly what they are interacting with on a web page.

By default, browsers display focus indicators when navigating by keyboard. If they are not present, they have been purposely removed. For the most part, these indicators appear as faint rectangles that surround the focused component. In text fields, the focus indicator is usually a flashing cursor. Web authors who use CSS and JavaScript can enhance the appearance of focused components or make them invisible or hard to see. Authors often remove the focus visibility for aesthetic reasons, though that practice violates this success criteria. WCAG 2.1 requires web authors to ensure that all focused components are easy to spot when navigating by keyboard.

While the default focus indicator is sufficient to pass the requirements of this success criteria, they can still be difficult to see, even for those with relatively good sight. It is generally recommended that website developers enhance the default focus indicator to make it easier for everyone to see.

Location Explained

When a website or a web application consists of dozens, hundreds, or thousands of pages, it can be easy to become disoriented and tricky to find related information. To help visitors orient themselves, include information about the current location in relation to the whole. This can be done, for example, by:

1. highlighting the current page within a set of navigation links,
2. providing a breadcrumb trail, or
3. describing the relationship of a page to a larger collection of pages.

This requirement may also be met by including a sitemap. Although this involves navigating away from the current page, a site map is a good way to show how information on one page (or in one part of the site) relates to the whole.

Link Purpose (Link Only) Explained

Help visitors understand the purpose of each link. This is a more stringent version of SC 2.4.4, which requires that links make sense on their own, without the benefit of surrounding context to add meaning. This benefits screen reader users who use a feature to extract all links from a page and sort them as an alphabetical list. When each link is unambiguous, individuals who rely on this technique can confidently decide whether they want to follow a link. They may otherwise hear a list of meaningless “Click Here” links.

Some visitors may find pages that consist entirely of unambiguous links easier to access, while others may find them harder to access. The word “mechanism” gives web authors the option to make all links understandable out of context or to provide a way to make them this way. Providing this option gives all visitors the ability to customize the “wordiness” of links to match their needs.

There is an exception to SC 2.4.9 when the purpose of a link cannot be determined from information that appears anywhere on the web page. In this case, a person with the disability is not disadvantaged, as the context is not available to anyone.

Section Headings Explained

Whenever possible, divide pages into sections and begin each section with the heading that reflects the place of the section within the whole.

For example, a long document may be divided into chapters, chapters into topics, topics into subtopics, and subtopics into paragraphs. Headings are designed to organize content hierarchically; they are the scaffolding that give shape to documents.

For HTML documents, use these elements to organize content hierarchically:

• <h1> for the highest level of page organization,
• <h2> for the second level,
• <h3> for the third level,
• and so on.

For Word documents, use these styles to organize content hierarchically:

• Heading 1 for the highest level of page organization,
• Heading 2 for the second level,
• Heading 3 for the third level,
• and so on.

Section headings clarify the organization of the content, facilitate navigation, and aid comprehension. Other page elements, such as horizontal rules and boxes, enhance the visual presentation but are not sufficient in themselves to identify document sections.

This provision is included at Level AAA because headings may be impractical or unsuitable. For example:

• Headings are inappropriate for historical documents that do not have headings. However, if the original document has a title, mark it up as <h1>.
• Headings are not normally used in letters, even when letters cover a range of topics.
• Some electronic file formats, such as plain text, have no built-in support for hierarchically structured documents.

Also, see SC 1.3.1 Info and Relationships (Level A). While SC 2.4.10 (Level AAA) suggests using headings to section content by topic and subtopic within written content (as opposed to interface elements), SC 1.3.1 provides guidance on organizing that content semantically so the relationships between topics and subtopics can be understood. Content that complies with SC 1.3.1, also complies with SC 2.4.10, though not necessarily vice versa.

Why is it important to allow for multiple input modes?

A keyboard was the first input mode for accessing a computer. The mouse was then introduced, greatly improving navigation through web content — for those who could operate a mouse. Various other mouse-like input devices soon followed, like track pads, track balls, eye-gaze pointers, speech control, joysticks, and various other input methods that mimic mouse functions.

Then, mobile devices with touch screens came along and introduced a new range of input methods — these are typically referred to as gestures. Gestures include physical movements like tapping, double tapping, pressing and holding, swiping, dragging, and so on.

Needless to say, limiting input modes can greatly reduce the number of people who are able to use a site. Fortunately, in many cases, designing for both mouse and keyboard access will also allow other input modes. A tap, for instance, is possible for elements that can be clicked with a mouse. A swipe function is much like Tab key navigation. However, it is when developers create custom elements in which mouse and/or keyboard access are scripted that input modes may be limited.

Pointer Gestures Explained

With the introduction of smartphones and touch pads, multipoint gestures have become fairly common place. A multipoint gesture typically requires two or three fingers to perform the gesture. One example is a pinch zoom, placing two fingers on a device screen and spreading them apart, causing the screen to magnify. Some people will not be able to perform such a gesture, so some other means is needed to zoom, such as [-] or [+] buttons that zoom with a single tap or click. Single-point gestures will be more accessible to some and can often be mimicked with a keypress.

These are some examples of multipoint and single-point gestures:

Multipoint gestures:

• Two-finger pinch
• Split tap
• Two- or three-finger taps and swipes.

Single-point gestures:

• Tap
• Double tap
• Press and hold
• Focus and gaze (eye tracking)

Another type of gesture is a path gesture. In the case of a path gesture, users draw a pattern to unlock a screen, or they drag a slider thumb to select a value along a particular range. In both cases, some people will not be able to click-and-drag or point-and-drag, so an alternative will be required. For a slider, users should be able to click on any spot along the slider, and, with a single click, they move the slider thumb to a select position along the slider bar. Users should also be able to control the slider thumb using a keyboard, though this is covered by SC 1.3.1 Keyboard (Level A).

Swipe gestures can also be difficult for some people. For example, a photo gallery may use a swipe to navigate from one image to the next. Next and Previous buttons or links can be added to the gallery viewer so those who are unable to swipe can click. Next and Previous buttons, with some scripting, can also be associated with left and right arrows on the keyboard, so those unable to swipe or point and click can also operate the gallery with a keypress.

This success criterion applies to web content rather than operating system–level gestures. For example, Android phones may have users draw a pattern to unlock the phone. In this case a preference setting is available to switch to a code or to use a fingerprint scanner instead of drawing the pattern. In this case, an operating system–level path gesture can be replaced with a single point method of unlocking the phone.

Pointer Cancellation Explained

The aim of this success criterion is to prevent accidental pointer input, whether through a mouse click or through a touch gesture to activate web content. For instance, by default, activation of a link or button occurs when a click is released or when a finger is lifted. In both cases, it gives a user an opportunity to abort the click or press by moving the pointer away from the element that was clicked before releasing it.

In most cases, activation should not occur during the down action (e.g., mousedown, touchstart); rather, it should occur when the action is released (e.g., mouseup, touchend). One exception occurs in cases where a down-event pops open a dialog, which closes when the up event occurs. Drag-and-drop elements also activate on the down action, i.e., holding down the element while it is moved. Then, the up action occurs when the element is in its new location. In this case, users should be able to release the action outside the allowable drop zone to abort, which returns the element to its initial location.

There are other conventional behaviours that also rely on a down-event, such as typing letters into a form field or clicking a key on a piano app. In such cases, it would be counter-intuitive to have the action occur on the up-event.

Label in Name Explained

This success criterion ensures that people who are using speech input or text-to-speech output are able to draw a connection between what they see on the screen and what their assistive technology reads to them. Assistive technologies read the “accessible name” associated with interface elements, which can be assembled with text gathered from a number of sources, such as a role (e.g., menuitem), state (e.g., enabled), and properties (e.g., haspopup menu) associated with the element, in addition to the text displayed on the screen. The W3C defines “accessible name” as follows:

For those using speech input through voice recognition software, they may encounter a form button created using an image, and in that image is the word “search.” They can speak the word “search” to activate the button but only if the alt text for the image is the same as the text in the button image. In this case, alt is the accessible name, joined with the role “button.”

On the other hand, a developer might also include additional information in a title attribute for the button, with words such as “enter keywords or phrases.” This text is hidden by default but displays when a mouse pointer hovers over the button. For a speech input user, they see the word “search” in the image, though in this case the accessible text would be “enter keywords and phrases.”

As a result of the accessible name differing from the text label for the button, a speech user may be unable to activate the button, in which the visible button text (“search”) and the accessible name (“enter keywords or phrases”) differ. In this case, the text in the button image should be prefixed on the title text. So you end up with an accessible name like “search: enter keywords and phrases.” In this case, the user can speak the word “search” to send focus to the button via its title text.

<button title="Search: enter keywords or phrases">
<img src="search_icon.png" alt="Search">
</button>

Screen reader support for HTML title attribute

*Despite a setting to read title text, title text is not read by JAWS 18

**When title text is present for linked images, title is read, and alt is not read.

Motion Actuation Explained

Most smartphones today include sensors, such as an accelerometer and/or gyroscope, that detect motion of the device. For example, they would detect shaking, which might act as an undo function. Some phones can also detect user gestures through the device’s camera, such as a hand wave to turn the page of an electronic book for instance.

Some people, however, who are unable to move the device (e.g., if it is attached to a wheelchair) or are unable to produce gestures (e.g., are unable to use their hands), will need alternative means of activating these functions. In the case of the undo function, there may be a button alternative that can be pressed when the device is stationary. Or, in the case of an electronic book, speech might be used to turn the page, to tap on the right side of the screen, to swipe left, and so on.

Likewise, motion actuation needs to be an option that can be disabled. If, for instance, a user has a shaky hand, they may inadvertently activate motion-based functions. They may need to disable motion activation. For any function that is activated via motion, an alternative means of activating the function is required that does not require moving the device or gesturing to it.

Target Size Explained

This success criterion was added in WCAG 2.1 to ensure that people are able to activate actions either with a mouse click or a touch. Some people may have difficulty targeting small objects with a mouse pointer, perhaps having difficulty holding the mouse pointer steady enough to click a tiny target area.

One common way to make tiny web elements, such as radio buttons or checkboxes, targetable, is to label them with the HTML label element. When it is used the label itself becomes clickable, creating a larger target area to activate these tiny form elements.

Where target sizes often become problematic is in responsive designs. When web content is viewed on larger screens, target areas may meet the 44 by 44 pixel minimum dimensions, though when viewed on a small device, content may reflow and elements may be reduced in size to fit in the smaller space available. On mobile devices, targets need to be (a) large enough to be touchable with a finger tip without activating other nearby elements unintentionally, and (b) large enough so a finger tip does not completely obscure the element.

Exceptions:

• Targets within a sentence
• When target size is essential and would invalidate an activity or function otherwise
• When an equivalent 44 by 44 target is provided, the original does not need to meet this requirement
• Links at the end of a sentence to a footnote (these are considered to be part of the sentence)
• Elements that are part of the operating system user interface or a user agent (e.g., browser)

Concurrent Input Mechanisms Explained

This success criterion was added in WCAG 2.1 to ensure that users are not limited in the input method they use to access web content. For a mobile device, a finger tip is typically the main input method. For a person who may have limited use of their fingers, however, they might choose to attach a mouse and keyboard to their device to make it easier to operate. Web content must not prevent the use of these or other alternate input devices.

Input type restrictions typically occur when JavaScript is used to handle input. If, for example, a developer chooses to use a touch-specific event handler (e.g., touchstart) without providing alternative access through a mouse event handler (e.g., mousedown), it may make the content unusable by someone who is unable to touch a screen or target elements on the screen. To avoid such limitation, developers can create functions that handle a variety of input methods (e.g., finger, mouse, keyboard, stylus, or joystick), or they can use device-independent event handlers (e.g. focus, blur, or click) that do not rely on any specific input device.

The Principle Explained

If you have ever poked around an attractive-looking website written in a language you do not recognize, you know that it is possible to explore a site without understanding a single word.

Principle 3 builds on the principles that come before it. Conforming to Principle 1 ensures that users can perceive a site. Conforming to Principle 2 ensures that users can act upon a site. But, even if visitors can see and interact with content, a site is not fully accessible if users cannot make sense of it. Principle 3 is about increasing the odds that visitors actually understand the content.

Even if content is written in your own language, it does not make the content understandable. For example, a page may contain:

• Unfamiliar words or abbreviations
• Overly complex instructions
• Messages that tell you that you made a mistake, but fail to explain how to fix it
• Interactive components that look familiar but behave in unpredictable ways

Barriers to understanding content are felt acutely by users with disabilities. Take, for example, the following scenarios:

• A student with low-vision uses magnification software. She needs to enlarge text so much that only a few words fit on the screen at one time. The lack of context makes it harder for her to understand abbreviations. Does “PC” mean personal computer, police constable, politically correct, or privy council?
• A professor with a learning disability is an expert in his field. He is very familiar with the jargon of the field, but he has trouble making sense of long and — from his perspective — unnecessarily complex sentences.
• An online job-application form indicates required fields in colour. Because screen readers only read text, an applicant who is blind is not able to determine which fields are required and which are optional.

By following Principle 3 guidelines, visitors will be better able to understand the content. Principle 3 is organized around three ideas. For web content to be understandable, these three items must be followed:

1. People must be able to read it: The content is readable.
2. The site must behave in ways that people can predict: The content is predictable.
3. The site must be designed to help people avoid mistakes. When they do make mistakes, it should be forgiving of errors. In the language of WCAG 2.1, the site provides input assistance.

What makes content ”readable?”

“Readable” means content can be understood by an educated person, with or without assistive technologies. Also, additional information necessary to understand the content is made available.

The easiest “readability” provision to implement is specifying the language (or languages) that appear on a web page. Language is specified in the page markup and is invisible to readers. Nevertheless, encoding the language — or changes in language — is important. Some browsers and assistive technologies cannot present content correctly unless the web author identifies the language or languages.

Language of Page Explained

Different languages use different alphabets. English, French, and German use the Latin alphabet; Russian and Ukrainian, the Cyrillic alphabet; and Greek, the Greek alphabet. Even when two languages share an alphabet, they may not use the same letters. For example, both English and Slovak are based on the Latin alphabet; however, English has 26 letters, while Slovak has 46.

Although SC 3.1.1 mostly affects individuals who are involved with the technical side of web production, anyone who creates online content should be aware of the rule: every web page must specify the language in which it is written (e.g., English, French, Hebrew, Japanese, and so on). When this rule is followed, browsers, media players, and assistive technologies automatically present text properly.

Specifying the language ensures the following:

• The correct alphabet is displayed
• All letters, characters, and symbols for the specified language are displayed
• Screen readers load the appropriate pronunciation rules
• Media players show the right captions

When a web page uses several languages, specify the language that is used most. If several languages share the spotlight, choose the first language that appears on the page.

The language of a page is defined in the opening html element on the page. The html element should have the lang attribute added, with the appropriate language code as its value. The two-letter language codes for HTML are defined in the ISO 639-1 standard, which are applied as seen in the following markup.

<html lang="en">

Language of Parts Explained

SC 3.1.1 requires you to specify the language of each page. Some pages, however, are written mostly in one language and contain words or phrases in a second language. In these cases, SC 3.1.2 requires you to specify the language of those words and phrases. For example:

• In an English-language novel, a character always speaks French:
  “Where were you Tuesday evening?” he asked.
  “Je ne comprends pas,” she responded.

• A web page includes links to translations of the same page:
  This recipe is also available in français, Deutsch, and 中文.

By following SC 3.1.2, browsers display the appropriate alphabet for these passages, and screen readers pronounce them correctly.

Exceptions: There is no need to specify language changes for the following:

1. Proper names such as Sophia Loren, Olof Palme, and Yma Sumac.
2. Technical terms such as Homo sapien, Alpha Centauri, and habeas corpus.
3. Words or phrases that have become part of another language, such as words that English has borrowed from French: rendezvous, RSVP, laissez-faire, and so on.
4. Words or phrases where the language cannot be determined.

Similar to how language of a page is defined by adding the lang attribute to the opening tag, the language of parts is defined by adding the lang attribute to the HTML element containing language that is not the primary language of the page. In the example below, the French language embedded in otherwise English text is defined as French by adding lang="fr" to a tag enclosing the French text.

<span lang="fr">Je ne comprends pas</span>

Unusual Words Explained

“Unusual words” are words or phrases that readers are unlikely to understand from context alone. This includes:

1. Idioms: Phrases whose meaning cannot be inferred from the meaning of the individual words that make up the phrase, such as spill the beans, turn the tables, and eat crow.
2. Jargon: Specialized terms used by people in particular fields, such as charm (physics), bug (computer programming), and ideological hegemony (cultural studies).

There are many ways to meet SC 3.1.3. For example:

• Follow the first occurrence of each unusual word with its definition
• Use definition lists
• Make a glossary that includes unusual words
• Link unusual words to definitions at the bottom of the page

Content that meets SC 3.1.3 benefits:

• Non-specialists who need to understand specialized information
• Students who are learning about a new or unfamiliar subject
• Second-language learners
• People whose disabilities make it difficult to understand idioms and jargon
• People who use screen magnification software — enlarging the text can cause a loss of context
• People who use handheld web devices with small screens — a small screen may cause loss of context

Abbreviations Explained

Abbreviations and acronyms are convenient for people who know them but confusing for people who don’t.

• Abbreviations may have no obvious connection to the words they represent. Switzerland is abbreviated as “CH,” which is Latin for “Confoederatio Helvetica.”
• Some abbreviations cannot be pronounced according to the rules of the language. “DK” (for Denmark) and “rm” (for room) are not English words or phonemes. Readers must know “or be able to guess” the abbreviations to pronounce them correctly.
• An acronym and a word may have the same spelling but different meanings. For example, “RIP” is an acronym for “rest in peace” and is a word meaning “slash.”
• Some acronyms sound like common words but are spelled differently. The acronym for Synchronized Multimedia Integration Language is SMIL and is pronounced “smile.”
• Some acronyms are pronounced differently than they appear. The acronym for American Automobile Association is “AAA” and is sometimes pronounced “triple A.”

Examples of ways to reduce the confusion that abbreviations may cause:

• Provide the expansion or explanation after the first occurrence of the abbreviation
• Link to its definition
• Provide definitions using the html abbr and acronym elements
• Include a glossary
• Link to a glossary
• Provide a function to search an online dictionary

Content that meets SC 3.1.4 benefits:

• Non-specialists who are not familiar with abbreviations and acronyms that specialists use
• People who are encountering abbreviations and acronyms for the first time
• Second-language learners
• People who have difficulties remembering
• People who rely on screen magnification software (enlarging the text can cause a loss of context)

Reading Level Explained

Clear and simple writing benefits everybody. There are people with reading disabilities (e.g., dyslexia) who are highly educated and possess specialized knowledge. It may be possible to accommodate some of these individuals by making text more readable.

Ways to make text more readable include:

• Simplify the writing. For example, express one idea in each paragraph, replace long or unfamiliar words with more common ones, and use the active voice.
• Provide a text summary that requires less advanced reading ability.
• Illustrate complex ideas with drawings, photographs, maps, symbols, and other resources.

SC 3.1.5 acknowledges that difficult and complex writing is appropriate for certain audiences. The comprehensibility of these texts can be improved by adding content that aids understanding, such as a summary or a chart.

Pronunciation Explained

If the pronunciation of a word is crucial to understanding a passage, indicate how the word should be pronounced.

SC 3.1.6 rarely applies to documents in English and French, where the meaning of words can usually be determined from context. Pronunciation issues are more likely to arise in documents written in other languages, such as Japanese.

A common example in English content, particularly in accessibility resources such as this one, is WCAG (i.e., wuh-kag).

What does “predictability” have to do with being understandable?

When reading web pages, people are not only seeing words, they are also “reading” patterns, such as the layout and organization of the page, the position and order of links, and the colour and shape of headers. These patterns orient readers to what information is where, and they help users focus in on the desired content.

Consistent patterns help readers understand content. Unpredictable patterns increase the cognitive effort that readers need to make sense of information.

Presenting information in a predictable order across a site is good design. It simplifies access for all users, and it may make a crucial difference for people with visual, learning, and cognitive disabilities, who may become disoriented when information or controls appear in different places on different pages.

On Focus Explained

When designing a web page, do not confuse users by unexpectedly changing the context when they navigate or explore.

Examples of context changes include:

• Opening a new window
• Moving focus to another component
• Going to a new page
• Significantly rearranging the content of a page

Conforming to SC 3.2.1 minimizes the chance that users will become confused or disoriented when interacting with a web page:

• Pressing the Tab key, which is normally used to jump from one control to another, should not initiate a search
• Pressing the down arrow key while scrolling through a drop-down menu should not open a new window
• Clicking into an edit field should not open a popup

On Input Explained

When designing online forms, ensure that (a) entering data in a text field, (b) checking or unchecking a checkbox, or (c) selecting or deselecting a radio button does not unexpectedly change the context.

Again, examples of context changes include:

• Opening a new window
• Moving focus to another component
• Going to a new page
• Significantly rearranging the content of a page

SC 3.2.2 helps ensure that users can predict what will happen when interacting with form controls. Context changes may confuse users who cannot easily perceive the page or who are distracted by the changes. A context change is appropriate only when the user is notified that the change will happen in response to an action.

Example: A form contains three fields for entering telephone numbers. The first field contains the three-digit area code. The second field contains the first three digits. The third field contains the last four digits. When a user completes entry of the first field, focus automatically moves to the second field. This is a context change. If this behaviour is described at the beginning of the form, the page conforms to SC 3.2.2. If the behaviour is not described, it does not conform.

Consistent Navigation Explained

When designing a website, keep information that is repeated on every page in the same order.

Content is easier to find when the location of repeated information is predictable. The phrase “same order” does not imply that expanding and contracting navigation menus must be avoided. By adding or removing links between existing navigation links, navigation within a subsection is enabled, and the relative order is maintained.

Conforming to SC 3.2.3 helps users predict the location of the content they are looking for and find content more quickly when they encounter it again. Consistencies in site layout are especially helpful to individuals who rely on visual cues or their spatial memory. People with low vision who use screen magnification software consequently see only a small portion of the screen at one time. These users can take advantage of page boundaries and other cues to quickly locate repeated content.

Using templates to ensure consistency across a site helps web authors meet SC 3.2.3.

Consistent Identification Explained

When designing a website, be consistent when identifying elements that have the same function. For example:

• A newspaper publishes an online edition. Each article spans several web pages. There are four links at the bottom of every page of every article: First Page, Previous Page, Next Page, and Last Page.
• On a company website, an envelope icon indicates that visitors can send a message to an employee. The text alternative always begins with the phrase “Send a message to” followed by the employee’s name.
• On an e-commerce site, there are captions under photographs of products. The caption gives the type of product followed by a short description, e.g., “CD – John Denver’s Greatest Hits,” “Book – Emily Martin – Woman in the Body: A Cultural Analysis of Reproduction.”
• A website has a “Search” feature on some pages and a “Find” feature on others. Both do the same thing. To conform to SC 3.2.4, the web author replaces “Find” with “Search” on every page. The website now uses “Search” consistently throughout.

Change on Request Explained

When designing a website, give users control over context changes, including:

• Automatically advancing slide shows
• Launching new windows
• Spawning popup windows
• Changing keyboard focus
• Automatically submitting forms after selecting a list item

In giving users this control, provide an option to disable context changes.

SC 3.2.5 aims to eliminate confusion caused by unexpected context changes. Unexpected context changes may complicate access for people with motor impairments, people with low vision, people who are blind, and people with certain cognitive disabilities.

Some context changes are not disruptive to everybody or benefit only certain people. For example, context changes are an integral part of slide shows that automatically advance. Content that automatically changes context conforms to SC 3.2.5, but users must have the option to turn the feature on or off.

Other examples of conformance to SC 3.2.5:

• Instead of automatically updating the order form on an e-commerce site, users activate an “Update Now” button to refresh the content.
• A user is automatically redirected from an old page to a new page in a way that he or she never realizes the redirect has occurred.

What is “input assistance?” How does it support understandability?

“Input assistance” is WCAG 2.1 jargon for techniques that help people avoid mistakes, especially when filling out forms. When people do make mistakes, it refers to the techniques that help them recover from errors.

Everyone makes mistakes, but some people with disabilities may be more prone to input errors than people without disabilities. For example, someone with a tremor may press keys by accident. An individual who is blind may have trouble determining which fields are mandatory and which are optional. A person who relies on speech recognition software may produce words that are different than the dictated words.

This guideline seeks to reduce the number of serious errors that users make, increase the likelihood that users will notice their errors, and help users understand what they must do to correct errors.

Error Identification Explained

When designing a website or online form, use text to indicate and describe errors.

It is okay to signal errors with images and colour changes provided there are also text descriptions.

Example: A bank encourages customers to apply for loans online. A customer submits a form with his or her name, address, phone number, email address, and account number. If the customer does not complete the form correctly, the form is re-displayed with an alert — three question marks ??? displayed after the prompt — for all missing or incorrect fields.

In addition, the fields in error are highlighted yellow to make them easier to spot.

SC 3.3.1 is a special benefit to screen reader users. Since screen readers only read text, screen reader users may have trouble understanding non-text error messages.

Labels or Instructions Explained

When designing online forms, help users enter information by providing clear instructions and examples. Conformance to SC 3.3.2 helps users avoid mistakes when their input is required.

When filling out forms, people who use certain assistive technologies are more likely to make mistakes than users without disabilities. Similarly, when recovering from mistakes, these users may have trouble focusing in on and fixing problems.

Instructions and cues that are visually and programmatically connected to form controls help users complete forms successfully the first time. If they do make mistakes, instructions and cues make it easier to find and fix them.

Examples of providing clear cues and instructions:

• Use Given Name instead of Name 1 as the prompt for entering a first name, and Family Name instead of Name 2 for entering a surname.
• Show the required date format for a field: Date (dd-mm-yyyy).
• Place prompts for text fields and combo boxes above or to the left of controls, and place prompts for checkboxes and radio buttons to the right of controls. Doing this “automatically” produces fairly accessible form controls.

Error Suggestion Explained

When designing online forms, provide suggestions for fixing problems when input errors are detected.

This is a more stringent version of SC 3.3.1, which requires that errors be identified. To conform to SC 3.3.3, the errors must not only be identified, but suggestions on how to correct them must be provided.

Explaining how to correct input errors may help people who, due to disability, have difficulties completing and submitting online forms. This includes people with learning disabilities, cognitive disabilities, visual impairments, and motor impairments.

For example, an input field asks users to type a month name. If a user enters “12,” suggestions for correction may include:

• A list of the acceptable values: Choose one of: January, February, March, April, May, June, July, August, September, October, November, December.
• A reworded prompt: Type the month name.
• A conversion of the input data in an interactive popup window: Do you mean “December?”

Error Prevention (Legal, Financial, Data) Explained

When designing websites that allow people to make financial transactions, establish legal commitments, update data, or take tests, you need to help users avoid serious consequences of their mistakes.

The aim of SC 3.3.4 is to give users a second chance if they accidentally input the wrong information or activate the wrong control. In the following examples, the mistakes involve transactions that occur immediately and without the ability to alter them:

• Purchasing non-refundable and non-exchangeable airline tickets online can have serious financial consequences. If a user specifies the wrong travel date, they may wind up with a ticket they cannot use.
• Accidentally deleting or modifying information stored in a travel service database may have dire consequences if the person later needs to access information about a flight.
• While taking an online examination, accidentally clicking the “Submit” button before answering all questions could result in a poor score.

Some people with disabilities are more likely to make mistakes than people without disabilities. People with certain reading disabilities may transpose numbers and letters. People with motor disabilities may hit keys by accident.

To conform to SC 3.3.4, allow users to correct mistakes that could result in serious consequences before they happen. Provide one of the following:

1. A mechanism to reverse actions
2. A way to review and correct information before it is submitted
3. A way to check data for input errors

Help Explained

When designing online forms, provide context-sensitive help when prompts cannot be made sufficiently descriptive.

By providing context-sensitive help, users can learn what to do without losing track of where they are. Context-sensitive help is only required when it is impractical to include full details in the prompts and labels.

It might be appropriate to offer context-sensitive help on an application for an employment program for newcomers to Canada. Applicants are asked to list their college and university degrees. Context-sensitive help reminds applicants that they are not obliged to include the years that degrees were granted.

One way to provide context-sensitive help is to place “Help” links next to questions.

Conforming to SC 3.3.5 helps:

• People with reading, writing, and intellectual disabilities
• Seniors
• Second-language learners
• Anyone who has trouble completing forms
• Anyone who does not know what information to include or exclude when filling out a form

Error Prevention (All) Explained

SC 3.3.6 amplifies SC 3.3.4 (above), which applies only to certain kinds of websites. SC 3.3.6 applies to all websites that require users to submit information.

Give users a second chance if they accidentally input the wrong information or activate the wrong control. To conform to SC 3.3.6, make it possible for users to correct submission errors.

Provide one of the following:

1. A mechanism to reverse an action
2. A way to review and correct information before it is submitted
3. A way to check data for input errors

Example: Reginald is a grade 8 student. Due to an accident, he has little use of his hands. He operates a computer via speech-recognition software instead of a keyboard and mouse. Recognition is excellent but not perfect.

While signing up for an online science forum, Reginald dictates his first name into the “Name” field. The speech recognition software thinks he said “Register,” which causes the mouse to click the “Register” button. Because the forum conforms to SC 3.3.6, the system gives him a chance to add his name before it commits the information to the database.

The Principle Explained

If you open the browser’s View Source feature while viewing a web page, you will find a document that consists of all the words that appear on the page (the content). Thickly interspersed with those words, there are non-words, numbers, and symbols (the code). The code describes how the content should be formatted and what purpose it serves.

During the process of creating a web page, errors tend to creep into the code. In fact, mistakes are almost inevitable. These errors almost always affect the appearance and functionality of the page. The effects may be minor (the formatting is slightly off) or major (the page does not display at all).

Principle 4 is about making websites robust. A robust web page meets the following conditions:

• It displays content as the author intends
• It functions as the author intends
• It is compatible with current and future browsers, web-enabled devices, and assistive technologies

Browsers, web-enabled devices, and assistive technologies do their best to compensate for coding errors. But there are limits to what can be repaired. To conform to Principle 4, web authors are required to avoid specific kinds of coding errors.

Why is compatibility important?

The goal of Guideline 4.1 is to ensure that web pages display correctly and work as the author intends in the following cases:

• All current and future browsers, web-enabled devices, and assistive technologies
• All current and future assistive technologies

Not all users have up-to-date technologies. Compatible web pages also work reasonably well in older and obsolete browsers, web-enabled devices, and assistive technologies. Obviously, not all features available on modern websites are compatible with older technologies.

Guideline 4.1 requires web authors to confirm the following:

1. Ensure that code does not “break” or otherwise impede assistive technologies
2. Expose information in standard ways so that assistive technologies can recognize and interact with content

Web technologies change quickly, and assistive technology developers are constantly playing catch-up. When web authors code according to specification, they maximize the chances that assistive technologies will work seamlessly with present and future technologies.

Parsing Explained

Ensure web pages conform to all markup language specifications.

Conforming to SC 4.1.1 ensures that browsers, web-enabled devices, and assistive technologies interpret, parse, and display content accurately. Improper markup may cause content to display differently in different browsers or devices, display incorrectly, not display at all, or be inaccessible to assistive technologies.

An easy way to test SC 4.1.1 is to use a validation tool, such as the W3C Markup Validation Service. A good validator will detect incomplete start and end tags, missing quotation marks, problems with attributes, duplicate IDs, and more.

Name, Role, Value Explained

Ensure that assistive technologies can gather information about, activate, set, and update user-interface controls.

SC 4.1.2 does not apply when web authors use standard controls according to specification. When web authors create custom controls or code (or script) interface elements, measures must be taken to ensure that the controls and assistive technologies are able to communicate.

Use a programmatically determinable name for all user interface components. Providing the role, state, and value of all user interface components enables compatibility with assistive technologies.

WAI-ARIA, which is covered on the next page, and in another resource in this series, is typically used to define roles, states, and properties (and their values).

Status Messages Explained

SC 4.1.3 helps ensure that assistive technology users, particularly people who are blind, receive feedback after completing an action. For typical website visitors, feedback such as confirmation, error, or warning messages are presented to them on the screen, often updating the content of the page without reloading it. They are usually visually recognizable. For screen reader users, this dynamically added content will typically go unnoticed if it has not been created in a way that screen readers are able to identify.

Fortunately, with the introduction of WAI-ARIA, providing feedback to screen readers is relatively simple. It’s as uncomplicated as adding a type of live region role that announces itself to a screen reader when the content of the associated element changes. There are a number of live region roles that can be added to feedback messages to ensure they are announced, such as:

• role="alert"
• role="status"
• role="log"

After submitting a registration form, a feedback message may appear on the page after it has been submitted. Having the content of the feedback automatically read when the page loads ensures the screen reader user gets the message and is not left wondering whether the action just completed was successful or not. In this case, a status message can be presented to the user, as in the following feedback message:

<div role="status">
Thank you for submitting your registration. 
You will be contacted shortly.
</div>

An error message might be injected into a form next to a required email field, after leaving the email field empty. The page does not reload, but instead a highlighted message is inserted next to the email field using JavaScript. The message reads automatically when it appears.

<span role="alert">
Email address is required
</span>

An important and recent addition to the family of accessibility standards created by the W3C is WAI-ARIA. This acronym stands for “Web Accessibility Initiative,” the W3C subgroup that created the standard, and “Accessible Rich Internet Applications,” the name of the standard itself. Here we touch on WAI-ARIA without going into much detail. It is primarily aimed at developers who create custom web applications and widgets using non-standard HTML. For example, a developer might create a checkbox out of an HTML <div>element. WAI-ARIA allows a developer to assign checkbox semantics to that <div>, like its role (i.e., role="checkbox") and its state (i.e., aria-checked="true" or aria-checked="false"), so when it is encountered by an assistive technology, the technology recognizes that <div> as a checkbox.