All non-text content that is presented to the user has a text alternative that serves the equivalent purpose.

Any information conveyed by means other than text needs to be provided in text as well. The text should provide equivalent information. Examples of non-text content are images, graphs, media, animations, CAPTCHA, and audio alerts.

Short and long text alternatives can be used as needed to convey the equivalent of the non-text content. The most common short text alternative is the use of ALT text attributes for images. Examples of long alternatives include descriptions for graphs, charts, or complex images.

Exceptions: There are situations where providing a text equivalent is either not possible or not desirable. Exceptions include controls, inputs, tests, and CAPTCHA. Non-text content that is primarily intended to create a specific sensory experience, then text alternatives should at least provide a descriptive identification of the non-text content. Content that is decorative, used to provide formatting, or visually hidden does not require a text alternative.

Refer to Understanding 1.1.1 Non-text Content for more information on exceptions, intent, benefits, and techniques (external link to W3C).

For prerecorded audio-only or video-only media, an alternative provides equivalent information.

This requirement ensures that when information is presented in a playable medium, the user has an alternative way of consuming it.

For audio-only information, such as a recording of a speech, provide a transcript. A transcript is also the preferred alternative for video-only information, such as a soundless demonstration video. This is because a transcript – which in the case of a video describes all important visual information — can be presented to the user in many different ways by assistive technology. The alternative for video-only material could also be provided as an audio track.

Exception: This requirement does not apply when the audio-only or video-only content is actually the media alternative for text content, and is labeled as such. This alternative equivalent should provide no more information than is available in the text content.

Refer to Understanding 1.2.1 Audio-only and Video-only (Prerecorded) for more information on exceptions, intent, benefits, and techniques (external link to W3C).

Captions are provided for all prerecorded audio content in synchronized media.

This requirement ensures that captions are provided as text equivalent for audio content. They are synchronized to appear on screen with the relevant audio information, such as dialogue, music, and sound effects.

Captions are of the following two types:

The source material for captions can also serve as a transcript or be transformed by assistive technology into other formats.

Exception: Captions are not needed when the media itself is an alternate presentation of text information. For example, if information on a page is accompanied by a synchronized media presentation that presents no more information than is already presented in text, but is easier for people with cognitive, language, or learning disabilities to understand, then the media would not need to be captioned. Such media should be labelled as a media alternative.

Refer to Understanding 1.2.2 Captions (Prerecorded) for more information on exceptions, intent, benefits, and techniques (external link to W3C).

An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media.

This requirement ensures that people who are blind or visually impaired have access to the visual information that is provided in multimedia. Anything that has a play button is typically “time-based media,” which includes anything that has duration and plays to the user over time. Video, audio, and animation are all time-based media.

The visual information is described using one of the following:

Exception: When the media is a media alternative for text and is clearly labeled as such.

Note: This requirement overlaps with requirement 1.2.5: Audio Description (Prerecorded). If an audio description is used to meet 1.2.3, then 1.2.5 is also met.

Refer to Understanding 1.2.3 Audio Description or Media Alternative (Prerecorded) for more information on exceptions, intent, benefits, and techniques (external link to W3C).

Captions are provided for all live audio content in synchronized media.

This requirement ensures people who are deaf or hearing-impaired, work in noisy environments, or turn off sounds to avoid disturbing others have access to the auditory information in real-time (live) presentations. Live captions do this by identifying who is speaking, displaying the dialogue and noting non-speech information conveyed through sound, such as sound effects, music, laughter, and location as it occurs.

Live captions must be synchronized with the presentation and be as accurate as possible, typically accomplished through Communication Access Real-time Translation (CART) real-time captioning.

As an added benefit, captioning live presentation can often produce a transcript that everyone who missed the live presentation can use for review.

This requirement also allows for equivalent facilitation when open or closed captions cannot be provided within the live video content via a separate communication channel, such as a third-party transcription service or by having meeting participants use a group chat to transcribe the discussion.

Refer to Understanding 1.2.4 Captions (Live) for more information on exceptions, intent, benefits, and techniques (external link to W3C).

Audio description is provided for all prerecorded video content in synchronized media.

This requirement ensures that users who cannot see have access to the visual information in a media presentation through an audio description, also sometimes called video descriptions or descriptive narration, to augment the audio portion of a presentation. This audio description is synchronized with the content; during existing pauses in the main soundtrack, the user hears an audio description of actions, characters, scene changes, and on-screen text that are important to understand the presentation. Secondary or alternate audio tracks are commonly used for this purpose.

Note: This requirement overlaps with requirement 1.2.3: Audio Description or Media Alternative (Prerecorded). Compliance requirements for 1.2.3 allow either an audio description or a text alternative. However, this requirement, 1.2.5, requires an audio description to comply.

Exception: If all important visual information is already announced in the audio track, or there is no important information in the video track, such as a “talking head” where a person is talking in front of an unchanging background, no audio description is necessary.

Refer to Understanding 1.2.5 Audio Description (Prerecorded) for more information on exceptions, intent, benefits, and techniques (external link to W3C).

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

This requirement ensures that Assistive Technologies (AT) can programmatically gather information, meaningful structure, and relationships that are displayed visually so that it can be rendered to the AT user. ATs such as screen readers and magnifiers speak the content or change the presentation layout for the user’s needs.

