Copy link for 1.1.1

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, specific sensory experiences, and CAPTCHA. 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.

Copy link for 1.2.1

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.

Copy link for 1.2.2

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.

Copy link for 1.2.3

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.

Copy link for 1.2.4

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 Wikipedia® - 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.

Copy link for 1.2.5

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.

Copy link for 1.3.1

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.

Copy link for 1.3.2

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.

Copy link for 1.3.3

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.

Copy link for 1.3.4

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.

Copy link for 1.3.5

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.

Copy link for 1.4.1

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.

Copy link for 1.4.2

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.

Copy link for 1.4.3

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.

Copy link for 1.4.4

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.

Copy link for 1.4.5

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.

Copy link for 1.4.10

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.

Copy link for 1.4.11

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.

Copy link for 1.4.12

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

Copy link for 1.4.13

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.

Copy link for 2.1.1

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.

Copy link for 2.1.2

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.

Copy link for 2.1.4

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.

Copy link for 2.2.1

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.

Copy link for 2.2.2

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.

Copy link for 2.3.1

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.

Copy link for 2.4.1

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.

Copy link for 2.4.2

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.

Copy link for 2.4.3

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.

Copy link for 2.4.4

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.

Copy link for 2.4.5

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.

Copy link for 2.4.6

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.

Copy link for 2.4.7

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

Copy link for 2.5.1

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

Copy link for 2.5.2

