This list of requirements can be filtered by technology type, as the individual requirements themselves are not always applicable to all technologies. Options include web (Web), non-web software and native mobile apps (Software), support documentation (Doc web/nonweb), or authoring features (Authoring). Separate requirements lists for hardware, closed functionality requirements, two-way communications are available for IBM Internal Use Only.
Although version 7.1 is the current (Default) version for projects already in development, all teams are encouraged to adopt version 7.2 as soon as new projects begin in 2021. IBM teams are required to adopt version 7.2 beginning July 1, 2021.
Select a version
Filter by technology
Filter by standard
Select a level to achieve
All non-text content that is presented to the user has a text alternative that serves the equivalent purpose.
Rationale
Any information conveyed by means other than text needs to be provided in text as well. The text should provide equivalent information. Examples of non-text content are images, graphs, media, animations, CAPTCHA, and audio alerts.
Short and long text alternatives can be used as needed to convey the equivalent of the non-text content. The most common short text alternative is the use of ALT text attributes for images. Examples of long alternatives include descriptions for graphs, charts, or complex images.
Exceptions: There are situations where providing a text equivalent is either not possible or not desirable. Exceptions include controls, inputs, tests, and CAPTCHA. Non-text content that is primarily intended to create a specific sensory experience, then text alternatives should at least provide a descriptive identification of the non-text content. Content that is decorative, used to provide formatting, or visually hidden does not require a text alternative.
Refer to Understanding 1.1.1 Non-text Content for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- Identify and annotate decorative images
- If a meaningful image can be easily described, provide the text alternative
- When an image is a control, ensure the alternative describes the purpose, not the image
- Provide a succinct description of complex visuals, then offer more detailed information
Level 2
Level 3
Level 1
- Give decorative images an ALT attribute with an empty string (alt="")
- Use HTML, ARIA, or technology-specific techniques to add short text alternatives
- Where relevant text exists in the UI, use arai-labelledby and aria-describedby to reference
- Provide an accessible method for exposing long text alternatives
- Unit test: Developers should use verification tools
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
Manual
Screen reader
For prerecorded audio-only or video-only media, an alternative provides equivalent information.
Rationale
This requirement ensures that when information is presented in a playable medium, the user has an alternative way of consuming it.
For audio-only information, such as a recording of a speech, provide a transcript. A transcript is also the preferred alternative for video-only information, such as a soundless demonstration video. This is because a transcript – which in the case of a video describes all important visual information — can be presented to the user in many different ways by assistive technology. The alternative for video-only material could also be provided as an audio track.
Exception: This requirement does not apply when the audio-only or video-only content is actually the media alternative for text content, and is labeled as such. This alternative equivalent should provide no more information than is available in the text content.
Refer to Understanding 1.2.1 Audio-only and Video-only (Prerecorded) for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- No level 2 design tasks for this requirement
Level 3
Level 1
- No level 1 developer tasks for this requirement
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
Manual
Screen reader
- No screen reader tests specific to this requirement
Captions are provided for all prerecorded audio content in synchronized media.
Rationale
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:
- Open captions cannot be turned off by the user; they are typically burned into the image so that the user cannot adjust their appearance.
- Closed captions can be turned on or off by the user. They are provided in a separate data stream that is synchronized with the multimedia. The user has the potential to alter their size, typeface and color.
The source material for captions can also serve as a transcript or be transformed by assistive technology into other formats.
Exception: Captions are not needed when the media itself is an alternate presentation of text information. For example, if information on a page is accompanied by a synchronized media presentation that presents no more information than is already presented in text, but is easier for people with cognitive, language, or learning disabilities to understand, then the media would not need to be captioned. Such media should be labelled as a media alternative.
Refer to Understanding 1.2.2 Captions (Prerecorded) for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
Level 2
Level 3
- No level 3 design tasks for this requirement
Level 1
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
Manual
Screen reader
- No screen reader tests specific to this requirement
An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media.
Rationale
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:
- An audio description (also called video description or descriptive narration) is either added to the existing audio track during pauses in the existing audio content or on an alternate audio track. A narrator describes the important visual details that are not already explained in the soundtrack, including information about actions, text information not verbally described, who is speaking, facial expressions, scene changes, and so on.
- A full text alternative is a transcript that includes descriptions of all of the visual details, including the visual context, actions and expressions of the actors, and any other visual content, as well as the auditory information - the dialogue, who is speaking, sounds (as would be contained in captions). The goal is to give a person who is blind or visually impaired the same information a sighted user would get from the media. People who are deaf, hard of hearing, or who have trouble understanding audio information also benefit because they can read the text alternative as a transcript of the audio or video information.
Exception: When the media is a media alternative for text and is clearly labeled as such.
Note: This requirement overlaps with requirement 1.2.5: Audio Description (Prerecorded). If an audio description is used to meet 1.2.3, then 1.2.5 is also met.
Refer to Understanding 1.2.3 Audio Description or Media Alternative (Prerecorded) for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- No level 2 design tasks for this requirement
Level 3
Level 1
- No level 1 developer tasks for this requirement
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
- No automated checks identify issues specific to this requirement
Manual
Screen reader
- No screen reader tests specific to this requirement
Captions are provided for all live audio content in synchronized media.
Rationale
This requirement ensures people who are deaf or hearing-impaired, work in noisy environments, or turn off sounds to avoid disturbing others have access to the auditory information in real-time (live) presentations. Live captions do this by identifying who is speaking, displaying the dialogue and noting non-speech information conveyed through sound, such as sound effects, music, laughter, and location as it occurs.
Live captions must be synchronized with the presentation and be as accurate as possible, typically accomplished through Communication Access Real-time Translation (CART) real-time captioning.
As an added benefit, captioning live presentation can often produce a transcript that everyone who missed the live presentation can use for review.
This requirement also allows for equivalent facilitation when open or closed captions cannot be provided within the live video content via a separate communication channel, such as a third-party transcription service or by having meeting participants use a group chat to transcribe the discussion.
Refer to Understanding 1.2.4 Captions (Live) for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
Level 2
Level 3
- No level 3 design tasks for this requirement
Level 1
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
Manual
Screen reader
- No screen reader tests specific to this requirement
Audio description is provided for all prerecorded video content in synchronized media.
Rationale
This requirement ensures that users who cannot see have access to the visual information in a media presentation through an audio description, also sometimes called video descriptions or descriptive narration, to augment the audio portion of a presentation. This audio description is synchronized with the content; during existing pauses in the main soundtrack, the user hears an audio description of actions, characters, scene changes, and on-screen text that are important to understand the presentation. Secondary or alternate audio tracks are commonly used for this purpose.
Note: This requirement overlaps with requirement 1.2.3: Audio Description or Media Alternative (Prerecorded). Compliance requirements for 1.2.3 allow either an audio description or a text alternative. However, this requirement, 1.2.5, requires an audio description to comply.
Exception: If all important visual information is already announced in the audio track, or there is no important information in the video track, such as a “talking head” where a person is talking in front of an unchanging background, no audio description is necessary.
Refer to Understanding 1.2.5 Audio Description (Prerecorded) for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- No level 2 design tasks for this requirement
Level 3
Level 1
- No level 1 developer tasks for this requirement
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
Manual
Screen reader
- No screen reader tests specific to this requirement
Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
Rationale
This requirement ensures that Assistive Technologies (AT) can programmatically gather information, meaningful structure, and relationships that are displayed visually so that it can be rendered to the AT user. ATs such as screen readers and magnifiers speak the content or change the presentation layout for the user’s needs.
Each visual cue must be implemented in the standard way supported by the platform or technology. Common visual cues to the semantics of the content on the Web are supported programmatically through markup, and include headings, labels, forms, tables with associated row and column headers, images with & without captions, lists, emphasis such as bold and italics, hyperlinks and paragraphs.
In cases where there is no support for programmatic identification of the content, an alternative must be provided in the text. For example where identification is required, but no markup is available for emphasis, additional characters such as a double asterisk (**) may be used.
Note: The requirement is not limited only to visual cues, although they are the most common. For example, if audio cues are used to indicate required content, markup or textual identification must be additionally provided.
Refer to Understanding 1.3.1 Info and Relationships for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- Provide a label for every input element
- Consistently locate labels near inputs
- Connect each label and input in the wireframes
- Specify the accessible name for inputs without visible labels
- Indicate required fields and legends in an accessible manner
- Indicate heading levels; avoid skipping a level
- Use only one H1 per page, which typically matches the page title
Level 2
- Consider headings in place of bold sentence fragments and larger-sized text
- Flag italics, all caps and other cues, where appropriate
- Notate cells that serve as row or column headers
- Properly notate nested table headers in complex tables
Level 3
Level 1
Level 2
Level 3
- No level 3 developer tasks for this requirement
Automated
Manual
Screen Reader
When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.
Rationale
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:
- Determine if any information being presented has a meaningful reading order
- Ensure that the meaningful order is available to assistive technologies
An example of meaningful sequence, such as reading order, is text in a two-column article. A user must read the lines of text in the first column sequentially, then move to the second column and do the same. If an assistive technology reads across both columns (e.g., reads the first line of the cell in the first cell and then reads the first line of the cell in the second column) before proceeding to the next line, the user will obviously not understand the meaning. Other potential failures of meaningful sequence can occur when using CSS, layout tables, or white space to position content.
It is important not to confuse the reading order with the navigation order. The ability to navigate (i.e., move by keyboard between interactive controls) in a way that preserves meaning is covered by 2.4.3 Focus Order. Meaningful Sequence is concerned solely with the reading order, and so cannot normally be tested without assistive technology. Screen readers render content in a serialized manner.
Note: Sequence is not important for some content. For example, it does not normally affect meaning whether side navigation is read before or after the main content. So while matching the visual and reading order is a way to ensure this requirement is met, a difference in visual order and reading order is not a failure where the sequence does not affect the meaning.
Refer to Understanding 1.3.2 Meaningful Sequence for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- No level 2 design tasks for this requirement
Level 3
Level 1
- No level 1 developer tasks for this requirement
Level 2
- No level 2 developer tasks for this requirement
Level 3
Automated
Manual
- No manual guidance for this requirement
Screen Reader
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.
Rationale
This requirement ensures instructions to the user that use sensory characteristics such as shape or location to provide context are not the only means of conveying information.
When elements are described using visual cues such as shape, size, or physical location (e.g., “select the button on the right”), it can make it easier for a sighted user and some people who have cognitive disabilities to locate the elements. But, someone with a vision disability may not be able to perceive those visual cues. The element must also be described in another non-visual way, such as by its label (e.g., “select the Delete button on the right”).
It is important to understand that this requirement is entirely focused on referencing sensory characteristics in instructions. The instructions need to be understandable even if the content is reflowed or transformed.
For example, a screen display without images, or the display is reflowed on a mobile device changing the content positioning.The simplest way to prevent failures of sensory characteristics is to always have a visible text label and reference that label in the instructions.
Note: Use of color, also a sensory characteristic, has a separate requirement, see 1.4.1 Use of Color, that governs its use as not being the only means of distinguishing content. That applies to any reliance on the use of color, and not just references to color in instructions.
Refer to Understanding 1.3.3 Sensory Characteristics for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
Level 3
- No level 3 design tasks for this requirement
Level 1
- No level 1 developer tasks for this requirement
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
Manual
Screen reader
- No screen reader tests specific to this requirement
Content does not restrict its view and operation to a single display orientation, such as portrait or landscape.
Rationale
This requirement ensures that content does not get locked to either portrait or landscape presentation mode.
The key intended beneficiaries of this requirement are users unable to modify the orientation of devices. If designers force content to only display in portrait (or landscape) mode, it deprives users of the option to consume the content in the perspective that they need. If a user has a device affixed to a wheelchair or is otherwise unable to reorient the device to match the design-imposed orientation, the content can become unusable.
Note: This requirement bans developer-controlled techniques to limit the display orientation of an application on the device. Where a user activates any system-level orientation lock, applications will be subjected to this system-level setting without any action required on the developer’s part. System or hardware locks are user-imposed preferences and are not contradictory to this requirement.
Essential Exception: This requirement does not apply where a specific display orientation is essential. WCAG defines essential as: ”if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform.” Such a situation will be rare; most applications should be able to be usable when displayed in either orientation although one orientation may be less optimal.
An example of an application whose orientation would be considered essential is a piano keyboard emulator. Since such an app mimics a physical piano keyboard, which is heavily biased to horizontal operation, the few keys available in a portrait orientation would make the application’s intended function unusable.
Refer to Understanding 1.3.4 Orientation for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
Level 3
- No level 3 design tasks for this requirement
Level 1
- No level 1 developer tasks for this requirement
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
- No automated checks identify issues specific to this requirement
Manual
Screen reader
- No screen reader tests specific to this requirement
The purpose of each input field that collects information about the user can be programmatically determined when the field serves a common purpose.
Rationale
This requirement ensures that meaning of common inputs is available via technology.
The key beneficiaries of this requirement are users with some cognitive disabilities. In situations where users are asked to provide information about themselves, if the purpose of each input can be programmatically determined, then the prompts may be customized or auto-filled through Assistive Technologies and browsers to make them more understandable to a specific user, and potentially easier to complete.
Not all inputs must meet this. The requirement is restricted to common ones identified in WCAG’s list of Input Purposes for User Interface Components, such as name, address and contact information. As well, this only needs to be met when a technology can programmatically indicate the meaning. The most common usage will be employing auto-fill attributes.
Refer to Understanding 1.3.5 Identify Input Purpose for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- No level 2 design tasks for this requirement
Level 3
Level 1
- No level 1 developer tasks for this requirement
Level 2
- No level 2 developer tasks for this requirement
Level 3
Automated
Manual
Screen reader
- No screen reader tests specific to this requirement
Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
Rationale
This requirement ensure that Color is not the only visual means of conveying information, because many users have deficiencies in color perception and cannot identify or distinguish colors. Another non-color method for making the information available visually is required, such as with pattern, images, text, or text formatting.
For example, if text in an input field is colored red to show it is invalid, a user who cannot distinguish the red will not be able to detect the problem. If a warning symbol is added beside the text box then the user can locate it.
This requirement is not meant to discourage the effective use of color or color coding, but to require redundant visual indication.
Exception: This requirement does not apply when color is used to indicate “visited” links. This requirement also does not apply when color is used to indicate the location of a mouseover focus on a navigation bar or within an application.
Refer to Understanding 1.4.1 Use of color for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- Ensure legends do not rely only on the non-contrasting colors to match data points to legend text
- Confirm color alone does not indicate status or errors
Level 3
- No level 3 design tasks for this requirement
Level 1
- No level 1 developer tasks for this requirement
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
Manual
Screen reader
- No screen reader tests specific to this requirement
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.
Rationale
Individuals who use screen reading software can find it hard to hear the speech output if there is other audio playing at the same time. This difficulty is exacerbated when the screen reader’s speech output is software-based (as most are today) and is controlled via the same volume control as the auto-playing sound. Therefore, this requirement ensure the user is able to turn off or adjust the volume of the background sound independently from the system volume control.
Automatically starting sounds is highly discouraged, especially those that last for more than 3 seconds, as the sound interferes with the ability for a screen reader user to hear navigational cues to find the sound adjustment controls. It is better to have any audio content started through a user action.
Note: Having control of the volume includes the ability to silence the sound.
Refer to Understanding 1.4.2 Audio control for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- Stop auto-playing content when it receives focus or provide a simple pause mechanism
- Avoid automatically playing content that lasts more than five seconds
- Provide an ability to pause, stop or hide auto-playing content
Level 3
- No level 2 design tasks for this requirement
Level 1
- No level 1 developer tasks for this requirement
Level 2
Level 3
- No level 3 developer tasks for this requirement
Automated
Manual
Screen reader
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.
Rationale
This requirement ensures enough contrast is provided between text and its background to enable users with moderately low vision to read the text without contrast-enhancing technology. (Users requiring more contrast will often use an assistive technology or platform feature such as Windows High Contrast mode.)
WCAG 2.0 makes a distinction between “large” text and small or body text.
Large text, which is defined as text that is at least 18 point or at least 14 point when bold, has a contrast requirement of 3 to 1.
Body text (less than 18 point and less than 14 point when bold) has a contrast requirement of 4.5 to 1.This requirement also applies to images of text that are intended to be understood as text. Refer to requirement 1.4.5 Images of text. However, this contrast requirement does not apply to decorative text which conveys no meaning, or text that is part of a logo or brand name.
This requirement specifically addresses text contrast, WCAG 2.0 recommends sufficient color contrast for data presented in charts and graphs as well. WCAG 2.1 introduced a new specific requirement for 1.4.11 Non-text contrast.
Incidental Exception: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
Logotypes Exception: Text that is part of a logo or brand name has no minimum contrast requirement.
Refer to Understanding 1.4.3 Contrast (minimum) for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- Choose text that sufficiently contrast with its background
- Achieve minimum contrast for all text placed over images or gradient backgrounds
Level 2
Level 3
- No level 3 design tasks for this requirement
Level 1
- No level 1 developer tasks for this requirement
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
Manual
- Check use of color, contrast, and images of text
- Check pointer hover
- Check pointer operation
- Check focus indicator
Screen reader
- No screen reader tests specific to this requirement
Text can be resized without assistive technology up to 200 percent without loss of content or functionality.
Rationale
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:
- a lack of appropriate line wrapping
- truncated, overlapped or obscured text
- missing scrollbars when content is zoomed
In cases where content fails to respond to the platform’s scaling features authors must provide a way of resizing text.
Note: For some interactive content, such as editable cells in a table, truncation is acceptable if the component’s full content is available on focus or after user activation, and an indication that this information can be accessed is provided to the user in some way besides the fact that it is truncated.
Exception: Media captions and images of text are excluded from this requirement. Resizing the closed captions is normally a feature of the player or platform, not the author’s responsibility. Images of text, which are covered under 1.4.5 Images of text, do not normally scale well.
Refer to Understanding 1.4.4 Resize text for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- No level 2 design tasks for this requirement
Level 3
- No level 2 design tasks for this requirement
Level 1
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
Manual
Screen reader
- No screen reader tests specific to this requirement
If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text.
Rationale
This requirement ensure that when technology is capable of achieving a desired visual presentation, designers must use text — not images of text — to allow people with disabilities to adjust the text presentation per their personal preferences. For example, a user may require a particular text size, font family or text/background color.
The definition of image of text contains the note: “This does not include text that is part of a picture that contains significant other visual content.” Examples of such pictures include graphs, screenshots, and diagrams that visually convey important information beyond text only.
Customizable Exception: This requirement does not apply to images of text that can be visually customized to the user’s requirements.
Essential Exception: This requirement does not apply when a particular presentation of text is essential to the information being conveyed. For example, logotypes (text that is part of a logo or brand name) are considered essential.
Refer to Understanding 1.4.5 Images of text for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- Do not use images of text when text can be used
- Provide text alternatives for logos and other essential images of text
Level 3
- No level 3 design tasks for this requirement
Level 1
- No level 1 developer tasks for this requirement
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
- No automated checks identify issues specific to this requirement
Manual
Screen reader
Content can reflow without loss of information or functionality, and without requiring scrolling in two dimensions.
Rationale
This requirement ensure content can be enlarged without requiring horizontal scrolling.
The key intended beneficiaries of Reflow are low-vision users who want to be able to enlarge text yet still see the content in their viewport without scrolling across the page.
With Reflow, width constraints are placed on horizontally read languages such as English, while height constraints are placed on vertically read languages such as Chinese. The constraints are as follows:
- Vertical scrolling content “can be presented without loss of information or functionality, and without requiring scrolling in two dimensions” at a width equivalent to 320 CSS pixels;
- Horizontal scrolling content can be presented in the same manner at a height equivalent to 256 CSS pixels.
“Scrolling in two dimensions” refers to forcing the user to scroll in both the X dimension (left and right) as well as the Y dimension (up and down) in order to view the content. Such scrolling makes it difficult to keep your place when relocating from the end of a long line to the start of the next line, especially when text is magnified. Since IBM mainly produces horizontally read content, we have simplified the objective of this guidance to say “horizontal scrolling” which is the scrolling to avoid in most written languages, including English.
This requirement complements the existing WCAG 2.0 1.4.4 Resize text, which requires text to be able to be doubled in size. Resize does not require text to reflow, but merely to enlarge. When combined with this requirement 1.4.10 Reflow, it means that the starting size of text must be able to resized to 200% while still having the ability to reflow so that horizontal scrolling is not needed.
Authors can test for reflow on a desktop browser with typical 1280x1024 pixel dimensions by zooming the content to 400%. If the content expands without requiring scrolling in both dimensions, this is mathematically the same as reducing the window to 320x256 pixels.
Exception: Parts of the content “which require two-dimensional layout for usage or meaning” do not need to meet this requirement. Two-dimensional content includes maps, videos and images, which generally rely on a maintained aspect ratio to be intelligible. As well, even relatively simple data tables may not fit within the confines of a reduced viewport and thus data tables are also excepted. It is important to note that there are advisory techniques that allow images to be displayed and tabular information to be transformed to fit within a constrained viewport. Where possible, content authors are encouraged to adopt such techniques.
Refer to Understanding 1.4.10 Reflow for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- Reflow content without horizontal scrolling
- Where responsive design is not supported, provide an option to display content at 256 CSS pixels wide
Level 2
- No level 2 design tasks for this requirement
Level 3
- No level 3 design tasks for this requirement
Level 1
- No level 1 developer tasks for this requirement
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
- No automated checks identify issues specific to this requirement
Manual
Screen reader
- No screen reader tests specific to this requirement
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.
Rationale
This requirement ensure important visual information such as graphics and icons meets the same minimum contrast that is required for larger text which is a 3:1 contrast ratio against adjacent colors for two types of non-text content:
- User interface components
- Graphical objects
The key intended beneficiaries of this requirement are low-vision users who need to perceive active UI components and their states, as well as meaningful graphics.
For User interface components, the visual information that identifies a component as well as its state needs to meet the contrast ratio. This typically means that the outer edge of a component will need to be distinguishable from the background, as will any indicators for focus, selection or other states
For every graphical object required for understanding the content, whether it be a UI component or a non-interactive object, the parts of the graphic must meet a 3:1 contrast with the neighboring information. The WCAG Understanding document provides a range of examples for everything from monochrome icons to pie charts with different colored wedges. Considerations for such things as gradients and infographics are also discussed.
Unmodified Exception: UI components whose appearance is entirely determined by the user agent (e.g., stock HTML radio buttons and checkboxes) do not need to meet the 3:1 contrast if they are not modified by authors. This exception is intended to prevent making authors responsible for any shortcomings of a particular user agent default implementation.
Inactive Exception: UI Components that are not active (i.e., disabled) are not required to meet a minimum contrast. This matches the exception for text that is “part of an inactive user interface component” in 1.4.3 Contrast (Minimum).
Essential Exception: If a particular presentation of a graphical object is essential to the information being conveyed, it also does not need to meet the 3:1 contrast requirement. Examples of such essential graphics may be logos and flags, as well as reproductions of physical objects, whether drawn or photographed.
Refer to Understanding 1.4.11 Non-text contrast for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- Confirm input fields are discernable
- Contrast components against background
- Ensure visual states for components have sufficient contrast
- Contrast focus and non-focus states at least 3:1
- Confirm icon shapes have enough contrast
- For charts, ensure all data representations achieve 3:1 contrast
Level 2
Level 3
- No level 3 design tasks for this requirement
Level 1
- No level 1 developer tasks for this requirement
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
- No automated checks identify issues specific to this requirement
Manual
Screen reader
- No screen reader tests specific to this requirement
No loss of content or functionality occurs when users change letter, word and paragraph spacing, as well as line height.
Rationale
This requirement ensure users can adjust text spacing to make it easier to read.
Authors should ensure content can be transformed (such as through user style sheets) to attain all of the following specific requirements for a number of different text transformations without loss of content or functionality:
- Line height (line spacing) to at least 1.5 times the font size;
- Spacing following paragraphs to at least 2 times the font size;
- Letter spacing (tracking) to at least 0.12 times the font size;
- Word spacing to at least 0.16 times the font size.
Language exception: Where the communication language used in the content, or the script in which the language is written, do not make use of one or more of these text style properties, that language need only conform using the properties that exist.
Technology exception: This requirement is restricted to content implemented using markup languages that support text styling properties. Technologies that do not use markup, such as PDF, are excluded.
IBM has simplified the normative language of this requirement. Refer to Understanding 1.4.13 Text Spacing for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- No level 2 design tasks for this requirement
Level 3
Level 1
- No level 1 developer tasks for this requirement
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
- No automated checks identify issues specific to this requirement
Manual
Screen reader
- No screen reader tests specific to this requirement
Where hover or focus actions cause additional content to become visible and hidden, the additional content is dismissible, hoverable and persistent.
Rationale
This requirement ensure when receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:
- Dismissible: A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;
- Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
- Persistent: The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.
There are two main objectives achieved by these requirements. The first (covered by hoverable) is that low vision users, particularly those who rely on magnification to enlarge the content, are able to move their pointer toward the newly revealed content so they can read it. Magnification often results in only part of the new information being visible in the viewport until the user reorients the pointer. If the new content disappears the moment the user moves the mouse off the triggering element, or after some arbitrary time period, it will be difficult or impossible for some users to read it.
The second objective is that blind users and others who depend on the keyboard for operation, will be able to both trigger and dismiss the new content without disrupting their work. If the new information obscures other content, the user should be able to dismiss it easily without navigating — unless the new content is a warning about an error. The persistent requirement ensures that the information will remain present until the user has reviewed it.
Exception: WCAG allows situations where “The visual presentation of the additional content is controlled by the user agent and is not modified by the author.” This primarily covers use of the HTML
<title>
attribute. Browsers determine the display position and timing of title text, so it is not developer-controlled. However,title
as the means of providing additional content is discouraged by many accessibility advocates.Refer to Understanding 1.4.13 Content on hover or focus for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- Where possible, have dynamic content appear when users click, not when they hover
- If content appears on hover, the new material needs to remain visible until dismissed
- Understand the requirements for dismissing content that appears on hover
Level 3
- No level 2 design tasks for this requirement
Level 1
- No level 1 developer tasks for this requirement
Level 2
- Ensure Esc dismisses new content
- If content appears on hover, the new content needs to remain visible until dismissed
- Moving the pointer away from the trigger should not be the action that dismisses the new content
- Ensure custom tooltips and similar hover text can be triggered by keyboard
- Discuss alternatives to hover text
- Use caution where interactive controls appear in the hover text
Level 3
- No level 3 developer tasks for this requirement
Automated
- No automated checks identify issues specific to this requirement
Manual
Screen reader
- No screen reader tests specific to this requirement
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.
Rationale
This requirement ensures that content can be navigated with a keyboard or keyboard interface. When interactive content is operated using a keyboard, it is accessible to vision impaired people who cannot use devices requiring hand-eye coordination (e.g., a mouse) and by people who use alternative keyboards or input devices that act as keyboard emulators. Keyboard emulators include speech input, sip and puff devices, on-screen keyboards, scanning software, and a variety of assistive technologies. This requirement does not forbid or discourage providing mouse input or other input methods in addition to keyboard operation.
The requirement 502.2.2 No disruption of accessibility features addresses the software requirement to not disrupt or override platform accessibility options, including the keyboard commands to control these options. For web applications, the need to document non-standard keyboard operation is covered under 602.2 Accessibility and compatibility features.
Refer to Understanding 2.1.1 Keyboard for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- Note intended keyboard navigation in wireframes
- Specify the tab order
- Ensure all mouse-operable components are reachable by keyboard
- Reduce tabbing by effective grouping of elements
- Set expectations and note intended keyboard operation in wireframes
- Choose standard HTML elements, where possible
- Confirm framework libraries follow keyboard conventions
- For custom components, match the ARIA authoring practices keyboard guidance
- Provide instructions in the UI where keyboard operation differs from the norm
- Provide a keyboard equivalent for drag and drop
- Where a component has multiple mouse operations, notate the keyboard equivalent
- Dismiss notices, modals, and overlays with the Esc
Level 2
- Ensure all functions of media players are keyboard operable
- Document keyboard and other accessibility considerations
Level 3
- No level 3 design tasks for this requirement
Level 1
- Where possible, achieve the desired tab order by adjusting the DOM, rather than overriding the tabindex
- Use standard HTML elements where possible, using CSS to alter appearance not behavior
- Be familiar with established keyboard conventions
- Implement keyboard operation for custom elements
- Follow core considerations in reducing effort
- Unit test - confirm component keyboard interaction
Level 2
Level 3
- No level 3 developer tasks for this requirement
Supplemental techniques
- Match established desktop keyboard interactions for widgets in web applications:
Ensure that keyboard navigation behaves like desktop keyboard navigation.
For example, keyboard users tab to Windows® File Explorer and
then use the
Left
,Right
andUp
,Down
arrow keys to navigate to elements within the tree. - WAI ARIA: provides support and guidance for arrow key navigation of complex widgets,
such as menus, trees, and grids, via the
tabindex
attribute or aria-activedescendant property. For more information on how to implement keyboard navigation, see WAI-ARIA Authoring Practices design patterns and Keyboard-navigable JavaScript widgets. - Note for iOS platform: For keyboards connected to iOS devices,
Apple has its own set of
Tab
and arrow keys behaviors as noted in Wireless Keyboard with VoiceOver.
Automated
Manual
- Check tab or navigation order
- Check component keyboard interaction
- Check bypass blocks, consistent navigation, and multiple ways
- Dynamic update triggers and effects
Screen reader
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.
Rationale
The intent of this requirement is to ensure the keyboard focus does not get “trapped” within subsections of content, leaving keyboard-only users no way to return to other content.
Note: Since any content that does not meet this requirement can interfere with a user’s ability to use the whole page/application, all content, whether it is used to meet other requirements or not, must meet this requirement. WCAG Conformance Requirement 5 Non-interference states that users must not be blocked from reaching all parts of the content, regardless of technology limitations.
Refer to Understanding 2.1.2 No keyboard trap for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- Confirm framework libraries follow keyboard conventions
- For custom components, match the ARIA authoring practices keyboard guidance
- Where a component has multiple mouse operations, notate the keyboard equivalent
- Dismiss notices, modals, and overlays with the Esc
Level 2
Level 3
- No level 3 design tasks for this requirement?
Level 1
- Implement keyboard operation for custom elements
- Follow core considerations in reducing effort
- Unit test - confirm component keyboard interaction
Level 2
Level 3
- No level 3 developer tasks for this requirement
Development techniques
G21: Ensuring that users are not trapped in content (external link to W3C)
- iOS-specific considerations for proper implementation.
iOS hybrid: Apple recommends using the HTML5
audio
andvideo
elements for mobile Safari. These elements support playback natively in the browser using the browser’s built-in controls.
Developers may also create custom media controls for rich interactivity using CSS and JavaScript.
See Apple’s About HTML5 Audio and Video and
Automated
Manual
- Check tab or navigation order
- Check component keyboard interaction
- Check bypass blocks, consistent navigation, and multiple ways
Screen reader
- No screen reader tests specific to this requirement
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.
Rationale
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:
- A mechanism to turn the shortcut off
- A mechanism to remap the shortcut to use one or more modifier keys, such as
Alt
- The keyboard shortcut for a user interface component is only active when that component has focus
Refer to Understanding 2.1.4 Character key shortcuts for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- No level 2 design tasks for this requirement
Level 3
Level 1
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Development techniques
- G217: Providing a mechanism to allow users to remap or turn off character key shortcuts (external link to W3C)
Automated
- No automated checks identify issues specific to this requirement
Manual
Screen reader
For each time limit that is set by the content, the user can turn off, adjust, or extend the limit.
Rationale
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:
- Turn off: User is allowed to turn off the time limit before encountering it; or
- Adjust: User is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
- Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action, such as “press the space bar”, and the user is allowed to extend the time limit at least ten times.
Real-time Exception: This requirement does not apply if the time limit is a required part of a real-time event, such as an auction, and no alternative to the time limit is possible.
Essential Exception: This requirement does not apply if the time limit is essential and extending it would invalidate the activity.
20 Hour Exception: This requirement does not apply if the time limit is longer than 20 hours.
Refer to Understanding 2.2.1 Timing adjustable for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- No level 2 design tasks for this requirement
Level 3
Level 1
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
Manual
Screen reader
For moving, blinking, scrolling, or auto-updating information, the user can pause, stop or hide it, or control the update frequency.
Rationale
This requirement ensures distractions to users are avoided during their interaction with content. There are two considerations:
- Moving, blinking, scrolling: For any moving, blinking, or scrolling information that
- starts automatically,
- is presented in parallel with other content,
- lasts more than five seconds, there is a mechanism for the user to pause, stop, or hide it; and
- Auto-updating: For any auto-updating information that
- starts automatically and
- is presented in parallel with other content,
- there is a mechanism for the user to pause, stop, or hide it, or to control the frequency of the update.
”Moving, blinking and scrolling” refers to visible content that conveys a sense of motion. Common examples include auto-playing videos, synchronized media presentations, animations, real-time games, and scrolling stock tickers.
”Auto-updating” refers to visible content that updates or disappears based on a preset time interval. Common automatically updating content includes audio, weather information, news, stock price updates, and auto-advancing presentations and messages.
For all these types of content, the user needs the ability to pause, stop, or hide the content. In addition, for auto-updating, designers have the option of providing the user with a means to control the frequency of updates.
Content that moves or updates automatically can be a barrier to anyone who has trouble reading stationary text quickly, anyone who has trouble tracking moving objects, and screen readers which may not be able to render all of the content (text) before it gets updated; the user can lose their place if the updates happen in the middle of reading the content.
Moving content can also be a severe distraction for some people. Certain groups, particularly those with attention deficit disorders, find blinking content distracting and have difficulty concentrating on other content. The five-second limit is long enough to get a user’s attention, but short enough for a user to wait out the distraction before reading the page.
The requirement Understanding 2.3.3 Animation from Interactions applies when a user’s interaction initiates animation. In contrast this requirement, 2.2.2 Pause, stop, hide, applies when the web page or application initiates animation.
Note 1: For requirements related to flickering or flashing content, see Guideline 2.3 Seizures and physical reactions.
Note 2: Since any content that does not meet this requirement can interfere with a user’s ability to use the whole page/application, all content, whether it is used to meet other requirements or not, must meet this requirement. WCAG Conformance Requirement 5 Non-interference states that users must not be blocked from reaching all parts of the content, regardless of technology limitations.
Essential Exception: If the movement, blinking, scrolling or auto-updating is part of an activity where it is essential, this requirement does not apply. An animation, such as loading… that occurs as part of a preload phase or similar situation can be considered essential if any user interaction cannot occur during that phase and if not indicating progress could confuse users or cause them to think that content was frozen or broken.
Refer to the definition of blinking.
Refer to Understanding 2.2.2 Pause, stop, hide for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- Stop auto-playing content when it receives focus or provide a simple pause mechanism
- Avoid starting animations or video automatically
- Avoid automatically playing content that lasts for more than five seconds
- Provide an ability to pause, stop, or hide auto-playing content
Level 3
- No level 3 design tasks for this requirement
Level 1
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
Manual
Screen reader
- No screen reader tests specific to this requirement
- Moving, blinking, scrolling: For any moving, blinking, or scrolling information that
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.
Rationale
This requirement ensures users can access content without inducing seizures due to photosensitivity.
For people with photosensitive seizure disorders, sizeable content that flashes at certain frequencies for more than a few flashes can trigger a seizure. Because people are more sensitive to red flashing than to other colors, you must perform a special test for saturated red flashing. This requirement is based on the broadcasting industry guidelines, but they have been adapted for computer monitors, which allow content to be viewed from a short distance using a larger angle of vision.
Note: Since any content that does not meet this requirement can interfere with a user’s ability to use the whole page/application, all content, whether it is used to meet other requirements or not, must meet this requirement. See WCAG Conformance Requirement 5 Non-interference (external link to W3C).
Refer to Understanding 2.3.1 Three flashes or below threshold for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- Avoid flashing content
- Reduce the frequency of flashes to under three times in any one second
- Reduce the size of the flashing content below the general flash and red flash thresholds
Level 2
- No level 2 design tasks for this requirement
Level 3
- No level 3 design tasks for this requirement
Level 1
Level 2
- No level 2 developer tasks for this requirement?
Level 3
- No level 3 developer tasks for this requirement?
Automated
- No automated checks identify issues specific to this requirement
Manual
Screen reader
- No screen reader tests specific to this requirement
A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.
Rationale
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
, andnavigation
.Notes:
- Non-web documents and software should mark this requirement N/A.
- This requirement does not require methods that are redundant to functionality provided by the browser.
Most web browsers and platforms provide keyboard shortcuts to move the user focus to the top or bottom of the page,
Home
orEnd
, andPagUp
orPageDown
at a time. - Although not essential to meet the requirement, being able to bypass blocks of content that are repeated within a page directly addresses user needs and is generally considered best practice.
Refer to Understanding 2.4.1 Bypass blocks for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- No level 2 design tasks for this requirement
Level 3
Level 1
Level 2
Level 3
- No level 3 developer tasks for this requirement
Automated
Manual
Screen reader
Web pages, non-web documents, and software have titles that describe topic or purpose.
Rationale
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:
- Succinctly identify the subject
- Make sense when read out of context, for example by a screen reader, in a site map, list of search results, window title, or on a browser tab title
If the page or document belongs to a collection, the title should:
- List the most unique identifying information first
- Be unique within the collection
Note: While the European standard EN 301 539, clause 11.2.4.2 Void does not require 2.4.2 Page Title for non-web software, it is still required by US 508.
Refer to Understanding 2.4.2 Page titled for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- In a set of pages, give each a unique title
- List the unique text string first in a concatenated title
Level 3
- No level 3 design tasks for this requirement
Level 1
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
Manual
Screen reader
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.
Rationale
This requirement ensures that when users navigate sequentially through content, they encounter information in an order that is consistent with the meaning of the content and can be operated from the keyboard.
When content relies on sequential navigation for the user to understand it, it is essential for the focus order to match the visual flow of the content, such as from left to right and top to bottom. If there is more than one order that preserves meaning and operability, such as navigating cells in a table by row or by column, either order may satisfy the requirement.
Refer to Understanding 2.4.3 Focus order for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- Specify the tab order
- Ensure all mouse-operable components are reachable by keyboard
- Reduce tabbing by effective grouping of elements
- Choose standard HTML elements, where possible
- Where a component has multiple mouse operations, notate the keyboard equivalent
Level 2
- No level 2 design tasks for this requirement
Level 3
- No level 3 design tasks for this requirement
Level 1
- Ensure interactive elements are reachable with the keyboard
- Where possible, achieve the desired tab order by adjusting the DOM, rather than overriding the tabindex
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
- No automated checks identify issues specific to this requirement
Manual
Screen reader
- No screen reader tests specific to this requirement
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.
Rationale
This requirement ensures the purpose of a link is clear and easy to understand for all users. Whenever possible, the text of the link should describe its purpose without needing additional context.
Some assistive technologies provide a list of all links on the page to its user. If the text of the links do not clearly give the purpose, or if multiple links with the same name point to different targets (e.g., “read more”), users are forced to locate the link on the page and search surrounding information for context.
When it is not possible to provide descriptive link text, the content that provides the context must be in the same sentence or be associated with the link programmatically. Ideally, this descriptive content should precede the link, so that users who read content sequentially encounter the link context before the link.
Exception: An exception to this requirement is where the purpose of a link would be ambiguous to all users in general. For example, a game may create suspense for all users by presenting links with no indication of what the links will do until activated. However, whatever context is available must be programmatically associated with the link.
Note: In non-web software, a “link” is any non-UI-control text string or image that behaves like a hypertext link.
See Applying WCAG to Non-Web Information and Communications Technologies (external link to WCAG2ICT).Refer to Understanding 2.4.4 Link purpose (in context) for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
Level 3
- No level 3 design tasks for this requirement
Level 1
Level 2
Level 3
- No level 3 developer tasks for this requirement
Supplemental techniques
- Review common failures for 2.4.4 Link purpose (in context)
- Identifying the purpose of a link using link text combined with programmatically determined link context: When the link text alone is insufficient to provide proper context, additional information can be programmatically determined from relationships with a link, which when combined with the link text, will offer context. For example, in HTML information that is programmatically determined link context includes text that is in the same paragraph, list, or table cell.
Automated
Manual
Screen reader
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.
Rationale
This requirement ensures users are able to locate information in a way that best suits their needs. With access to multiple ways of locating information, users may need one way over another. For example, a user may need to use a document’s search function to locate specific information rather than scrolling through a table of contents. Alternatively, a user who needs to understand the content’s structure will find a table of contents or site map more useful.
Note: Consistent with Applying WCAG to Non-Web Information and Communications Technologies (external link to WCAG2ICT), an individual document or software program (not in a set) should mark this requirement N/A because it applies only to things that appear in a set. Refer to the definitions of set of documents and set of software programs to determine when a group of documents or software is considered a set. These definitions require that every item in the set be independently reachable, and not include a “step in a process” which cannot be reached in any other way.
Refer to Understanding 2.4.5 Multiple ways for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- No level 2 design tasks for this requirement
Level 3
Level 1
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
- No automated checks identify issues specific to this requirement
Manual
Screen reader
- No screen reader tests specific to this requirement
Headings and labels describe topic or purpose.
Rationale
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:
- Enable users to easily navigate to sections of interest and understand the structure and relationships of content.
- Help users with cognitive disabilities to read and understand better.
- Help low-vision users focus on relevant content.
- Need not be lengthy. A word may suffice if it provides an appropriate cue. Because screen reader users often use headings to navigate through content, the headings must make sense when read out of context and they must accurately describe the content that follows them. Similarly, descriptive labels allow all users to quickly understand the purpose of interactive components such as input.
Note 1: Headings are used to describe sections of content while labels are used with controls. In some cases, it may be unclear whether a piece of static text should be a heading or a label. But whether treated as a label or a heading, the requirement is the same.
Note 2: This requirement does not mean that headings and labels must exist in all types of content. It requires that if headings or labels are provided, they must be descriptive. When labeling is ”required” is covered in 3.3.2 Labels or Instructions. Also note that headings and labels must meet 1.3.1 Info and Relationships.
Refer to Understanding 2.4.6 Headings and labels for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
Level 2
- No level 2 design tasks for this requirement
Level 3
- No level 3 design tasks for this requirement
Level 1
- No level 1 developer tasks for this requirement
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
Manual
- Check labeling, link names, and page titles
- Read text for clarity; check for foreign and sensory words
Screen reader
Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
Rationale
This requirement ensures that the keyboard focus indicator can be visually located so that a person knows which element has the keyboard focus. All focus indicators should be visible and distinguishable.
Refer to Understanding 2.4.7 Focus visible for more information on status, intent, benefits, and techniques (external link to W3C).
Level 1
Level 2
Level 3
- No level 3 design tasks for this requirement
Level 1
- When overriding the default focus indicator, confirm focus is highly visible
- Follow core considerations in reducing effort by understanding what you get from design
- Unit test - confirm component keyboard interaction
- Unit test - check tab order
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Supplemental technique
- G195 Using an developer-supplied, highly visible focus indicator: When using an developer-supplied focus indicator, you must also ensure the indicator is highly visible when platform high-contrast styles are in place. With operating system high contrast activated, make sure keyboard and mouse focus indicators are easily distinguishable. One way to confirm is to ensure the focus indicator achieves sufficient contrast or relative luminence, as per requirement 1.4.1 Use of color and 1.4.3 Contrast (minimum).
Automated
Manual
- Check focus indicator
- Check tab or navigation order
- Check component keyboard interaction
- Check pointer hover
- Check pointer operations
Screen reader
All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture.
Rationale
This requirement ensures users can operate interactive content with a simple action.
The key intended beneficiaries are users with some physical disabilities, who may lack the ability to carry out complex gestures on mobile devices or other touchscreens. When designers and developers create a custom gesture, they need to ensure it is a simple action using a single contact point, or that there is a simple action to achieve the same result.
An example of a multipoint gesture is a two-finger pinch to zoom. An example of a path-based gesture is a swipe-up since the direction of the swipe — it’s path — determines the interpreted action.
Note: This requirement does not apply to operating system and browser gestures, which are not under the developer’s control. Most devices have platform accessibility features which offer alternatives for device-based complex gestures.
Essential Exception: Multipoint or patterned gestures such as those that require the drawing of a specific shape are allowed if that is the only way to achieve something, such as a user’s signature. Note that in many cases a signature may not be essential if there are other acceptable ways to, for instance, validate a user’s identify or capture their consent.
Refer to Understanding 2.5.1 Pointer Gestures for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- Provide an ability to complete all tasks with clicks, double clicks and other simple pointer actions
- Do not rely on multipoint gestures like pinch to zoom for custom widgets
- Do not rely on swiping or path-based gestures for custom widgets
Level 3
- No level 3 design tasks for this requirement
Level 1
- Follow core considerations in reducing effort by understanding what you get from design
- Unit test - confirm component keyboard interaction
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
- No automated checks identify issues specific to this requirement
Manual
Screen reader
For functionality that can be operated using a single pointer, completion of the function is on the up-event with an ability to abort, undo, or reverse the outcome.
Rationale
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:
- No Down Event: The down-event of the pointer is not used to execute any part of the function
- Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion
- Up Reversal: The up-event reverses any outcome of the preceding down-event
- Essential: Completing the function on the down-event is essential
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 toabort
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 ofup reversal
. Finally, a piano keyboard emulator is an example of a function that is down-eventessential
. A physical piano plays a note when the piano key is pressed, and any emulator must also do so to approximate the experience.Refer to Understanding 2.5.2 Pointer cancellation for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement?
Level 2
- No level 2 design tasks for this requirement?
Level 3
Level 1
- Follow core considerations in reducing effort by understanding what you get from design
- Unit test - confirm component keyboard interaction
Level 2
Level 3
- No level 3 developer tasks for this requirement
Automated
- No automated checks identify issues specific to this requirement
Manual
Screen reader
For user interface components with labels that include text or images of text, the accessible name contains the text that is presented visually.
Rationale
The requirement ensures that a component’s visible text label is the same as (or included in) the accessible name for the component. This makes the visual label for controls to be a trigger for speech activation. It primarily benefits users of speech recognition, but it also benefits low-vision and blind users who use a screen reader.
The accessible name is the text that is programmatically associated with the component — what an assistive technology will use. A screen reader will announce the accessible name when it lands on a button or an input field, so if users still retain the ability to see the screen, it can be confusing if what is announced doesn’t match what they see. A similar situation can occur when the blind user only knows how to refer to the accessible name based on what the screen reader renders, while a sighted colleague or remote Help-desk may only see the visible label.
More crucially, when users of speech recognition navigate around a page by voice, they can say the accessible name of the component to perform operations. If the visible label is different from the accessible name, two unwelcome things can happen. The first is the user will not be able to say the visible label to interact with the item. The second is that users may accidentally trigger the wrong component by saying its accessible name, if the visible label is not the same.
These problems are avoided by ensuring that the visible label is also the programmatic name of the component — or that the label’s text is included in the accessible name, preferably at the beginning.
Refer to Understanding 2.5.3 Label in name for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- No level 2 design tasks for this requirement
Level 3
- No level 3 design tasks for this requirement
Level 1
- No level 1 developer tasks for this requirement
Level 2
Level 3
- No level 3 developer tasks for this requirement
Automated
Manual
- No manual tests specific to this requirement
Screen reader
Functionality that can be operated by motion can also be operated by user interface components, and the motion trigger can be disabled.
Rationale
This requirement ensures that the page/application doesn’t rely solely on device motion to control the page content.
It primarily benefits users who are unable to physically manipulate devices and those who inadvertently trigger motion features due to tremors. Where designers and developers offer functionality that is triggered by motion, they must provide an alternative accessible means of operation and also provide an ability to disable motion as an interaction method.
An example of a motion actuation feature is a Shake To Undo feature. This can be made accessible by providing a user setting to disable the feature and offering an
Undo
button to perform the same action.Spatial Exception: This requirement concerns input through sensors which respond directly to motions such as gesturing towards, tilting, or shaking a device. It does not cover the movement of users through space as registered by geolocation sensors or beacons.
Accessibility Supported Exception: Motion can be the sole means of operation where it triggers functionality through an accessibility supported interface, such as using eye movement detected by a camera as an alternative input device.
Essential Exception: This requirement does not apply where the motion is essential for the function, and, disabling or, bypassing it would invalidate the activity. A pedometer that relies on device motion to count steps is an example of such an essential activity.
Refer to Understanding 2.5.4 Motion actuation for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
**Level 3
- No level 3 design tasks for this requirement
Level 1
- Follow core considerations in reducing effort by understanding what you get from design
- Unit test - confirm component keyboard interaction
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
- No automated checks identify issues specific to this requirement
Manual
Screen reader
The default human language of Web pages, non-web documents, or software can be programmatically determined.
Rationale
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 thatlocale / language
would comply with this requirement. Applications that do not use that setting, but instead use an accessibility-supported method for exposing the human language of the software would also comply.Refer to Understanding 3.1.1: Language of Page for more information on intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- No level 2 design tasks for this requirement
Level 3
- No level 3 design tasks for this requirement
Level 1
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
Manual
- Check the value of the
lang
attribute reflects the primary language used by the page
Screen reader
The human language of each passage or phrase in the content can be programmatically determined.
Rationale
This requirement ensures that developers clearly identify language changes for any portion of the content from the primary language on a page. The user agents and the assistive technologies need this information to correctly present content written in multiple languages, using the presentation and pronunciation rules for that language.
Note 1: There are some software and non-web document technologies where there is no assistive technology supported method for marking the language for the different passages or phrases in content, and it would not be possible to meet this requirement with those technologies.
Note 2: While the European standard EN 301 539, clause 11.3.1.2 Void does not require 3.1.2 Language of Parts for non-web software, it is still required by US 508.
Exception: Proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text are excluded from this requirement.
Refer to Understanding success criterion 3.1.2: Language of Parts for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- No level 2 design tasks for this requirement
Level 3
Level 1
- No level 1 developer tasks for this requirement
Level 2
- No level 2 developer tasks for this requirement
Level 3
Automated
Manual
Screen reader
When any component receives focus, it does not initiate a change of context.
Rationale
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:
- Forms submitted automatically when a component receives focus.
- New windows launched when a component receives focus.
- Focus is changed to another component when a component receives focus.
Note: Some compound documents and their user agents are designed to provide different viewing and editing functionality depending on which portion of the compound document the user moves focus to. For example, a presentation can contain an embedded spreadsheet where menus and toolbars change based upon whether the user interacts with the presentation content or the embedded spreadsheet content. If an additional mechanism, such as a menu choice or special keyboard command, allows this change of context, then even though a focus change may trigger this context change, such a compound document would include a means of changing context without a change of focus and so would pass. See Guidance on Applying WCAG to Non-Web Information and Communications Technologies (WCAG2ICT)
Refer to Understanding success criterion 3.2.1: On Focus for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- No level 2 design tasks for this requirement
Level 3
Level 1
- No level 1 developer tasks for this requirement
Level 2
- No level 2 developer tasks for this requirement
Level 3
Automated
Manual
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.
Rationale
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:
- Opening a new window
- Moving focus to a different component
- Going to a new page (including anything that would look to a user as if they had moved to a new page)
- Significantly re-arranging the content
“Changing the setting” of any user interface component is changing some aspect in the control that will persist when the user is no longer interacting with it. So selecting a checkbox or radio button, entering text into a text field, or changing the selected option in a list control changes its setting. In each situation, a user would need prior notice of changes in context. Activating a link or a button does not “change the setting”, and so does not fall under this requirement.
Refer to Understanding success criterion 3.2.2: On Input for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- No level 2 design tasks for this requirement
Level 3
Level 1
- No level 1 developer tasks for this requirement
Level 2
- No level 2 developer tasks for this requirement
Level 3
Automated
Manual
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.
Rationale
This requirement involves designing a consistent layout that enables users to predict where repeated elements in content appear, allowing quick navigation. For example, a low-vision user may depend on a search field that appears in the same location on each page of a Web site. Or, to better locate the home link in the left navigation area, a low-vision user may depend on the link appearing in the same relative order on each of a Web site’s pages.
This requirement does not restrict removing or adding content. It requires only that content that is repeated in multiple places remain in the same relative order. For example, links may be removed from the left navigation area of a Web site as a user navigates the site but the links that are present must remain in the same relative order.
Note: This requirement applies only to things that appear in a set, and is not applicable to individual non-web documents and software programs (not in a set). Refer to the definitions of set of documents and set of software programs to determine when a group of documents or software programs is considered a set, as well as the WCAG2ICT 3.2.3 guidance. When this requirement doesn’t apply, mark it as ‘N/A’ in a conformance report.
Refer to Understanding 3.2.3 Consistent Navigation for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
- No level 1 design tasks for this requirement
Level 2
- No level 2 design tasks for this requirement
Level 3
Level 1
- No level 1 developer tasks for this requirement
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
- No automated checks identify issues specific to this requirement
Manual
Components that have the same functionality within a set of content are identified consistently.
Rationale
This requirement requires consistent identification of functional elements within a set of content such as web pages on a web site, documents in a library and components in a software application. When identical functions have different labels (identification), the content can be difficult to users with disability and users who rely on their familiarity with the functions.
This requirement also applies to alternative text. If icons or other non-text content has the same functionality in different content sets, then the alternative text must be the same.
Note: Individual non-web documents and software programs (not in a set) should mark this requirement N/A because it applies only to things that appear in a set. Refer to the definitions of set of documents and set of software programs to determine when a group of documents or software programs is considered a set, as well as the WCAG2ICT 3.2.4 guidance.
Refer to Understanding 3.2.4 Consistent Identification for more information on exceptions, intent, benefits, and techniques (external link to W3C).
Level 1
Level 2
- No level 2 design tasks for this requirement
Level 3
- No level 3 design tasks for this requirement
Level 1
- No level 1 developer tasks for this requirement
Level 2
- No level 2 developer tasks for this requirement
Level 3
- No level 3 developer tasks for this requirement
Automated
- No automated checks identify issues specific to this requirement
Manual
Screen Reader
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.
Rationale
The requirement ensures users are aware that an input error has occurred and can determine what is wrong. The error message should be as specific and detectable as possible.
For example, if an unsuccessful form submission occurs due to input errors, simply re-displaying the form with a visual indicator for each bad field may be insufficient notification that errors occurred. The visual indicator may not be perceivable to a screen reader user and the form may be abandoned as not functional. Clear text messages are required.
“Input error” is defined as information provided by the user that is not accepted. This includes:
- Information that is required but omitted by the user, or
- Information that is provided by the user but that falls outside the required data format or allowed values.
Refer to Understanding 3.3.1 Error Identification for more information on exceptions, intent, benefits, and techniques (external link to W3C).