Each visual cue must be implemented in the standard way supported by the platform or technology. Common visual cues to the semantics of the content on the Web are supported programmatically through markup, and include headings, labels, forms, tables with associated row and column headers, images with & without captions, lists, emphasis such as bold and italics, hyperlinks and paragraphs.

In cases where there is no support for programmatic identification of the content, an alternative must be provided in the text. For example where identification is required, but no markup is available for emphasis, additional characters such as a double asterisk (**) may be used.

Note: The requirement is not limited only to visual cues, although they are the most common. For example, if audio cues are used to indicate required content, markup or textual identification must be additionally provided.

Refer to Understanding 1.3.1 Info and Relationships for more information on exceptions, intent, benefits, and techniques (external link to W3C).

When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.

This requirement ensures if the visual order of reading information on the page is important to its meaning, then the sequence, such as reading order, of the information is available programmatically.

Teams need to do two things to achieve the goal of this requirement:

An example of meaningful sequence, such as reading order, is text in a two-column article. A user must read the lines of text in the first column sequentially, then move to the second column and do the same. If an assistive technology reads across both columns (e.g., reads the first line of the cell in the first cell and then reads the first line of the cell in the second column) before proceeding to the next line, the user will obviously not understand the meaning. Other potential failures of meaningful sequence can occur when using CSS, layout tables, or white space to position content.

It is important not to confuse the reading order with the navigation order. The ability to navigate (i.e., move by keyboard between interactive controls) in a way that preserves meaning is covered by 2.4.3 Focus Order. Meaningful Sequence is concerned solely with the reading order, and so cannot normally be tested without assistive technology. Screen readers render content in a serialized manner.

Note: Sequence is not important for some content. For example, it does not normally affect meaning whether side navigation is read before or after the main content. So while matching the visual and reading order is a way to ensure this requirement is met, a difference in visual order and reading order is not a failure where the sequence does not affect the meaning.

Refer to Understanding 1.3.2 Meaningful Sequence for more information on exceptions, intent, benefits, and techniques (external link to W3C).

Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound.

This requirement ensures instructions to the user that use sensory characteristics such as shape or location to provide context are not the only means of conveying information.

When elements are described using visual cues such as shape, size, or physical location (e.g., “select the button on the right”), it can make it easier for a sighted user and some people who have cognitive disabilities to locate the elements. But, someone with a vision disability may not be able to perceive those visual cues. The element must also be described in another non-visual way, such as by its label (e.g., “select the Delete button on the right”).

It is important to understand that this requirement is entirely focused on referencing sensory characteristics in instructions. The instructions need to be understandable even if the content is reflowed or transformed.
For example, a screen display without images, or the display is reflowed on a mobile device changing the content positioning.

The simplest way to prevent failures of sensory characteristics is to always have a visible text label and reference that label in the instructions.

Note: Use of color, also a sensory characteristic, has a separate requirement, see 1.4.1 Use of Color, that governs its use as not being the only means of distinguishing content. That applies to any reliance on the use of color, and not just references to color in instructions.

Refer to Understanding 1.3.3 Sensory Characteristics for more information on exceptions, intent, benefits, and techniques (external link to W3C).

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape.

This requirement ensures that content does not get locked to either portrait or landscape presentation mode.

The key intended beneficiaries of this requirement are users unable to modify the orientation of devices. If designers force content to only display in portrait (or landscape) mode, it deprives users of the option to consume the content in the perspective that they need. If a user has a device affixed to a wheelchair or is otherwise unable to reorient the device to match the design-imposed orientation, the content can become unusable.

Note: This requirement bans developer-controlled techniques to limit the display orientation of an application on the device. Where a user activates any system-level orientation lock, applications will be subjected to this system-level setting without any action required on the developer’s part. System or hardware locks are user-imposed preferences and are not contradictory to this requirement.

Essential Exception: This requirement does not apply where a specific display orientation is essential. WCAG defines essential as: ”if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform.” Such a situation will be rare; most applications should be able to be usable when displayed in either orientation although one orientation may be less optimal.

An example of an application whose orientation would be considered essential is a piano keyboard emulator. Since such an app mimics a physical piano keyboard, which is heavily biased to horizontal operation, the few keys available in a portrait orientation would make the application’s intended function unusable.

Refer to Understanding 1.3.4 Orientation for more information on exceptions, intent, benefits, and techniques (external link to W3C).

The purpose of each input field that collects information about the user can be programmatically determined when the field serves a common purpose.

This requirement ensures that meaning of common inputs is available via technology.

The key beneficiaries of this requirement are users with some cognitive disabilities. In situations where users are asked to provide information about themselves, if the purpose of each input can be programmatically determined, then the prompts may be customized or auto-filled through Assistive Technologies and browsers to make them more understandable to a specific user, and potentially easier to complete.

Not all inputs must meet this. The requirement is restricted to common ones identified in WCAG’s list of Input Purposes for User Interface Components, such as name, address and contact information. As well, this only needs to be met when a technology can programmatically indicate the meaning. The most common usage will be employing auto-fill attributes.

Refer to Understanding 1.3.5 Identify Input Purpose for more information on exceptions, intent, benefits, and techniques (external link to W3C).

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

This requirement ensure that Color is not the only visual means of conveying information, because many users have deficiencies in color perception and cannot identify or distinguish colors. Another non-color method for making the information available visually is required, such as with pattern, images, text, or text formatting.

For example, if text in an input field is colored red to show it is invalid, a user who cannot distinguish the red will not be able to detect the problem. If a warning symbol is added beside the text box then the user can locate it.