For functionality that can be operated using a single pointer, the function completes on the up-event or offers 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 (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

Copy link for 2.5.3

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

Copy link for 2.5.4

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 motion actuation can be disabled, and that there is also an alternative, non-motion method of performing the desired functionality.

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.

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

Copy link for 3.1.1

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

Copy link for 3.1.2

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

Copy link for 3.2.1

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

Copy link for 3.2.2

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

Copy link for 3.2.3

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

Copy link for 3.2.4

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

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

Copy link for 3.3.1

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.

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

Copy link for 3.3.2

Labels or instructions are provided when content requires user input.

This requirement ensures that content contains unambiguous labels or instructions that enable users to avoid errors when input is required.

Instructions or labels may also specify data formats for fields, especially if they are out of the customary formats or if there are specific rules for correct input. Content authors may also choose to make such instructions available to users only when an individual control has focus. The goal is to provide enough information for the user to accomplish the task without causing hindrance or unnecessary clutter.

Refer to Understanding 3.3.2 Labels or Instructions (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

Copy link for 3.3.3

If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.

This requirement ensures that users are offered suggestions to correct input errors. It is easier for people with visual impairment or cognitive disabilities to correct input errors when allowed values are suggested or they can select one.

Refer to Understanding 3.3.3 Error Suggestions (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

Copy link for 3.3.4

For content that causes legal commitments or financial transactions for the user to occur, that modifies or deletes user-controllable data in data storage systems, or that submits user test responses, the user can reverse, correct, or confirm the action.

This requirement ensures users can avoid irreversible consequences that may occur when performing an action. This includes submitting financial transactions that cannot be reversed, deleting data that cannot be recovered, and purchasing items.

A disability can contribute to the possibility of making a mistake when performing a device-based action. For example, people with reading disabilities may transpose numbers and letters, and people who have motor disabilities may hit keys by mistake. Providing the ability to review and correct information or to reverse actions allows users to avoid mistakes that could have serious consequences.

To comply with this requirement, one of the following must be true:

Refer to Understanding 3.3.4 Error Prevention (Legal, Financial, Data) (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

Copy link for 4.1.1

Note: Authors no longer need to test against this requirement in order to mark it as satisfied for WCAG 2.1 or 2.0, as per updates to the WCAG standard. “In practice, this criterion no longer provides any benefit to people with disabilities in itself.”

IBM’s Accessibility Conformance Reports (ACRs) will automatically report 4.1.1 as being met for any standards that reference WCAG 2.0 or 2.1. Requirement 4.1.1 has been removed from the WCAG 2.2 standard.

The original purpose of this requirement was to ensure that user agents, including assistive technology such as screen readers, were able to accurately interpret content that uses markup languages. The concern was that if the markup of the content is ambiguous or incorrect, then it may be interpreted differently by different user agents and the content will not be accessible. This is no longer the case due to standards changes.

Where any accessibility issues arise from poorly formed code, they should now be reported against other appropriate Success Criteria. For example, if improper markup results in a component having a missing or inappropriate role, it would be fail 4.1.2 Name, Role, Value. Where code leads to incorrectly defined relationships between different elements on the page, it would likely fail 1.3.1 Info and Relationships.

Refer to Understanding 4.1.1 Parsing (external link to WCAG 2.1) for more information and history on this requirement.

Copy link for 4.1.2

For all user interface components (including but not limited to: form elements, links, and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

This requirement ensures that Assistive Technologies (AT) can gather information about, activate, set, and receive status of all user interface components.

Note: This requirement is primarily for developers who develop or script their own custom user interface components. Standard HTML controls already meet this requirement when used according to specification.

Custom interactive user interface components often do not expose proper role, state, and property information needed for assistive technologies. As a result, people with disabilities have difficulty identifying and interacting with the components. Common examples are custom menus, trees, data grids, accordions, and dialog boxes. Ensuring proper markup and keyboard operation enables people with disabilities to identify and interact with the custom components in the same manner they identify and interact with standard components.

Refer to Understanding 4.1.2: Name, Role, Value (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

Copy link for 4.1.3

In content implemented using markup languages, status messages can be programmatically determined through role or properties so that messages can be presented by assistive technologies without receiving focus.

This requirement ensures users are alerted of changes in status, such as new text appearing or a busy state ending. The key intended beneficiaries are blind and low vision users who may not perceive status messages.

Note: The ”status messages” are defined by WCAG as messages that provide information on things like the success or results of a user action, but that do not change the user’s context (i.e., take focus). This does not suggest that messages that take focus are forbidden; merely, such messages do not qualify as status messages and thus do not need to meet this requirement. The WCAG Understanding document provides multiple examples of messages that meet this criteria, as well as examples of messages that do not.

Refer to Understanding 4.1.3 Status Messages (external link to WCAG 2.1) for more information on exceptions, intent, benefits, and techniques.

Copy link for 4.1.4

Use accessibility-supported technologies. Any information or functionality that is implemented in technologies that are not accessibility supported must also be available via technologies that are accessibility supported.

Technology features can be relied upon to conform to this requirement only if they are used in a way that is accessibility supported.

Technology is accessibility supported when it works with assistive technologies (AT), and the accessibility features of operating systems, browsers, and other user agents.

As an example, a video is accessibility supported on a web page or in an application, if a number of things are in place. It is briefly labelled in text so a user knows what the video is (e.g., “Excerpt from the movie Bambi”). The media player or the operating system offers the ability to display captions and provide audio descriptions. All the controls for operating the media player are keyboard accessible, and assistive technologies such as screen readers properly announce and interact with those controls.

Note: This is an IBM requirement, WCAG describes what it means to be accessibility supported under Conformance section of understanding WCAG.

To fully understand what it means for a technology to be accessibility supported, see Understanding Accessibility Support section of Understanding WCAG (external link to WCAG).

Copy link for 502.2.1

Platform software shall provide user control over platform features that are defined in the platform documentation as accessibility features.

Note: This requirement applies to platform software and is Not Applicable (N/A) for most application software. Examples of platforms are: desktop operating systems, mobile and embedded operating systems, Web browsers, and software that supports macros or scripting. See definitions in the US Revised 508 Standard.

When a feature is documented in a platform as an accessibility feature, it should be consistently applied throughout the entire platform. This allows people who have disabilities to assume the reliability of accessibility features. For example, if an operating system allows changing the contrast, once the user makes a contrast change, it should be reflected in the entire operating system. If a browser allows changing the text size, once a user makes a text size change, this should be reflected in the entire browser.

All accessibility features must function and be operable by the end user as documented.

Refer to 502.2.1 User Control of Accessibility Features (external link to US 508) for more information.

Copy link for 502.2.2

Software shall not disrupt platform features that are defined in the platform documentation as accessibility features.

Platforms, such as the Windows operating system and iOS, have a set of accessibility options and settings that enables users with disabilities to customize system wide settings to improve accessibility. For example, a Windows user with a physical disability may not be able to press multiple key stroke sequences, such as Ctrl+Alt+Delete, simultaneously. Setting the Sticky Keys option enables the user to press and release the keys separately to invoke the desired function. For example, the user can press and release the Shift key 5 times, then press and release Ctrl, then Alt, then Delete keys to restart the Windows operating system.

Accessibility options and settings make it possible for people with a variety of disabilities to use their computer. If the application software interferes with these options, some users may find their system unusable.

Note: This requirement addresses the need to not disrupt or override platform accessibility options, including the keyboard commands to control these options. Requirement 503.2 User preferences addresses the need for applications to provide a mode of operation that inherits platform settings for color, contrast, font type, font size, and focus cursor.

Refer to 502.2.2 No Disruption of Accessibility Features (external link to US 508) for more information.

Copy link for 502.3.1

The object role, state(s), properties, boundary, name, and description shall be programmatically determinable.

Someone who is blind or vision impaired uses a computer with the aid of assistive technology (AT) such as a screen reader, screen magnifier, or Braille display. Software must provide semantic information about the user interface objects to the AT. This is done through platform specific application programming interfaces (APIs) that programmatically expose UI object information to the AT including the following:

In the following sample Windows dialog box, the UI element with the current focus has a role of radio button, a name of ”Two” and a state reflecting checked, focused, and focusable. The AT communicates to the user that focus is currently located on the radio button with the name ”Two”, and that there are three radio buttons from which to choose.

Sample Windows dialog box with radio buttons and text input field.

When the user moves focus to the edit input field, the object information returned to the AT reflects

The level of effort to expose object information to assistive technologies depends on how the user interface objects have been created. Standard user interface controls (widgets) such as Windows controls or Eclipse SWT widgets, such as push buttons, menu bars, and menu items typically expose object information with no additional implementation needed. Custom controls can be created by building on standard controls, or can be custom drawn. Controls that build on an accessible standard control are often accessible with little effort. Custom drawn controls that are unique to the software do not share any of the standard control definitions and have no inherited accessibility properties; therefore, all the accessible features must be provided by the software.

Refer to 502.3.1 Object Information (external link to US 508) for more information.

Apple iOS

Windows

Eclipse

Copy link for 502.3.2

States and properties that can be set by the user shall be capable of being set programmatically, including through assistive technology.

Someone who is blind or vision impaired uses a computer with the aid of assistive technology (AT) such as a screen reader, screen magnifier, or Braille display. Software must provide semantic information about the user interface objects to the AT. This is done through platform specific application programming interfaces (APIs) that programmatically expose information to the AT including name (identity), role (operation), state, boundary, properties, and description of user interface objects.

Often the assistive technology needs to set the attributes, such as states and properties in the object information. For example, a user inputting text in a desktop application through speech recognition software may need to style the text. The AT (speech recognition software) needs to access these attributes via APIs to programmatically set the styling of the text.

Refer to 502.3.2 Modification of Object Information (external link to US 508) for more information.

Copy link for 502.3.3

If an object is in a data table, the occupied rows and columns, and any headers associated with those rows or columns, shall be programmatically determinable.

Table organization and relationship information displayed visually must also be available programmatically so that the information is accessible to Assistive Technology (AT) users. Someone who is blind or vision impaired uses a computer with the aid of AT such as a screen reader, screen magnifier, or Braille display. Sighted users take many cues from the visible table and can easily see whether there are row or column headers and can read the data in a single cell, row, or column and associate it with the correct header information. Screen readers must have this information programmatically identified so that the intended relationships and organization shown in the presentation of the table can be conveyed to the user who cannot see it. As an example, a table header must be coded as a header; it is not sufficient to simply place the header information in the first row or first column and give it a special visual treatment such as bold text or a colored background.

Refer to 502.3.3 Row, Column, and Headers (external link to US 508) for more information.

Copy link for 502.3.4

Any current value(s), and any set or range of allowable values associated with an object, shall be programmatically determinable.

In addition to knowing the name, role, state, boundary, properties, and description of an object as covered in 502.3.1 Object Information, it is important for the assistive technology (AT) user to understand the current value and range of values available for input controls. For example, for a blind or sight impaired user to be able to interact with a spinner widget, it is important for the user to know the current value, as well as the allowed minimum to maximum values. In order to communicate these values to the user, they must be programmatically obtainable by the AT.

Refer to 502.3.4 Values (external link to US 508) for more information.

Copy link for 502.3.5

Any values associated with an object that can be set by the user shall be capable of being set programmatically, including through assistive technology.

In addition to knowing the name, role, state, boundary, properties, and description of a user interface object (component or widget) as covered in 502.3.1 Object Information, it is important for the assistive technology (AT) user to understand the current value and be able to set those values through the use of the AT that interfaces programmatically with the UI object.

For example, for a blind or sight impaired user to be able to interact with a spinner widget, it is important for the user to know the current value, the allowed minimum to maximum values, as well as to be able to select a desired value from a list. In order to communicate these values to the user, they must be programmatically obtainable by the AT.

Any values that can be set by other non-AT users must be capable of being set by AT users through the use of their AT which programmatically interfaces with the UI object (widget or component).

Refer to 502.3.5 Modification of Values (external link to US 508) for more information.

Copy link for 502.3.6

Any relationship that a component has as a label for another component, or of being labeled by another component, shall be programmatically determinable.

In addition to knowing the name, role, state, boundary, properties, and description of a user interface object (component or widget) as covered in 502.3.1 Object Information, it is important for the assistive technology (AT) user to understand the relationship a component (widget or UI object) may have as a label for or be labeled by another component, and that the AT can programmatically determine that relationship.

This requirements is in addition the requirement that a UI object have a name such as icon names, window titles, button labels, and edit field labels. The UI object and its name must be associated programmatically with the related UI object or content for which it is a label for or for which it is labeled by, such that the AT can render that information to the user.

Labels and relationships are used to describe sections of content, controls, as well as groups of controls. In some cases, it may be unclear whether a piece of static text is a label or additional description or instructions. But whether treated as a label, a description, or instructions the requirement is the same: if labels, descriptions or instructions are present, they must be programmatically determinable.

Note: For non-web software to which this requirement applies, programmatic determinability is best achieved through the use of accessibility services or API provided by platform software to enable interoperability between software and assistive technologies. See WCAG2ICT - 1.3.1 Info and relationships.

Refer to 502.3.6 Label Relationships (external link to US 508) for more information.

Copy link for 502.3.7

Any hierarchical (parent-child) relationship that a component has as a container for, or being contained by, another component shall be programmatically determinable.

This requirements is in addition to the requirement that a component (widget or UI object) have a name such as icon names, window titles, button labels, and edit field labels as covered in 502.3.1 Object Information. It is important for the assistive technology (AT) user to understand the relationship a component may have as a container for or be contained by another component, and that the AT can programmatically determine that relationship and render it to the user where applicable. This allows AT users to understand how to navigate through and interact with content and compound controls.

For example, AT users may be exploring a Folder (container or tree) view. They tab to the topmost folder (node) in the view and the AT announces that it has five items (children). Users can then use the arrow keys to move through the five items under the parent folder and discover the folder’s contents.

Refer to 502.3.7 Hierarchical Relationships (external link to US 508) for more information.

Copy link for 502.3.8

The content of text objects, text attributes, and the boundary of text rendered to the screen, shall be programmatically determinable.

Users depend on Assistive Technology (AT) to relay information to them about text content and attributes that are programmatically determined. If text is editable, AT users also need the ability to interact with the text content. The AT uses programmatically determined text attributes to describe the text styling to the user. Where the text is editable, the caret focus, text selection, and text boundaries must also be made programmatically available to the AT.

Note: The selection and manipulation of text involves considerations from several requirements. Depending on circumstances, such as whether text is static, read-only, or fully editable, similar techniques may be required from each of 502.3.x set of requirements:

Refer to 502.3.8 Text (external link to US 508) for more information.

Copy link for 502.3.9

Text that can be set by the user shall be capable of being set programmatically, including through assistive technology.

Users depend on Assistive Technology (AT) to relay information to them about text content and attributes that are programmatically determined. If text is editable, AT users also need the ability to interact with the text content. The AT uses programmatically determined text attributes to describe the text styling to the user. Where the text is editable, the caret focus, text selection, and text boundaries must also be made programmatically available to the AT.

Note: The selection and manipulation of text involves considerations from several requirements. Depending on circumstances, such as whether text is static, read-only, or fully editable, similar techniques may be required from each of 502.3.x set of requirements:

Refer to 502.3.9 Modification of Text (external link to US 508) for more information.

Copy link for 502.3.10

A list of all actions that can be executed on an object shall be programmatically determinable.

This requirement ensures that the list of possible actions offered by each UI object (component or widget) is made available programmatically. Assistive technology (AT) can then give access to all the supported actions without the user resorting to accessing them through a mechanism like a context menu, which would require extra steps. For example, a node in a flow diagram could be opened when the user presses Enter or Spacebar, deleted via the Delete key, or copied via Ctrl+C. These 3 possible actions would be available to ATs. This is especially beneficial for AT’s that offer assistance to users with mobility impairment, such as voice control software and on-screen keyboards.

Refer to 502.3.10 List of Actions (external link to US 508) for more information.

Notes:

Copy link for 502.3.11

Applications shall allow assistive technology to programmatically execute available actions on objects.

This requirement is complementary to 502.3.10 List of Actions. 502.3.11 Actions on Objects requires that Assistive Technology (AT) have the ability to execute all those supported actions without having the user resort to accessing the actions through a context menu, which would require extra steps. This is especially beneficial for ATs that offer assistance to users with mobility impairment, such as voice control software and on-screen keyboards. For example, possible actions that could be supported include:

Refer to 502.3.11 Actions on Objects (external link to US 508) for more information.

Notes:

Copy link for 502.3.12

Applications shall expose information and mechanisms necessary to track focus, text insertion point, and selection attributes of user interface components.

Even when the software provides keyboard access so users can navigate the software, the focus location, selection state, and text insertion point information must also be programmatically available to Assistive Technology (AT). AT’s such as screen readers and screen magnifiers need to know the position and contents of the visual focus indicator, so it can describe, magnify, or manipulate the focused object for the user. For example, as a user tabs around a dialog, a screen magnifier needs to follow the visual focus and does that using the programmatic focus information.

When editing, the caret or insertion bar is the visual focus. As a AT user moves the focus with the arrow keys, the AT must know the position of that focus so that it can echo the current character, word or line. The AT uses programmatically determined text selection, boundaries, and attributes to describe the text styling to the user.

Note: The selection and manipulation of text involves considerations from several requirements. Depending on circumstances, such as whether text is static, read-only, or fully editable, similar techniques may be required from each of 502.3.x set of requirements:

Refer to 502.3.12 Focus Cursor (external link to US 508) for more information.

Copy link for 502.3.13

Focus, text insertion point, and selection attributes that can be set by the user shall be capable of being set programmatically, including through the use of assistive technology.

Even when the software provides keyboard access so users can navigate the software, the focus location, selection state, and text insertion point information must also be programmatically available to Assistive Technology (AT). AT’s such as screen readers and screen magnifiers need to know the position and contents of the visual focus indicator, so it can describe, magnify, or manipulate the focused object for the user.

When editing, the caret or insertion bar is the visual focus. As a AT user moves the focus with the arrow keys, the AT must know the position of that focus so that it can echo the current character, word, or line. The AT uses programmatically determined text selection, boundaries, and attributes to describe the text styling to the user.

For example, speech recognition (command and control) needs programmatic access to the focus, text insertion point, and selection attributes to process a user’s spoken commands when creating a new document, entering spoken text into the application or document, or moving focus to manipulate the application or document.

Note: The selection and manipulation of text involves considerations from several requirements. Depending on circumstances, such as whether text is static, read-only, or fully editable, similar techniques may be required from each of 502.3.x set of requirements:

Refer to 502.3.13 Modification of Focus Cursor (external link to US 508) for more information.

Copy link for 502.3.14

Notification of events relevant to user interactions, including but not limited to changes in the component’s state(s), value, name, description, or boundary, shall be available to assistive technology.

In addition to providing semantic information about user interface objects (widgets, components, content) to Assistive Technology (AT), software must alert the AT when events occur that cause changes to the semantic information. These events include the following:

For example, an event is when a mailbox is refreshed or updated with new unread items.

It is essential that such change are programmatically available to the AT, such as via a listener, so that AT can describe the changes to the AT users, enabling them to understand and interact with the controls and content.

Refer to 502.3.14 Event Notification (external link to US 508) for more information.

Resources: See resources listed in 502.3.1 Object Information.

Copy link for 502.4

Platforms and platform software shall conform to the requirements in ANSI/HFES 200.2, Human Factors Engineering of Software User Interfaces — Part 2: Accessibility (copyright 2008) listed below:

Note: This requirement applies to platform software and is Not Applicable (N/A) for most application software. Examples of platforms are: desktop operating systems, mobile and embedded operating systems, Web browsers, and software that supports macros or scripting. See definitions in the Revised 508 Standards (external link to US 508) for more information.

Platforms are essential in providing the user basic access to the system under use. This requirement outlines the requirements for platform software to provide basic accessibility services as outlined in the ANSI/HFES 200.2 Human Factors Engineering of Software User Interfaces — Part 2: Accessibility (copyright 2008).

Refer to 502.4 Platform Accessibility Features (external link to US 508) for more information.

Copy link for 503.2

Applications shall permit user preferences from platform settings for color, contrast, font type, font size, and focus cursor.

The purpose of this requirement is to enable users who need a high contrast theme, preferrable fonts, or a more visible focus cursor to define their preferences in one place rather than having to modify the display settings for each application. Each application would then need to respect the platform settings.

High Contrast For most people, color is a matter of preference, but it is critical for many users with vision impairments. Many users with low vision need high contrast between text and the background to be able to read information on the screen. They may even need a particular color scheme, such as white text on a black background, to prevent the background from “bleeding” over and obscuring the foreground text. Some people consider the default color scheme legible but find that it causes eyestrain over longer periods of time.

Some operating systems provide a “high contrast” setting. For example, Windows users enable high contrast by going to the Ease of Access Center, selecting Set up High Contrast and choosing a high contrast theme.

System settings for color, font type and font size Someone with a vision disability who has difficulty reading small text, certain color combinations, or text that does not have sufficient font type (style) can use settings available through the operating system.

On the Windows platform, users can customize font color, type, and size settings to meet their specific needs. Applications should inherit those system settings and may also provide capability to customize the font color, type, and size for use within the application.

System settings for focus cursor Someone with low vision may have difficulty following the focus cursor. On the Windows platform, the user can modify the thickness of the focus rectangle and the blinking cursor (caret).

Exception: Applications that are designed to be isolated from their underlying platform software, including Web applications, shall not be required to conform to this requirement 503.2 User Preferences.

Refer to 503.2 User Preferences (external link to US 508) for more information.

Copy link for 503.3

Where an application provides an alternative user interface that functions as assistive technology, the application shall use platform and other industry standard accessibility services.

This requirement clarifies that any ”novel” interface designed by a team to support users with disabilities should be considered as an assistive technology and must satisfy the 502.x interoperability requirements of the US Revised 508 Standard.

As discussed in the standard, “The section aims to forestall the rare, but problematic, situation where there is a question about whether a product should be treated as assistive technology or another type of software. Examples of alternative user interfaces include on-screen keyboards for a single switch user, and screen reading software for a person who is blind”

More recent smartphone-relevant examples include voice recognition and on-screen keyboards with word prediction. In such situations, developers should use native platform versions of these features which should provide the compatibility with the assistive technologies (ATs). If an application creates a custom version of such interfaces, it must utilize industry standards for accessibility.

Note:

Refer to 503.3 Alternative User Interfaces (external link to US 508) for more information.

Copy link for 503.4.1

Where user controls are provided for volume adjustment, ICT shall provide user controls for the selection of captions at the same menu level as the user controls for volume or program selection.

This requirement applies to applications and software including media players and embedded players that control volume adjustments. Information and communications technology (ICT) products and applications that do not contain volume adjustments should mark this N/A (not applicable).

Several “Time-based Media” success criteria in WCAG, such as 1.2.2 Captions (prerecorded), require that captions are provided. Those requirements stipulate that audio content has been transcribed and is captured in a format that can be used to display captions. Those WCAG requirements covering the content of the captions are complementary to chapter 7 ICT with video capabilities of EN 301 594 and related Revised 508 Standard, which covers the actual process of displaying closed captions during playback, and the controls (CC button) for turning captions on and off provided by the media player. Ensure that the player you’re developing or deploying includes a CC button or setting at the same menu level as the user controls for volume or program selection.

Where the requirements of 7.3 User Controls for Captions and Audio Description are met, this requirement 503.4.1 Captions controls can also be considered to be met. 7.3 requires that the controls for captions be at the same level of interaction as the primary media controls.

Refer to 503.4.1 Caption Controls (external link to US 508) for more information.

Related requirements: Applications that play audio and video are required to meet the following related requirements:

Copy link for 503.4.2

Where user controls are provided for program selection, ICT shall provide user controls for the selection of audio descriptions at the same menu level as the user controls for volume or program selection.

Information and communications technology (ICT) products and applications that do not contain program selection should mark this N/A (not applicable). This requirement applies to applications and software including media players and embedded players that control program selection. Based on regional conventions, audio descriptions are also known as described video, video descriptions, or descriptive narration. 

Several “Time-based Media” success criteria in WCAG, such as 1.2.5 Audio Description, require that audio descriptions are provided. That requirement stipulates that meaningful video content has been described and is captured in a format that can be used to provide synchronized audio descriptions. Those requirements, covering the content of the audio descriptions, are complementary to chapter 7 ICT with video capabilities of EN 301 594 and related US Revised 508 Standards, which covers the actual delivery of audio descriptions during playback, and the controls for turning audio descriptions on and off provided by the media player.

Where media player technologies do not have explicit and separate mechanisms for audio description, an ICT is deemed to satisfy this requirement if the ICT enables the user to select and play alternative audio tracks, one of which provides audio descriptions in addition to other audio content.

Ensure that the media player you’re developing or deploying includes a setting or button for audio descriptions or alternative audio tracks at the same menu level as the user controls for volume or program selection.

Where the requirements of 7.3 User Controls for Captions and Audio Description are met, this requirement 503.4.2 Audio Description Controls can also be considered to be met. 7.3 requires that the controls for captions be at the same level of interaction as the primary media controls.

Refer to 503.4.2 Audio Description Controls (external link to US 508) for more information.

Related requirements: Applications that play audio and video are required to meet the following related requirements:

Copy link for 504.2

Authoring tools shall provide a mode of operation to create or edit content that conforms to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.1 for all supported features and, as applicable, to file formats supported by the authoring tool. Authoring tools shall permit authors the option of overriding information required for accessibility.

If a product provides the ability for users to author content, the output from the authoring tool must be verified against all requirements filtered by WCAG in these IBM requirements.

The US Revised 508 Standards defines an authoring tool as:

”Any software, or collection of software components, that can be used by authors, alone or collaboratively, to create or modify content for use by others, including other authors.”

Generally, any application or website that offers an ability for authors or end users to create rich text content is considered to include authoring tool functionality. A comment mechanism on a page which offered only an ability to include text with no styling would not be considered an authoring tool. However, any such comment mechanism that allowed for text styling (bold, italics or headings) or the inclusion of actionable elements like hyperlinks would be considered an authoring tool.

The Authoring Tool Accessibility Guidelines (ATAG) provide examples of software that are generally considered authoring tools, including “software for rapidly updating portions of web pages” (e.g., online forums and wikis).

The US Access Board has clarified that they only require one accessible mode of operation which need not be the main mode of operation. So where an application offers multiple formats for authored content output, only one of these formats needs to be accessible to meet 504.2.

The output need only support accessibility to the degree it is possible for that format. So if the format does not support multimedia, all the time-based media requirements would be Not Applicable (N/A). To use an extreme example, if an application offered the ability to author a plain-text document, this would meet 504.2 as long as the document used standard text formatting conventions for paragraphs, lists, and headings. In such a situation, almost all WCAG requirements (except potentially 1.3.1, 1.3.3, and 2.4.6) would be N/A, since they are not supported in plain text documents.

Exception: Authoring tools shall not be required to conform to 504.2 when used to directly edit plain text source code.

Notes:

Refer to 504.2 Content Creation or Editing (external link to US 508) for more information.

Copy link for 504.2.1

Authoring tools shall, when converting content from one format to another or saving content in multiple formats, preserve the information required for accessibility to the extent that the information is supported by the destination format.

When accessible content is created in one format, the accessible content and related information, such as proper heading mark-up, should be preserved when converting the document to another format.

The chief danger when converting is that the structure that improves a content’s accessibility may be lost, yet the visual cues that suggest its presence continue to exist. For instance, properly structured and accessible heading levels may exist in the original format, but when saved as another format, although the appearance of heading styles may be preserved, for instance, they still appear centered in a larger type size, the structural information that designates them as headings is lost.

In such a situation, assistive technologies can no longer expose this heading information to the end user. As well, technologies will no longer be able to apply user-specified styling to the headings.

Other common conversion losses include tabular information which is no longer programmatically structured as a table, form fields which are no longer interactive or are no longer associated with their labels, and navigation elements which appear to be retained but are no longer functional.

Note: Some formats may not support all the accessibility information contained in the original. The requirement is to ensure that accessibility is preserved ”to the extent that the information is supported by the destination format.”

Refer to 504.2.1 Preservation of Information Provided for Accessibility in Format Conversion (external link to US 508) for more information.

Copy link for 504.2.2

Authoring tools capable of exporting PDF files that conform to ISO 32000-1:2008 (PDF 1.7) shall also be capable of exporting PDF files that conform to ANSI/AIIM/ISO 14289-1:2016 (PDF/UA-1).

The US Revised 508 Standards states the following:

”Any authoring tools that export PDF files are required to allow a user to comply with the International Standard for Accessible PDF Technology (PDF/UA-1). PDF/UA-1 provides a technical, interoperable standard for the authoring, remediation, and validation of PDF content to ensure accessibility for people with disabilities who use AT such as screen readers, screen magnifiers, and joysticks to navigate and read electronic content.”

Where authoring tools provide the ability to create accessible PDFs, products need to confirm that the accessibility standard is also supported by the authoring tool.

Notes:

Resources: See requirement 602.3 Electronic support documentation for resources on accessible PDF.

Refer to 504.2.2 PDF Export (external link to US 508) for more information.

Copy link for 504.3

Authoring tools shall provide a mode of operation that prompts authors to create content that conforms to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.1 for supported features and, as applicable, to file formats supported by the authoring tool.

The Authoring Tools Accessibility Guidelines (ATAG) emphasize that by guiding authors from the outset toward the creation and maintenance of accessible content, accessibility problems are mitigated and less repair effort is required. For example, prompts to create accessible content can be as simple as:

Guiding users to create accessible content can also include more sophisticated approaches, such as integrating an accessibility checker into the tool or functionality.

See requirement 504.2 Content Creation or Editing to see the US Revised 508 Standard’s definition of an authoring tool.

Refer to 504.3 Prompts (external link to US 508) for more information.

Copy link for 504.4

Authoring tools may provide a range of templates that support features and, as applicable file formats. Where templates are provided, templates shall allow content creation that conforms to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.1.

Where authoring tools provide templates, there must be accessible template options. In the case where some templates are non-accessible, the accessible templates should be indicated. The templates identified as being accessible means that they have been verified against the WCAG subset of IBM accessibility requirements.

The Authoring Tools Accessibility Guidelines (ATAG) define templates as follows: ”Content patterns that are filled in by authors or the authoring tool to produce web content for end users (e.g. document templates, content management templates, presentation themes). Often templates will pre-specify at least some authoring decisions.”

ATAG states that providing accessible templates can have several benefits, including:

Refer to 504.4 Templates (external link to US 508) for more information. Also refer to 11.8.5 Templates (external link to EN 301 549).

Copy link for 602.2

Documentation lists and explains accessibility and compatibility features, including keyboard access.

People with disabilities cannot effectively use your software if they are not provided information on how to use the accessibility features. This is particularly important for keyboard access. Because most products, websites, and applications focus on navigation with the mouse, it is not always clear how to use it with the keyboard. All keyboard navigation and operation which does not follow established system conventions must be documented.

Designers: See related guidance

Developers: See related guidance

Refer to 602.2 Accessibility and Compatibility Features (external link to US 508) for more information.

Copy link for 602.3

Documentation in electronic format, including Web-based self-service support, shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.1.

The US Revised 508 Standards requires that electronic support documentation, both web-based and non-web-based, must conform to WCAG 2.0 Level A and AA success criteria. In Europe, EN 301 549 requires that the same documentation must also conform to WCAG, but at version 2.1 of the standard which includes additional requirements. This is a departure from the reduced accessibility requirements formerly applied to documentation in these jurisdictions.

Some examples of how documentation can be made accessible are:

Although following guidance from documentation format vendors such as PDF and Word can assist with creating accessible content, it is the responsibility of the product team, website and application owners to ensure all relevant WCAG 2.1 requirements have been addressed.

Refer to 602.2 Accessibility and Compatibility Features (external link to US 508) for more information.

Ensuring that documentation meets all relevant WCAG 2.1 requirements will have similar considerations regardless of the technology platform or format being used. Each section provides links to vendor or third-party supplied information that can help create accessible content:

Rather than publish a separate documentation requirements list, IBM requires that when documentation is provided in electronic format, it must meet all requirements in WCAG 2.1.

Copy link for 5.2

Where ICT has documented accessibility features, it shall be possible to activate those documented accessibility features that are required to meet a specific need without relying on a method that does not support that need.

The European EN 301 549 standard ensures that users of information and communications technology (ICT) in need of accessibility features can successfully activate them. For example, if a user has a need to only press one key at a time, the user should not be forced to use a keyboard combination to activate a feature that provides single-key-press operation. Similarly, a user that needs to operate a pointer using only single clicks should not be forced to use a double-click to activate the single-click feature.

This requirement is primarily aimed at platform software (i.e., operating systems). Applications meet this requirement automatically through features offered by the user agent or platform.

Refer to 5.2 Activation of accessibility features (external link to EN 301 549) for more information.

Copy link for 5.7

Where ICT has a key repeat function that cannot be turned off: a) the delay before the key repeat shall be adjustable to at least 2 seconds; and b) the key repeat rate shall be adjustable down to one character per 2 seconds.

The European EN 301 549 standard is similar to 502.4 Platform Accessibility requirement of the US Revised 508 Standard. However, where 502.4 Platform Accessibility mentions the need to ”provide adjustment of delay before key acceptance;” the European standard gives specific timings for the adjustment of both the key repeat and delay rate. Unlike US 508 requirement, the EU requirement is only assessed where key repeats cannot be disabled; however, since the EU requirement is more stringent, meeting the 2 second requirements for both the delay and repeat rate will also meet the US Revised 508 Standard.

This requirement is primarily aimed at platform software (i.e., operating systems). Applications meet this requirement automatically through features offered by the platform.

Refer to 5.7 Key Repeat (external link to EN 301 549) for more information.

Copy link for 5.8

Where ICT has a keyboard or keypad, the delay after any keystroke, during which an additional key-press will not be accepted if it is identical to the previous keystroke, shall be adjustable up to at least 0.5 seconds.

The European EN 301 549 standard is similar to 502.4 Platform Accessibility requirement of the US Revised 508 Standard. However, where 502.4 Platform Accessibility mentions a need to ”provide adjustment of same-key double-strike acceptance” the EU standard gives specific timings for the adjustment. Since the EU requirement is more stringent, meeting it will also satisfy the US Revised 508 Standard.

This requirement is primarily aimed at platform software (i.e., operating systems). Applications meet this requirement automatically through features offered by the platform.

Refer to 5.8 Double-strike Key Acceptance (external link to EN 301 549) for more information.

Copy link for 5.9

Where ICT has a mode of operation requiring simultaneous user actions for its operation, such ICT shall provide at least one mode of operation that does not require simultaneous user actions to operate the ICT.

Note: Having to use both hands to open the lid of a laptop, having to press two or more keys at the same time, or having to touch a surface with more than one finger are examples of simultaneous user actions.

Although primarily applicable to platform software, this requirement ensures that users who have permanent or temporary limited dexterity and reach, missing digits, hands and limbs, and other impairments can operate your non-web software. This requirement only addresses simultaneous operation in one modality since there must be a keyboard-equivalent to navigating and operating web and software. For example, this requirement does not require the elimination of using a mouse click in combination with a key press since there should be a keyboard equivalent to the mouse click.

Related requirements:

Refer to 5.9 Simultaneous User Actions (external link to EN 301 549) for more information.

Copy link for 7.1.1

Where ICT displays video with synchronized audio, it shall have a mode of operation to display the available captions. Where closed captions are provided as part of the content, the ICT shall allow the user to choose to display the captions.

The European EN 301 549 standard specifies requirements for information and communications technologies (ICT) such as media players and embedded players that render captions. This requirement is Not Applicable (N/A) to products and applications that do not play audio and video.

Several “Time-based Media” success criteria in WCAG, such as 1.2.2 Captions (Prerecorded), require that captions are provided. Those requirements stipulate that audio content has been transcribed and is captured in a format that can be used to display captions. Those WCAG requirements covering the content of the captions are complementary to chapter 7 ICT with video capabilities of EN 301 549, which covers the actual process and mechanisms of displaying closed captions during playback, and the controls (CC button) for turning captions on and off provided by the media player. Ensure that the player you’re developing or deploying will display closed caption and includes a CC button or setting.

Note: Where the requirements of 7.3 User Controls for Captions and Audio Description are met, this requirement 7.1.1 Captioning Playback can also be considered to be met. 7.3 requires that the controls for captions be at the same level of interaction as the primary media controls.

Refer to 7.1.1 Captioning Playback (external link to EN 301 549) for more information.

Related requirements: Applications that play audio and video are required to meet several related requirements:

Copy link for 7.1.2

Where ICT displays captions, the mechanism to display captions shall preserve synchronization between the audio and the corresponding captions as follows:

The European EN 301 549 standard specifies requirements for information and communication technologies (ICT) such as media players and embedded players that render captions. This requirement is Not Applicable (N/A) to products and applications that do not play audio and video.

Several “Time-based Media” success criteria in WCAG, such as 1.2.2 Captions (prerecorded), require that captions are provided. Those requirements stipulate that audio content has been transcribed and is captured in a format that can be used to display captions. Those WCAG requirements covering the content of the captions are complementary to chapter 7 ICT with video capabilities of EN 301 549, which covers the actual process and mechanisms of displaying closed captions during playback, and the controls (CC button) for turning captions on and off provided by the media player. Ensure that the video player you’re developing or deploying preserves the time stamps in the captions.  

Note: Open captions are considered to always meet this requirement since they are permanently burnt into the video, and so cannot have the synchronization affected by the media player.

Refer to 7.1.2 Captioning Synchronization (external link to EN 301 549) for more information.

Related requirements: Applications that play audio and video are required to meet the following related requirements:

Copy link for 7.1.3

Where ICT transmits, converts or records video with synchronized audio, it shall preserve caption data such that it can be displayed in a manner consistent with clauses 7.1.1 Captioning Playback and 7.1.2 Captioning Synchronization.

The European EN 301 549 standard specifies requirements for information and communications technologies (ICT) that are themselves media players and embedded players that render captions. This requirement is Not Applicable (N/A) to products and applications that do not play audio and video.

Caption data includes timing, presentational aspects of the text such as screen position, text colors, text style, and text fonts convey meaning. Altering these presentational aspects when transmitting, converting, or recording content could change the meaning and should be avoided to meet this requirement.

Several “Time-based Media” success criteria in WCAG, such as 1.2.2 Captions (Prerecorded), require that captions are provided. Those requirements stipulate that audio content has been transcribed and is captured in a format that can be used to display captions. Those WCAG requirements covering the content of the captions are complementary to chapter 7 ICT with video capabilities of EN 301 549, which covers the actual process of displaying captions during playback.

Refer to 7.1.3 Preservation of Captioning (external link to EN 301 549) for more information.

Related requirements: Applications that play audio and video are required to meet the following related requirements:

Copy link for 7.1.4

Where ICT displays captions, it shall provide a way for the user to adapt the displayed characteristics of captions to their individual needs, except where the captions are displayed as unmodifiable characters.

The European EN 301 549 standard specifies requirements for information and communications technologies such as media players and embedded players that render captions. This requirement is Not Applicable (N/A) to products and applications that do not play audio and video.

Allowing the user to set the following can contribute to meeting this requirement:

Open captions that are bitmap images (burnt into the video) are examples of unmodifiable characters.

Several “Time-based Media” success criteria in WCAG, such as 1.2.2 Captions (prerecorded), require that captions are provided. Those requirements stipulate that audio content has been transcribed and is captured in a format that can be used to display captions. Those WCAG requirements covering the content of the captions are complementary to chapter 7 ICT with video capabilities of EN 301 594, which covers the actual process and mechanisms of displaying captions during playback, and the settings for displaying the captions by the media player. Ensure that the player you’re developing or deploying includes caption display settings the user can control.

Refer to 7.1.4 Captions Characteristics (external link to EN 301 549) for more information.

Related requirements: Applications that play audio and video are required to meet the following related requirements:

Copy link for 7.1.5

Where ICT displays video with synchronized audio, it shall have a mode of operation to provide a spoken output of the available captions, except where the content of the displayed captions is not programmatically determinable.

The European EN 301 549 standard specifies requirements for information and communications technologies (ICT) such as media players and embedded players that render captions. This requirement is Not Applicable (N/A) to products and applications that do not play audio and video.

Several “Time-based Media” success criteria in WCAG, such as 1.2.2 Captions (Prerecorded), require that captions are provided. Since the captions provide text alternatives for the spoken words and sounds in the video, the captions themselves would not normally be announced. However, subtitles are different. Like captions, they appear as text on the screen, but subtitles provide a text translation of the original language. So if the subtitles can be announced (spoken), blind and low vision users who cannot see the subtitles on the screen can benefit from the spoken translation.

Where the subtitles are available programmatically (they exist as a file or text encoding instead of being burnt directly into the video) assistive technologies can use text-to-speech to speak or Braille the subtitles. Note that in order not to compete with the foreign-language audio, it is preferable for most users to have the spoken translated subtitles delivered on a separate audio track from the foreign-language audio track.

Refer to 7.1.5 Spoken Subtitles (external link to EN 301 549) for more information.

Related requirements: Applications that play audio and video are required to meet the following related requirements:

Copy link for 7.2.1

Where ICT displays video with synchronized audio, it shall provide a mechanism to select and play available audio description to the default audio channel.

The European EN 301 549 standard specifies requirements for information and communications technologies (ICT) such as media players and embedded players that render audio descriptions. Based on regional conventions, it is also known as described video, video descriptions, or descriptive narration. This requirement is Not Applicable (N/A) to products and applications that do not play audio and video.

Several “Time-based Media” success criteria in WCAG, such as 1.2.5 Audio Description, require that audio descriptions are provided. That requirement stipulates that meaningful video content has been described and is captured in a format that can be used to provide synchronized audio descriptions. Those WCAG requirements, covering the content of the audio descriptions, are complementary to chapter 7 ICT with video capabilities of EN 301 549, which covers the actual delivery of audio descriptions during playback, and the controls for turning audio descriptions on and off provided by the media player.

Providing user controls to activate audio descriptions: Although the wording of 7.2.1 Audio Description Playback specifies a mechanism that plays audio descriptions using the default audio channel, it also contains provisions for allowing the selection of alternative audio tracks.

Where video player technologies do not have explicit and separate mechanisms for audio description, an ICT is deemed to satisfy this requirement if the ICT enables the user to select and play alternative audio tracks, in the same manner that language tracks can be played, such as settings or buttons for English, French, or Mandarin audio tracks. The alternative audio track must provide the audio descriptions in addition to original audio content.

Where the requirements of 7.3 User Controls for Captions and Audio Description are met, this requirement 7.2.1 Audio Description Playback can also be considered to be met. 7.3 requires that the controls for audio descriptions be at the same level of interaction as the primary media controls.

Ensure that the media player you’re developing or deploying includes a setting or button for audio descriptions or alternative audio tracks.

Refer to 7.2.1 Audio Description Playback (external link to EN 301 549) for more information.

Related requirements: Applications that play audio and video are required to meet the following related requirements:

Copy link for 7.2.2

Where ICT has a mechanism to play audio description, it shall preserve the synchronization between the audio/visual content and the corresponding audio description.

The European EN 301 549 standard specifies requirements for information and communications technologies (ICT) such as media players and embedded players that render audio descriptions. Based on regional conventions, audio description is also known as described video, video descriptions, or descriptive narration. This requirement is Not Applicable to products and applications that do not play audio and video.

Several “Time-based Media” success criteria in WCAG, such as 1.2.5 Audio Description, require that audio descriptions are provided. That requirement stipulates that meaningful video content has been described and is captured in a format that can be used to provide synchronized audio descriptions. Those WCAG requirements, covering the content of the audio descriptions, are complementary to chapter 7 ICT with video capabilities of EN 301 549, which covers the actual delivery of audio descriptions during playback.

Ensure that the player you’re developing or deploying preserves the synchronization between the visual content and the corresponding audio description during playback.

Refer to 7.2.2 Audio Description Synchronization (external link to EN 301 549) for more information.

Related requirements: Applications that play audio and video are required to meet the following related requirements:

Copy link for 7.2.3

Where ICT transmits, converts, or records video with synchronized audio, it shall preserve audio description data such that it can be played in a manner consistent with clauses 7.2.1 Audio Description Playback and 7.2.2 Audio Description Synchronization.

The European EN 301 549 standard specifies requirements for information and communications technologies (ICT) such as media players and embedded players that render captions and audio descriptions. Based on regional conventions, audio description is also known as described video, video descriptions, or descriptive narration. This requirement is Not Applicable (N/A) to products and applications that do not play audio and video.

Audio description data includes the timing, volume of the audio, and content. Altering the audio descriptions when transmitting, converting, or playing back could change the meaning and should be avoided to meet this requirement.

Several “Time-based Media” success criteria in WCAG, such as 1.2.5 Audio Description, require that audio descriptions are provided. That requirement stipulates that meaningful video content has been described and is captured in a format that can be used to provide synchronized audio descriptions. Those requirements, covering the content of the audio descriptions, are complementary to chapter 7 ICT with video capabilities of EN 301 549, which covers the actual delivery of audio descriptions during playback.

Ensure that the player you’re developing or deploying preserves the audio description data during playback.

Refer to 7.2.3 Preservation of Audio Description (external link to EN 301 549) for more information.

Related requirements: Applications that play audio and video are required to meet the following related requirements:

Copy link for 7.3

Where ICT primarily displays materials containing video with associated audio content, user controls to activate subtitling and audio description shall be provided to the user at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls.

The European EN 301 549 standard specifies requirements for information and communications technologies such as media players and embedded players that render captions and audio descriptions. This requirement is Not Applicable to products and applications that do not play audio and video.

Several “Time-based Media” success criteria in WCAG, such as 1.2.2 Captions (Prerecorded), and 1.2.5 Audio Description (Prerecorded), require that captions and audio description are provided. Those requirements stipulate that meaningful audio and video content has been transcribed and described and is captured in a format that can be used to provide closed captions and audio descriptions. Those requirements, covering the content of the captions and audio descriptions, are complementary to chapter 7 ICT with video capabilities of EN 301 549, which covers the actual delivery of the captions and audio descriptions during playback.

Note: Where the requirements of 7.3 User Controls for Captions and Audio Description are met, the following requirements can also be considered to be met:

Refer to 7.3 User Controls for Captions and Audio Description (external link to EN 301 549) for more information.

Copy link for 10.5

Where ICT is a non-web document that contains synchronized media with captions, the captions should not obscure relevant information in the synchronized media.

Note: The numbering of this requirement was updated to match the latest version of the EN 301 549 standard. It is otherwise identical to the prior version 7.0 requirement 10.2.39 Caption Positioning.

The European EN 301 549 standard specifies requirements for non-web documentation. This requirement ensures that the position of captions do not cover any meaningful information in the video content. This requirement is Not Applicable (N/A) to documentation that does not play audio and video. This requirement only applies to non-web documents, including downloadable documents, and associated media player.

Several “Time-based Media” success criteria in WCAG, such as 1.2.2 Captions (Prerecorded), require that captions are provided. Those requirements stipulate that audio content has been transcribed and is captured in a format that can be used to display captions. Those WCAG requirements covering the content of the captions are complementary to chapter 10 Non-Web documents of EN 301 549, but which only covers non-web documentation.

Refer to 10.5 Caption Positioning (external link to EN 301 549) for more information.

Place captions outside content area: Where the media is shot in a different aspect ratio from the viewing area, or displayed in a different viewing area, it may be possible to place the captions in blank or black space outside the video area. This ensures the captions never obscure any important information in the video.

Reposition captions to avoid covering up important visual information: The following guidance is culled from the CBC Captioning Style Guide: Captions generally appear centered at the bottom of the screen. Re-position the caption during playback in order to avoid covering up important visual information such as on screen text, graphics, a person’s mouth, eyes, etc. Captions should be one or two lines in length. Three line scrolling captions are acceptable when time or space is not limited.

Related requirements: Applications that play audio and video are required to meet the following related requirements:

Copy link for 10.6

Where ICT is a non-web document that contains synchronized media with audio description, the audio description should not interfere with relevant audio information in the synchronized media.

Note: The numbering of this requirement was updated to match the latest version of the EN 301 549 standard. It is otherwise identical to the prior version 7.0 requirement 10.2.40 Audio Description Timing.

The European EN 301 549 standard specifies requirements for non-web documentation. This requirement ensures that audio descriptions do not overlap with any meaningful information in the audio track. This requirement is Not Applicable (N/A) to documentation that does not play audio and video. This requirement only applies to non-web documents, including downloadable documents, and associated media player.

A similar WCAG principle exists for all audio descriptions, so any team following best practices will not need to do additional work to meet this requirement. As noted in each of the WCAG techniques for audio descriptions:

”Since it is not helpful to have this new information obscure key audio information in the original sound track (or be obscured by loud sound effects), the new audio description is added during pauses in dialogue and sound effects.”

Refer to 10.6 Audio Description Timing (external link to EN 301 549) for more information.

Ensure audio descriptions do not overlap dialogue and sound effects or other important information by using any of the following techniques:

Related requirements: Applications that play audio and video are required to meet the following related requirements:

Copy link for 11.5.2.3

Where the software provides a user interface it shall use the applicable documented platform accessibility services. If the documented platform accessibility services do not allow the software to meet the applicable requirements of clauses 11.5.2.5 to 11.5.2.17, then software that provides a user interface shall use other documented services to interoperate with assistive technology.

Note: The numbering of this requirement was updated to match the latest version of the EN 301 549 standard. It is otherwise identical to the prior version 7.0 requirement 11.3.2.3 Use of Accessibility Services.

Interoperability with assistive technology (AT) such as a screen reader, screen magnifier, speech recognition software, or a Braille display is only possible for software applications that use accessibility services, also known as accessibility APIs. Each software platform has its own accessibility services and standardized extensions to the platform’s APIs. These APIs give applications a way to provide the required accessibility information and make it available to the ATs. The AT then uses this information as well as interacts with the user interface (UI) elements in the application.

By using the platform accessibility services, an application can provide information about UI elements such as the name, role, value, state, and property information as well as methods to insert text, follow or move the focus, perform actions on UI elements, and so on.

Note: Clauses 11.3.2.5 to 11.3.2.17 in the EN 301 549 standard are equivalent to the US Revised 508 Standards documented here in 502.3.1 Object Information through 502.3.14 Event Notification.

Refer to 11.5.2.3 Use of Accessibility Services (external link to EN 301 549) for more information.

Items in this section represent techniques that can be used to meet this requirement:

Copy link for 11.8.4 Repair

If the accessibility checking functionality of an authoring tool can detect that content does not meet a requirement of clauses 9 (Web content) or 10 (Documents) as applicable, then the authoring tool shall provide repair suggestion(s).

Note: The numbering of this requirement was updated to match the latest version of the EN 301 549 standard. It is otherwise identical to the prior version 7.0 requirement 11.6.4 Repair Assistance.

The European accessibility standard’s requirement to help authors repair inaccessible content can exceed the US Revised 508 Standards (504.3 Prompts) requirement to simply prompt authors to create accessible content. This European requirement, 11.8.4 Repair Assistance, addresses the additional authoring tool abilities to offer repair suggestions.

Refer to 11.8.4 Repair Assistance (external link to EN 301 549) for more information.

The output of authoring tools must meet all WCAG requirements. In addition, Techniques For Accessibility Evaluation And Repair Tools (AERT) should be used to meet this additional EN 301 549 requirement: