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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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.

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) (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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) (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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) (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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) (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 ensures that color is not the only visual means of conveying information. 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 is unable 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 requires redundant visual indication.

Exception: This requirement does not apply when color is used to indicate “visited” links. It 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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 ensures 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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 the 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) (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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

This requirement ensures 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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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

This requirement ensures 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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 ensures important visual information, such as graphics and icons, meets a 3:1 contrast ratio against adjacent colors (the same minimum contrast required for large or bold text) 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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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

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

Authors must 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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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

This requirement ensures 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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 WCAG).

Refer to Understanding 2.3.1 Three Flashes or Below Threshold (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 EN 301 539, clause 11.2.4.2 Void standard 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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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) (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

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.