This requirement is not meant to discourage the effective use of color or color coding, but to require redundant visual indication.

Exception: This requirement does not apply when color is used to indicate “visited” links. This requirement also does not apply when color is used to indicate the location of a mouseover focus on a navigation bar or within an application.

Refer to Understanding 1.4.1 Use of color for more information on exceptions, intent, benefits, and techniques (external link to W3C).

If any audio plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.

Individuals who use screen reading software can find it hard to hear the speech output if there is other audio playing at the same time. This difficulty is exacerbated when the screen reader’s speech output is software-based (as most are today) and is controlled via the same volume control as the auto-playing sound. Therefore, this requirement ensure the user is able to turn off or adjust the volume of the background sound independently from the system volume control.

Automatically starting sounds is highly discouraged, especially those that last for more than 3 seconds, as the sound interferes with the ability for a screen reader user to hear navigational cues to find the sound adjustment controls. It is better to have any audio content started through a user action.

Note: Having control of the volume includes the ability to silence the sound.

Refer to Understanding 1.4.2 Audio control for more information on exceptions, intent, benefits, and techniques (external link to W3C).

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, with a 3:1 ratio for large-scale text.

This requirement ensures enough contrast is provided between text and its background to enable users with moderately low vision to read the text without contrast-enhancing technology. (Users requiring more contrast will often use an assistive technology or platform feature such as Windows High Contrast mode.)

WCAG 2.0 makes a distinction between “large” text and small or body text.
Large text, which is defined as text that is at least 18 point or at least 14 point when bold, has a contrast requirement of 3 to 1.
Body text (less than 18 point and less than 14 point when bold) has a contrast requirement of 4.5 to 1.

This requirement also applies to images of text that are intended to be understood as text. Refer to requirement 1.4.5 Images of text. However, this contrast requirement does not apply to decorative text which conveys no meaning, or text that is part of a logo or brand name.

This requirement specifically addresses text contrast, WCAG 2.0 recommends sufficient color contrast for data presented in charts and graphs as well. WCAG 2.1 introduced a new specific requirement for 1.4.11 Non-text contrast.

Incidental Exception: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

Logotypes Exception: Text that is part of a logo or brand name has no minimum contrast requirement.

Refer to Understanding 1.4.3 Contrast (minimum) for more information on exceptions, intent, benefits, and techniques (external link to W3C).

Text can be resized without assistive technology up to 200 percent without loss of content or functionality.

This requirement ensures visually rendered text can be scaled successfully so more users are able to read the information without requiring the use of assistive technology such as a screen magnifier. This increase in size can be achieved either by zooming all content OR by increasing just the text size. In both cases, this resizing is normally achieved by the user agent (i.e., web browser or view controller). The author’s responsibility is to create content that does not prevent the user agent from scaling the content effectively.

To meet this requirement, confirm that scaling works and ensure there are no visual or functional issues as a result of the increase, such as:

In cases where content fails to respond to the platform’s scaling features authors must provide a way of resizing text.

Note: For some interactive content, such as editable cells in a table, truncation is acceptable if the component’s full content is available on focus or after user activation, and an indication that this information can be accessed is provided to the user in some way besides the fact that it is truncated.

Exception: Media captions and images of text are excluded from this requirement. Resizing the closed captions is normally a feature of the player or platform, not the author’s responsibility. Images of text, which are covered under 1.4.5 Images of text, do not normally scale well.

Refer to Understanding 1.4.4 Resize text for more information on exceptions, intent, benefits, and techniques (external link to W3C).

If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text.

This requirement ensure that when technology is capable of achieving a desired visual presentation, designers must use text — not images of text — to allow people with disabilities to adjust the text presentation per their personal preferences. For example, a user may require a particular text size, font family or text/background color.

The definition of image of text contains the note: “This does not include text that is part of a picture that contains significant other visual content.” Examples of such pictures include graphs, screenshots, and diagrams that visually convey important information beyond text only.

Customizable Exception: This requirement does not apply to images of text that can be visually customized to the user’s requirements.

Essential Exception: This requirement does not apply when a particular presentation of text is essential to the information being conveyed. For example, logotypes (text that is part of a logo or brand name) are considered essential.

Refer to Understanding 1.4.5 Images of text for more information on exceptions, intent, benefits, and techniques (external link to W3C).

Content can reflow without loss of information or functionality, and without requiring scrolling in two dimensions.

This requirement ensure content can be enlarged without requiring horizontal scrolling.

The key intended beneficiaries of Reflow are low-vision users who want to be able to enlarge text yet still see the content in their viewport without scrolling across the page.

With Reflow, width constraints are placed on horizontally read languages such as English, while height constraints are placed on vertically read languages such as Chinese. The constraints are as follows:

“Scrolling in two dimensions” refers to forcing the user to scroll in both the X dimension (left and right) as well as the Y dimension (up and down) in order to view the content. Such scrolling makes it difficult to keep your place when relocating from the end of a long line to the start of the next line, especially when text is magnified. Since IBM mainly produces horizontally read content, we have simplified the objective of this guidance to say “horizontal scrolling” which is the scrolling to avoid in most written languages, including English.

This requirement complements the existing WCAG 2.0 1.4.4 Resize text, which requires text to be able to be doubled in size. Resize does not require text to reflow, but merely to enlarge. When combined with this requirement 1.4.10 Reflow, it means that the starting size of text must be able to resized to 200% while still having the ability to reflow so that horizontal scrolling is not needed.

Authors can test for reflow on a desktop browser with typical 1280x1024 pixel dimensions by zooming the content to 400%. If the content expands without requiring scrolling in both dimensions, this is mathematically the same as reducing the window to 320x256 pixels.

Exception: Parts of the content “which require two-dimensional layout for usage or meaning” do not need to meet this requirement. Two-dimensional content includes maps, videos and images, which generally rely on a maintained aspect ratio to be intelligible. As well, even relatively simple data tables may not fit within the confines of a reduced viewport and thus data tables are also excepted. It is important to note that there are advisory techniques that allow images to be displayed and tabular information to be transformed to fit within a constrained viewport. Where possible, content authors are encouraged to adopt such techniques.

Refer to Understanding 1.4.10 Reflow for more information on exceptions, intent, benefits, and techniques (external link to W3C).

The parts of graphical objects required to understand the content, and the visual information required to identify UI components and states, have a contrast ratio of at least 3:1 against adjacent colors.

This requirement ensure important visual information such as graphics and icons meets the same minimum contrast that is required for larger text which is a 3:1 contrast ratio against adjacent colors for two types of non-text content:

The key intended beneficiaries of this requirement are low-vision users who need to perceive active UI components and their states, as well as meaningful graphics.

For User interface components, the visual information that identifies a component as well as its state needs to meet the contrast ratio. This typically means that the outer edge of a component will need to be distinguishable from the background, as will any indicators for focus, selection or other states

For every graphical object required for understanding the content, whether it be a UI component or a non-interactive object, the parts of the graphic must meet a 3:1 contrast with the neighboring information. The WCAG Understanding document provides a range of examples for everything from monochrome icons to pie charts with different colored wedges. Considerations for such things as gradients and infographics are also discussed.

Unmodified Exception: UI components whose appearance is entirely determined by the user agent (e.g., stock HTML radio buttons and checkboxes) do not need to meet the 3:1 contrast if they are not modified by authors. This exception is intended to prevent making authors responsible for any shortcomings of a particular user agent default implementation.

Inactive Exception: UI Components that are not active (i.e., disabled) are not required to meet a minimum contrast. This matches the exception for text that is “part of an inactive user interface component” in 1.4.3 Contrast (Minimum).

Essential Exception: If a particular presentation of a graphical object is essential to the information being conveyed, it also does not need to meet the 3:1 contrast requirement. Examples of such essential graphics may be logos and flags, as well as reproductions of physical objects, whether drawn or photographed.

Refer to Understanding 1.4.11 Non-text contrast for more information on exceptions, intent, benefits, and techniques (external link to W3C).

No loss of content or functionality occurs when users change letter, word and paragraph spacing, as well as line height.

This requirement ensure users can adjust text spacing to make it easier to read.

Authors should ensure content can be transformed (such as through user style sheets) to attain all of the following specific requirements for a number of different text transformations without loss of content or functionality:

Language exception: Where the communication language used in the content, or the script in which the language is written, do not make use of one or more of these text style properties, that language need only conform using the properties that exist.

Technology exception: This requirement is restricted to content implemented using markup languages that support text styling properties. Technologies that do not use markup, such as PDF, are excluded.

IBM has simplified the normative language of this requirement. Refer to Understanding 1.4.13 Text Spacing for more information on exceptions, intent, benefits, and techniques (external link to W3C).

Where hover or focus actions cause additional content to become visible and hidden, the additional content is dismissible, hoverable and persistent.

This requirement ensure when receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:

There are two main objectives achieved by these requirements. The first (covered by hoverable) is that low vision users, particularly those who rely on magnification to enlarge the content, are able to move their pointer toward the newly revealed content so they can read it. Magnification often results in only part of the new information being visible in the viewport until the user reorients the pointer. If the new content disappears the moment the user moves the mouse off the triggering element, or after some arbitrary time period, it will be difficult or impossible for some users to read it.

The second objective is that blind users and others who depend on the keyboard for operation, will be able to both trigger and dismiss the new content without disrupting their work. If the new information obscures other content, the user should be able to dismiss it easily without navigating — unless the new content is a warning about an error. The persistent requirement ensures that the information will remain present until the user has reviewed it.

Exception: WCAG allows situations where “The visual presentation of the additional content is controlled by the user agent and is not modified by the author.” This primarily covers use of the HTML <title>attribute. Browsers determine the display position and timing of title text, so it is not developer-controlled. However, title as the means of providing additional content is discouraged by many accessibility advocates.

Refer to Understanding 1.4.13 Content on hover or focus for more information on exceptions, intent, benefits, and techniques (external link to W3C).

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.

This requirement ensures that content can be navigated with a keyboard or keyboard interface. When interactive content is operated using a keyboard, it is accessible to vision impaired people who cannot use devices requiring hand-eye coordination (e.g., a mouse) and by people who use alternative keyboards or input devices that act as keyboard emulators. Keyboard emulators include speech input, sip and puff devices, on-screen keyboards, scanning software, and a variety of assistive technologies. This requirement does not forbid or discourage providing mouse input or other input methods in addition to keyboard operation.

The requirement 502.2.2 No disruption of accessibility features addresses the software requirement to not disrupt or override platform accessibility options, including the keyboard commands to control these options. For web applications, the need to document non-standard keyboard operation is covered under 602.2 Accessibility and compatibility features.

Refer to Understanding 2.1.1 Keyboard for more information on exceptions, intent, benefits, and techniques (external link to W3C).

If keyboard focus can be moved to a component of the page/application using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

The intent of this requirement is to ensure the keyboard focus does not get “trapped” within subsections of content, leaving keyboard-only users no way to return to other content.

Note: Since any content that does not meet this requirement can interfere with a user’s ability to use the whole page/application, all content, whether it is used to meet other requirements or not, must meet this requirement. WCAG Conformance Requirement 5 Non-interference states that users must not be blocked from reaching all parts of the content, regardless of technology limitations.

Refer to Understanding 2.1.2 No keyboard trap for more information on exceptions, intent, benefits, and techniques (external link to W3C).

If a keyboard shortcut is implemented using only letter, punctuation, number or symbol characters, then the shortcut can be turned off, remapped or activated only on focus.

This requirement ensures custom shortcuts are not accidentally triggered.

The key intended beneficiaries are users primarily operating content via speech or keyboard. Such users may inadvertently activate a shortcut key in the process of navigating or updating content. This problem occurs with custom shortcuts that do not include modifier keys, such as Ctrl.

The easiest and best solution is to ensure that all shortcut keys are a combination of character and modifier keys. However when not possible, any of the following are acceptable ways of meeting this requirement:

Refer to Understanding 2.1.4 Character key shortcuts for more information on exceptions, intent, benefits, and techniques (external link to W3C).

For each time limit that is set by the content, the user can turn off, adjust, or extend the limit.

This requirement ensures users with disabilities have adequate time to interact with content when possible. People with disabilities may require additional time to read content or perform functions such as completing online forms. When faced with time-dependent functions, users with low vision, dexterity impairments, or cognitive limitations may have difficulty performing the required action before reaching a time limit, making the service potentially inaccessible to them.

A time limit includes any process that occurs (without user initiation) after a set amount of time or on a periodic basis. Examples include partial or full updates of content such as page refreshes, changes to content, or the expiration of a “window of opportunity” for user input requests. Time limits also include content that is advancing or updating at a rate beyond the user’s ability to read, understand, and/or interact, such as animated, moving, or scrolling content.

By designing functions that are not time-dependent, you can help people with disabilities complete these functions and make it easier for all users. When a time limit is required, one of the following options must be provided, in order of preference:

Real-time Exception: This requirement does not apply if the time limit is a required part of a real-time event, such as an auction, and no alternative to the time limit is possible.

Essential Exception: This requirement does not apply if the time limit is essential and extending it would invalidate the activity.

20 Hour Exception: This requirement does not apply if the time limit is longer than 20 hours.

Refer to Understanding 2.2.1 Timing adjustable for more information on exceptions, intent, benefits, and techniques (external link to W3C).

For moving, blinking, scrolling, or auto-updating information, the user can pause, stop or hide it, or control the update frequency.

This requirement ensures distractions to users are avoided during their interaction with content. There are two considerations:

”Moving, blinking and scrolling” refers to visible content that conveys a sense of motion. Common examples include auto-playing videos, synchronized media presentations, animations, real-time games, and scrolling stock tickers.

”Auto-updating” refers to visible content that updates or disappears based on a preset time interval. Common automatically updating content includes audio, weather information, news, stock price updates, and auto-advancing presentations and messages.

For all these types of content, the user needs the ability to pause, stop, or hide the content. In addition, for auto-updating, designers have the option of providing the user with a means to control the frequency of updates.

Content that moves or updates automatically can be a barrier to anyone who has trouble reading stationary text quickly, anyone who has trouble tracking moving objects, and screen readers which may not be able to render all of the content (text) before it gets updated; the user can lose their place if the updates happen in the middle of reading the content.

Moving content can also be a severe distraction for some people. Certain groups, particularly those with attention deficit disorders, find blinking content distracting and have difficulty concentrating on other content. The five-second limit is long enough to get a user’s attention, but short enough for a user to wait out the distraction before reading the page.

The requirement Understanding 2.3.3 Animation from Interactions applies when a user’s interaction initiates animation. In contrast this requirement, 2.2.2 Pause, stop, hide, applies when the web page or application initiates animation.

Note 1: For requirements related to flickering or flashing content, see Guideline 2.3 Seizures and physical reactions.

Note 2: Since any content that does not meet this requirement can interfere with a user’s ability to use the whole page/application, all content, whether it is used to meet other requirements or not, must meet this requirement. WCAG Conformance Requirement 5 Non-interference states that users must not be blocked from reaching all parts of the content, regardless of technology limitations.

Essential Exception: If the movement, blinking, scrolling or auto-updating is part of an activity where it is essential, this requirement does not apply. An animation, such as loading… that occurs as part of a preload phase or similar situation can be considered essential if any user interaction cannot occur during that phase and if not indicating progress could confuse users or cause them to think that content was frozen or broken.

Refer to the definition of blinking.

Refer to Understanding 2.2.2 Pause, stop, hide for more information on exceptions, intent, benefits, and techniques (external link to W3C).

Content does not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.

This requirement ensures users can access content without inducing seizures due to photosensitivity.

For people with photosensitive seizure disorders, sizeable content that flashes at certain frequencies for more than a few flashes can trigger a seizure. Because people are more sensitive to red flashing than to other colors, you must perform a special test for saturated red flashing. This requirement is based on the broadcasting industry guidelines, but they have been adapted for computer monitors, which allow content to be viewed from a short distance using a larger angle of vision.

Note: Since any content that does not meet this requirement can interfere with a user’s ability to use the whole page/application, all content, whether it is used to meet other requirements or not, must meet this requirement. See WCAG Conformance Requirement 5 Non-interference (external link to W3C).

Refer to Understanding 2.3.1 Three flashes or below threshold for more information on exceptions, intent, benefits, and techniques (external link to W3C).

A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

People with disabilities often navigate content without the use of a mouse. This makes navigating the content more tedious when there is repeating information, such as links and search inputs that are in the tab order.

When repeated interactive content is organized into logical groups and regions, a means is provided for more efficient navigation. Navigation for screen reader users becomes much more efficient when WAI-ARIA landmarks (regions) are implemented. Screen reader users may navigate sequentially through landmarks using a hotkey sequence. Alternatively, a dialog containing a list of landmarks may be invoked from which users can jump directly. Examples of available landmarks (regions) include: banner/header, sitelookup/search, content/main, footer/contentinfo, and navigation.

Notes:

Refer to Understanding 2.4.1 Bypass blocks for more information on exceptions, intent, benefits, and techniques (external link to W3C).

Web pages, non-web documents, and software have titles that describe topic or purpose.

This requirement ensures descriptive titles are provided. Descriptive titles help all users orient themselves when navigating through content or when moving between multiple applications or documents.

Screen readers announce titles before other content. If titles are missing, screen reader users must explore more content to determine the purpose. Conversely, if titles are identical for multiple pages, or repeat the same information before providing unique information, a user will hear repetitive content before understanding context.

The title should:

If the page or document belongs to a collection, the title should:

Note: While the European standard EN 301 539, clause 11.2.4.2 Void does not require 2.4.2 Page Title for non-web software, it is still required by US 508.

Refer to Understanding 2.4.2 Page titled for more information on exceptions, intent, benefits, and techniques (external link to W3C).

If content can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

This requirement ensures that when users navigate sequentially through content, they encounter information in an order that is consistent with the meaning of the content and can be operated from the keyboard.

When content relies on sequential navigation for the user to understand it, it is essential for the focus order to match the visual flow of the content, such as from left to right and top to bottom. If there is more than one order that preserves meaning and operability, such as navigating cells in a table by row or by column, either order may satisfy the requirement.

Refer to Understanding 2.4.3 Focus order for more information on exceptions, intent, benefits, and techniques (external link to W3C).

The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context.

This requirement ensures the purpose of a link is clear and easy to understand for all users. Whenever possible, the text of the link should describe its purpose without needing additional context.

Some assistive technologies provide a list of all links on the page to its user. If the text of the links do not clearly give the purpose, or if multiple links with the same name point to different targets (e.g., “read more”), users are forced to locate the link on the page and search surrounding information for context.

When it is not possible to provide descriptive link text, the content that provides the context must be in the same sentence or be associated with the link programmatically. Ideally, this descriptive content should precede the link, so that users who read content sequentially encounter the link context before the link.

Exception: An exception to this requirement is where the purpose of a link would be ambiguous to all users in general. For example, a game may create suspense for all users by presenting links with no indication of what the links will do until activated. However, whatever context is available must be programmatically associated with the link.

Note: In non-web software, a “link” is any non-UI-control text string or image that behaves like a hypertext link.
See Applying WCAG to Non-Web Information and Communications Technologies (external link to WCAG2ICT).

Refer to Understanding 2.4.4 Link purpose (in context) for more information on exceptions, intent, benefits, and techniques (external link to W3C).

More than one way is available to locate an item in a set of items, whether it is a Web page within a set of Web pages, a document within a set of non-web documents, or a program within a set of software programs except where the item is the result of, or a step in, a process.

This requirement ensures users are able to locate information in a way that best suits their needs. With access to multiple ways of locating information, users may need one way over another. For example, a user may need to use a document’s search function to locate specific information rather than scrolling through a table of contents. Alternatively, a user who needs to understand the content’s structure will find a table of contents or site map more useful.

Note: Consistent with Applying WCAG to Non-Web Information and Communications Technologies (external link to WCAG2ICT), an individual document or software program (not in a set) should mark this requirement N/A because it applies only to things that appear in a set. Refer to the definitions of set of documents and set of software programs to determine when a group of documents or software is considered a set. These definitions require that every item in the set be independently reachable, and not include a “step in a process” which cannot be reached in any other way.

Refer to Understanding 2.4.5 Multiple ways for more information on exceptions, intent, benefits, and techniques (external link to W3C).

Headings and labels describe topic or purpose.

This requirement ensures When headings and labels are present, they describe the topic or purpose of the item(s) with which they are associated. Descriptive headings and labels:

Note 1: Headings are used to describe sections of content while labels are used with controls. In some cases, it may be unclear whether a piece of static text should be a heading or a label. But whether treated as a label or a heading, the requirement is the same. 

Note 2: This requirement does not mean that headings and labels must exist in all types of content. It requires that if headings or labels are provided, they must be descriptive. When  labeling is ”required” is covered in 3.3.2 Labels or Instructions. Also note that headings and labels must meet 1.3.1 Info and Relationships.

Refer to Understanding 2.4.6 Headings and labels for more information on exceptions, intent, benefits, and techniques (external link to W3C).

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

This requirement ensures that the keyboard focus indicator can be visually located so that a person knows which element has the keyboard focus. All focus indicators should be visible and distinguishable.

Refer to Understanding 2.4.7 Focus visible for more information on status, intent, benefits, and techniques (external link to W3C).

All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture.

This requirement ensures users can operate interactive content with a simple action.

The key intended beneficiaries are users with some physical disabilities, who may lack the ability to carry out complex gestures on mobile devices or other touchscreens. When designers and developers create a custom gesture, they need to ensure it is a simple action using a single contact point, or that there is a simple action to achieve the same result.

An example of a multipoint gesture is a two-finger pinch to zoom. An example of a path-based gesture is a swipe-up since the direction of the swipe — it’s path — determines the interpreted action.

Note: This requirement does not apply to operating system and browser gestures, which are not under the developer’s control. Most devices have platform accessibility features which offer alternatives for device-based complex gestures.

Essential Exception: Multipoint or patterned gestures such as those that require the drawing of a specific shape are allowed if that is the only way to achieve something, such as a user’s signature. Note that in many cases a signature may not be essential if there are other acceptable ways to, for instance, validate a user’s identify or capture their consent.

Refer to Understanding 2.5.1 Pointer Gestures for more information on exceptions, intent, benefits, and techniques (external link to W3C).

For functionality that can be operated using a single pointer, completion of the function is on the up-event with an ability to abort, undo, or reverse the outcome.

The intent of this requirement is to reduce accidental activation of controls and the effects by making their operation consistent.

This requirement benefits a range of users with cognitive, physical, or visual disabilities. Designers and developers should help ensure that pointer operation is predictable and consistent. To prevent accidental or erroneous pointer input, ensure at least one of the following is true:

If users mistakenly activate a mouse button or gesture, or if they have poor fine motor control and click the wrong thing, they can cause unintended consequences.

If no down-event causes execution, a user who mistakenly clicks a control does not immediately activate the control. Instead, activation occurs on the up-event when the user releases the control such as by taking their finger off the mouse button or the touchscreen. This provides users with an opportunity to nullify their action, for instance by moving the pointer away from the control. Moving the pointer away from the target while the mouse button is still depressed, then releasing the pointer when it is no longer over any control, is a built-in example of the ability to abort on the up-event.

A drag-and-drop operation that completes on the up-event and then asks for confirmation to move the object is an example of an undo function. A help icon that displays a message when pressed (on the down-event) that then disappears when it is no longer pressed (on the up-event) is an example of up reversal. Finally, a piano keyboard emulator is an example of a function that is down-event essential. A physical piano plays a note when the piano key is pressed, and any emulator must also do so to approximate the experience.

Refer to Understanding 2.5.2 Pointer cancellation for more information on exceptions, intent, benefits, and techniques (external link to W3C).

For user interface components with labels that include text or images of text, the accessible name contains the text that is presented visually.

The requirement ensures that a component’s visible text label is the same as (or included in) the accessible name for the component. This makes the visual label for controls to be a trigger for speech activation. It primarily benefits users of speech recognition, but it also benefits low-vision and blind users who use a screen reader.

The accessible name is the text that is programmatically associated with the component — what an assistive technology will use. A screen reader will announce the accessible name when it lands on a button or an input field, so if users still retain the ability to see the screen, it can be confusing if what is announced doesn’t match what they see. A similar situation can occur when the blind user only knows how to refer to the accessible name based on what the screen reader renders, while a sighted colleague or remote Help-desk may only see the visible label.

More crucially, when users of speech recognition navigate around a page by voice, they can say the accessible name of the component to perform operations. If the visible label is different from the accessible name, two unwelcome things can happen. The first is the user will not be able to say the visible label to interact with the item. The second is that users may accidentally trigger the wrong component by saying its accessible name, if the visible label is not the same.

These problems are avoided by ensuring that the visible label is also the programmatic name of the component — or that the label’s text is included in the accessible name, preferably at the beginning.

Refer to Understanding 2.5.3 Label in name for more information on exceptions, intent, benefits, and techniques (external link to W3C).

Functionality that can be operated by motion can also be operated by user interface components, and the motion trigger can be disabled.

This requirement ensures that the page/application doesn’t rely solely on device motion to control the page content.

It primarily benefits users who are unable to physically manipulate devices and those who inadvertently trigger motion features due to tremors. Where designers and developers offer functionality that is triggered by motion, they must provide an alternative accessible means of operation and also provide an ability to disable motion as an interaction method.

An example of a motion actuation feature is a Shake To Undo feature. This can be made accessible by providing a user setting to disable the feature and offering an Undo button to perform the same action.

Spatial Exception: This requirement concerns input through sensors which respond directly to motions such as gesturing towards, tilting, or shaking a device. It does not cover the movement of users through space as registered by geolocation sensors or beacons.

Accessibility Supported Exception: Motion can be the sole means of operation where it triggers functionality through an accessibility supported interface, such as using eye movement detected by a camera as an alternative input device.

Essential Exception: This requirement does not apply where the motion is essential for the function, and, disabling or, bypassing it would invalidate the activity. A pedometer that relies on device motion to count steps is an example of such an essential activity.

Refer to Understanding 2.5.4 Motion actuation for more information on exceptions, intent, benefits, and techniques (external link to W3C).

The default human language of Web pages, non-web documents, or software can be programmatically determined.

This requirement ensures that developers identify the primary language of the content so that browsers and assistive technology can present text and other linguistic content correctly. This enables assistive technologies to load the correct pronunciations rules for the language.

For a web page the lang attribute of the <html> element allows you to specify the primary language and enables both assistive technologies and browsers to render the content more accurately.

Note: Where software platforms provide a locale / language setting, applications that use that setting and render their interface in that locale / language would comply with this requirement. Applications that do not use that setting, but instead use an accessibility-supported method for exposing the human language of the software would also comply.

Refer to Understanding 3.1.1: Language of Page for more information on intent, benefits, and techniques (external link to W3C).

The human language of each passage or phrase in the content can be programmatically determined.

This requirement ensures that developers clearly identify language changes for any portion of the content from the primary language on a page. The user agents and the assistive technologies need this information to correctly present content written in multiple languages, using the presentation and pronunciation rules for that language.

Note 1: There are some software and non-web document technologies where there is no assistive technology supported method for marking the language for the different passages or phrases in content, and it would not be possible to meet this requirement with those technologies.

Note 2: While the European standard EN 301 539, clause 11.3.1.2 Void does not require 3.1.2 Language of Parts for non-web software, it is still required by US 508.

Exception: Proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text are excluded from this requirement.

Refer to Understanding success criterion 3.1.2: Language of Parts for more information on exceptions, intent, benefits, and techniques (external link to W3C).

When any component receives focus, it does not initiate a change of context.

UI components receiving focus must not automatically change the context of the screen content. This ensures users navigating content can predict the circumstances that trigger a change of context.

Note: Changes to the ‘content’ do not always cause a “change of context”. The following examples of context changes do not meet this requirement:

Note: Some compound documents and their user agents are designed to provide different viewing and editing functionality depending on which portion of the compound document the user moves focus to. For example, a presentation can contain an embedded spreadsheet where menus and toolbars change based upon whether the user interacts with the presentation content or the embedded spreadsheet content. If an additional mechanism, such as a menu choice or special keyboard command, allows this change of context, then even though a focus change may trigger this context change, such a compound document would include a means of changing context without a change of focus and so would pass. See Guidance on Applying WCAG to Non-Web Information and Communications Technologies (WCAG2ICT)

Refer to Understanding success criterion 3.2.1: On Focus for more information on exceptions, intent, benefits, and techniques (external link to W3C).

Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.

This requirement ensures that when a user changes a setting in the user interface or inputs a value, it does not cause an automatic change of context unless the change can be predicted or the user is notified in advance. Displaying new content is not necessarily a change of context. A change of context is a change in meaning that can disorient a user. Examples of changes of context are:

“Changing the setting” of any user interface component is changing some aspect in the control that will persist when the user is no longer interacting with it. So selecting a checkbox or radio button, entering text into a text field, or changing the selected option in a list control changes its setting. In each situation, a user would need prior notice of changes in context. Activating a link or a button does not “change the setting”, and so does not fall under this requirement.

Refer to Understanding success criterion 3.2.2: On Input for more information on exceptions, intent, benefits, and techniques (external link to W3C).

Navigational mechanisms that are repeated throughout content occur in the same relative order each time they are repeated, unless a change is initiated by the user.

This requirement involves designing a consistent layout that enables users to predict where repeated elements in content appear, allowing quick navigation. For example, a low-vision user may depend on a search field that appears in the same location on each page of a Web site. Or, to better locate the home link in the left navigation area, a low-vision user may depend on the link appearing in the same relative order on each of a Web site’s pages.

This requirement does not restrict removing or adding content. It requires only that content that is repeated in multiple places remain in the same relative order. For example, links may be removed from the left navigation area of a Web site as a user navigates the site but the links that are present must remain in the same relative order.

Note: This requirement applies only to things that appear in a set, and is not applicable to individual non-web documents and software programs (not in a set). Refer to the definitions of set of documents and set of software programs to determine when a group of documents or software programs is considered a set, as well as the WCAG2ICT 3.2.3 guidance. When this requirement doesn’t apply, mark it as ‘N/A’ in a conformance report.

Refer to Understanding 3.2.3 Consistent Navigation for more information on exceptions, intent, benefits, and techniques (external link to W3C).

Components that have the same functionality within a set of content are identified consistently.

This requirement requires consistent identification of functional elements within a set of content such as web pages on a web site, documents in a library and components in a software application. When identical functions have different labels (identification), the content can be difficult to users with disability and users who rely on their familiarity with the functions.

This requirement also applies to alternative text. If icons or other non-text content has the same functionality in different content sets, then the alternative text must be the same.

Note: Individual non-web documents and software programs (not in a set) should mark this requirement N/A because it applies only to things that appear in a set. Refer to the definitions of set of documents and set of software programs to determine when a group of documents or software programs is considered a set, as well as the WCAG2ICT 3.2.4 guidance.

Refer to Understanding 3.2.4 Consistent Identification for more information on exceptions, intent, benefits, and techniques (external link to W3C).

If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

The requirement ensures users are aware that an input error has occurred and can determine what is wrong. The error message should be as specific and detectable as possible.

For example, if an unsuccessful form submission occurs due to input errors, simply re-displaying the form with a visual indicator for each bad field may be insufficient notification that errors occurred. The visual indicator may not be perceivable to a screen reader user and the form may be abandoned as not functional. Clear text messages are required.

“Input error” is defined as information provided by the user that is not accepted. This includes:

Refer to Understanding 3.3.1 Error Identification for more information on exceptions, intent, benefits, and techniques (external link to W3C).