W3C Accessibility Guidelines (WCAG) 3.0

W3C Editor's Draft

More details about this document
This version:
https://w3c.github.io/wcag3/guidelines/
Latest published version:
https://www.w3.org/TR/wcag-3.0/
Latest editor's draft:
https://w3c.github.io/wcag3/guidelines/
History:
https://www.w3.org/standards/history/wcag-3.0/
Commit history
Editors:
(Library of Congress)
(Oracle)
(Nomensa)
(W3C)
(TetraLogical)
(Intel Corporation)
Former editors:
Michael Cooper, Staff Contact, 2016-2023 (W3C)
Shawn Lauriat, Editor, 2016-2023 (Google, Inc.)
Wilco Fiers, Project Manager, 2021-2023 (Deque Systems, Inc.)
Feedback:
GitHub w3c/wcag3 (pull requests, new issue, open issues)
public-agwg-comments@w3.org with subject line [wcag-3.0] … message topic … (archives)

Abstract

W3C Accessibility Guidelines (WCAG) 3.0 will provide a wide range of recommendations for making web content more accessible to users with disabilities. Following these guidelines will address many of the needs of users with blindness, low vision and other vision impairments; deafness and hearing loss; limited movement and dexterity; speech disabilities; sensory disorders; cognitive and learning disabilities; and combinations of these. These guidelines address accessibility of web content on desktops, laptops, tablets, mobile devices, wearable devices, and other web of things devices. The guidelines apply to various types of web content including static, dynamic, interactive, and streaming content; visual and auditory media; virtual and augmented reality; and alternative access presentation and control. These guidelines also address related web tools such as user agents (browsers and assistive technologies), content management systems, authoring tools, and testing tools.

Each guideline in this standard provides information on accessibility practices that address documented user needs of people with disabilities. Guidelines are supported by multiple requirements and assertions to determine whether the need has been met. Guidelines are also supported by technology-specific methods to meet each requirement or assertion.

This specification is expected to be updated regularly to keep pace with changing technology by updating and adding methods, requirements, and guidelines to address new needs as technologies evolve. For entities that make formal claims of conformance to these guidelines, several levels of conformance are available to address the diverse nature of digital content and the type of testing that is performed.

See WCAG 3.0 Introduction for an introduction and links to WCAG technical and educational material.

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C standards and drafts index.

This is an update to the W3C Accessibility Guidelines (WCAG) 3.0. It includes a restructuring of the guidelines and first draft decision trees for three Guidelines: Clear meaning, Image alternatives, and Keyboard focus appearance.

To comment, file an issue in the W3C wcag3 GitHub repository. The Working Group requests that public comments be filed as new issues, one issue per discrete comment. It is free to create a GitHub account to file issues. If filing issues in GitHub is not feasible, email public-agwg-comments@w3.org (comment archive). In-progress updates to the guidelines can be viewed in the public editors’ draft.

This document was published by the Accessibility Guidelines Working Group as an Editor's Draft.

Publication as an Editor's Draft does not imply endorsement by W3C and its Members.

This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent that the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 03 November 2023 W3C Process Document.

1. Introduction

This section (with its subsections) provides advice only and does not specify guidelines, meaning it is informative or non-normative.

Plain language summary of Introduction

End of summary for Introduction

What’s new in this version of WCAG 3.0?

This draft includes an updated list of the potential Guidelines and Requirements that we are exploring. The list of Requirements is longer than the list of Success Criteria in WCAG 2.2. This is because:

The final set of Requirements in WCAG 3.0 will be different from what is in this draft. Requirements will be added, combined, and removed. We also expect changes to the text of the Requirements. Only some of the Requirements will be used to meet the base level of conformance.

The Requirements are grouped into the following sections:

The purpose of this update is to demonstrate a potential structure for guidelines and indicate the current direction of the WCAG 3.0 conformance. Please consider the following questions when reviewing this draft:

To provide feedback, please file a GitHub issue or email public-agwg-comments@w3.org (comment archive).

1.1 About WCAG 3.0

This specification presents a new model and guidelines to make web content and applications accessible to people with disabilities. The W3C Accessibility Guidelines (WCAG) 3.0 support a wide set of user needs, use new approaches to testing, and allow frequent maintenance of guidelines and related content to keep pace with accelerating technology change. WCAG 3.0 supports this evolution by focusing on the functional needs of users. These needs are then supported by guidelines written as outcome statements, requirements, assertions, and technology-specific methods to meet those needs.

WCAG 3.0 is a successor to Web Content Accessibility Guidelines 2.2 [WCAG22] and previous versions, but does not deprecate WCAG 2. It will also incorporate some content from and partially extend User Agent Accessibility Guidelines 2.0 [UAAG20] and Authoring Tool Accessibility Guidelines 2.0 [ATAG20]. These earlier versions provided a flexible model that kept them relevant for over 15 years. However, changing technology and changing needs of people with disabilities have led to the need for a new model to address content accessibility more comprehensively and flexibly.

There are many differences between WCAG 2 and WCAG 3.0. The WCAG 3.0 guidelines address accessibility of web content on desktops, laptops, tablets, mobile devices, wearable devices, and other Web of Things devices. The guidelines apply to various types of web content, including static, dynamic, interactive, and streaming content; visual and auditory media; virtual and augmented reality; and alternative access presentation and control. These guidelines also address related web tools such as user agents (browsers and assistive technologies), content management systems, authoring tools, and testing tools.

Each guideline in this standard provides information on accessibility practices that address documented user needs of people with disabilities. Guidelines are supported by multiple requirements to determine whether the need has been met. Guidelines are also supported by technology-specific methods to meet each requirement.

Content that conforms to WCAG 2.2 levels A and AA is expected to meet most of the minimum conformance level of this new standard but, since WCAG 3.0 includes additional tests and different scoring mechanics, additional work will be needed to reach full conformance. Since the new standard will use a different conformance model, the Accessibility Guidelines Working Group expects that some organizations may wish to continue using WCAG 2, while others may wish to migrate to the new standard. For those that wish to migrate to the new standard, the Working Group will provide transition support materials, which may use mapping and other approaches to facilitate migration.

1.2 Section status levels

As part of the WCAG 3.0 drafting process each normative section of this document is given a status. This status is used to indicate how far along in the development this section is, how ready it is for experimental adoption, and what kind of feedback the Accessibility Guidelines Working Group is looking for.

2. GuidelinesPlaceholder

This section (with its subsections) provides requirements which must be followed to conform to the specification, meaning it is normative.

Plain language summary of Guidelines

The following guidelines are being considered for WCAG 3.0. They are currently a list of topics which we expect to explore more thoroughly in future drafts. The list includes current WCAG 2 guidance and additional requirements. The list will change in future drafts.

Unless otherwise stated, requirements assume the content described is provided both visually and programmatically.

End of summary for Guidelines

Editor's note

The individuals and organizations that use WCAG vary widely and include web designers and developers, policy makers, purchasing agents, teachers, and students. To meet the varying needs of this audience, several layers of guidance will be provided including guidelines written as outcome statements, requirements that can be tested, assertions, a rich collection of methods, resource links, and code samples.

The following list is an initial set of potential guidelines and requirements that the Working Group will be exploring. The goal is to guide the next phase of work. They should be considered drafts and should not be considered as final content of WCAG 3.0.

Ordinarily, exploratory content includes editor's notes listing concerns and questions for each item. Because this Guidelines section is very early in the process of working on WCAG 3.0, this editor's note covers most of the content in this section. Unless otherwise noted, all items in the list as exploratory at this point. It is a list of all possible topics for consideration. Not all items listed will be included in the final version of WCAG 3.0.

The guidelines and requirements listed below came from analysis of user needs that the Working Group has been studying, examining, and researching. They have not been refined and do not include essential exceptions or methods. Some requirements may be best addressed by authoring tools or at the platform level. Many requirements need additional work to better define the scope and to ensure they apply correctly to multiple languages, cultures, and writing systems. We will address these questions as we further explore each requirement.

Additional Research

One goal of publishing this list is to identify gaps in current research and request assistance filling those gaps.

Editor's notes indicate the requirements within this list where the Working Group has not found enough research to fully validate the guidance and create methods to support it or additional work is needed to evaluate existing research. If you know of existing research or if you are interested in conducting research in this area, please file a GitHub issue or send email to public-agwg-comments@w3.org (comment archive).

2.1 Image and media alternativesDeveloping

2.1.1 Image alternatives

Users have equivalent alternatives for images.

Which foundational requirements apply?

For each image:

  1. Would removing the image impact how people understand the page?
  2. Is the image presented in a way that is available to user agents and assistive technology?
  3. Is an equivalent text alternative available for the image?
Foundational requirement: Decorative imageDeveloping

Decorative image is programmatically hidden.

Foundational requirement: Equivalent text alternativeDeveloping

Equivalent text alternative is available for image that conveys content.

Foundational requirement: Detectable imageDeveloping

Image is programmatically determinable.

Supplemental requirement: Image roleExploratory

The role and importance of the image is programmatically indicated.

Supplemental requirement: Image typeExploratory

The image type (photo, icon, etc.) is indicated.

Supplemental requirement: Editable alternativesExploratory
Editor's note

Needs additional research

Auto generated text descriptions are editable by content creator.

Assertion: Style guideExploratory

Text alternatives follow an organizational style guide.

2.1.2 Media alternatives

Users have equivalent alternatives for media content.

Requirement: Descriptive transcriptsExploratory

A transcript is available whenever audio or visual alternatives are used.

Requirement: Findable media alternativesExploratory
Editor's note

Needs additional research

Media that has the desired media alternatives (captions, audio description, and descriptive transcripts) can be found.

Requirement: Preferred languageExploratory
Editor's note

Needs additional research

Equivalent audio alternatives are available in the preferred language.

Requirement: Non-verbal cuesExploratory
Editor's note

Needs additional research

Media alternatives explain nonverbal cues, such as tone of voice, facial expressions, body gestures, or music with emotional meaning.

2.1.3 Non-text alternatives

Users have alternatives available for non-text, non-image content that conveys context or meaning.

Requirement: Non-text contentExploratory
Editor's note

Needs additional research

Equivalent text alternatives are available for non-text, non-image content that conveys context or meaning.

2.1.4 Captions

Where there is audio content in media, there are equivalent synchronized captions.

Foundational requirement: Captions existDeveloping

Text alternatives to the information conveyed by the audio track exist.

Foundational requirement: Captions are findableDeveloping

Mechanisms exist to help users find text alternatives to the auditory information conveyed by media.

Foundational requirement: Captions are controllableDeveloping

The media player provides a mechanism to turn the captions on and off.

Foundational requirement: Captions are in the target user's languageDeveloping

When captions are used as a text alternative for an audio track, they are provided in the target user’s language for the media.

Foundational requirement: Captions are equivalent to audio contentDeveloping

Captions are equivalent and equal in content to that of audio.

Foundational requirement: Captions are synchronizedDeveloping

Captions are in sync with the visual media.

Foundational requirement: Captions are consistentDeveloping

The captions are presented consistently throughout the media, and across several related productions, unless exceptions are warranted. This includes consistent styling and placement of the captions text and consistent methods for identifying speakers, languages, and sounds.

Foundational requirement: Captions do not obstruct visual informationDeveloping

In visual media, captions are placed on the screen so that they do not obstruct important visual information.

Foundational requirement: Speakers are identifiedDeveloping

The speaker is identified in the captions. If there is only one speaker in the media, the speaker can be identified in the media description or at the beginning of the closed captioning. If there is more than one speaker in the media, then changes in speaker need to be identified throughout.

Foundational requirement: Languages of speech are identifiedDeveloping

When there is more than one language spoken in media, the captions identify the language spoken by each speaker.

Foundational requirement: Sounds are identified or describedDeveloping

Significant sounds, including sound effects and other non-spoken audio, are identified or described in the captions.

Foundational requirement: Captions are adaptableDeveloping

The appearance of captions and the language of captions are adaptable.

Supplemental requirement: Alternative language versions are availableDeveloping

Captions in a different language than that of the media are available so that the user can choose to view captions in their preferred language.

Supplemental requirement: Enhanced features to interact with captions are availableDeveloping

Enhanced features that allow users to interact with captions are available.

Supplemental requirement: Captions are available in 360-degree space in augmented, virtual, and extended realitiesDeveloping

In augmented, virtual, and extended reality environments, captions are available in 360-degree space.

Supplemental requirement: Speakers are indicated visually in augmented, extended, and virtual realitiesDeveloping

In augmented, virtual, and extended environments, a visual indicator or signal, in addition to audio, is available to direct users toward the source of a sound or to indicate who is the speaker.

Assertion: Style guideDeveloping

The captions are following an organization’s style guide.

  • Name of the style guide
  • Version (if any)
  • Date of release
  • Description
  • Examples of how core WCAG guidelines are addressed
Assertion: Testing with usersDeveloping

The organization conducted tests with users who need captions and fixed issues based on findings.

  • Types of disabilities each user had
  • Number of users (for each type of disability)
  • Date of testing
  • Examples of fixed issues based on the results
Assertion: Video player selectionDeveloping

The organization uses a video player that supports captions.The video player supports closed captions in a standard caption format, or an open captions format.

  • Name of the video player
  • Caption format
Assertion: Contribution by producerDeveloping

During the video production process, the video producer converts the dialogue, along with other important sounds and music, into a caption file format.

  • Names of the videos
  • File types
  • Number/Name of video producer
Assertion: Video player controls for captionsDeveloping

The organization has selected a video player that provides controls for turning captions on and off. In the video player controls, there must be at least one method to turn captions on or off.

  • Name of the video player
Assertion: Adaptable video playerDeveloping

The organization uses a video player that allows the user to personalize the appearance and location of closed captions. An individual’s need for modification will vary among people. The organization should allow for adjustment to these styles, including but not limited to: font size, font weight, font style, font color, background color, background transparency, and placement.

  • Name of the video player
  • Customizable styles
Assertion: AR, VR, or XR video playerDeveloping

The organization uses a video player that supports captions remaining directly in front of the user in a 360-degree augmented, virtual, or extended environment (AR, VR, or XR). In these spaces, the user feels surrounded by content. As the user moves in this space, any caption provided will appear directly in front of the user regardless of where they are looking.

  • Name of the video player
Assertion: Subtitles in other languagesDeveloping

The organization provides captions in one or more alternative languages for the most common languages in their market. Typically called subtitles when in another language, closed captions in multiple languages assists in understanding the content and learning another language.

  • Original language for video
  • Languages for subtitles
Assertion: Visual indicators in 360 fieldDeveloping

The organization provides visual indicators in extended reality environments to indicate where the speaker is or the direction of a sound when audio is heard from outside the current view. As users move in extended reality environments, the position of the audio may stay the same. Users can personalize the visual indicators by selecting from a set of options.

Assertion: Using human captionersDeveloping

For live events, the organization has a human captioner providing live captions to the audience using CART.

  • Name of the captioner or service provider
Assertion: Perfect set of alternativesDeveloping

As part of the organization’s standard media production procedures, the video producer creates the closed caption files, audio description, and descriptive transcript during the production cycle and then uploads them to their appropriate places during the publishing process.

  • Alternatives provided

2.1.5 Audio descriptions

Where there is visual content in media, there is an equivalent synchronized audio description.

Foundational requirement: Audio descriptions existDeveloping

An audio alternative to the visual information conveyed in visual media exists.

Foundational requirement: Audio description is findableDeveloping

Mechanisms exist to help users find audio alternatives to the visual information conveyed in visual media.

Foundational requirement: Audio description is controllableDeveloping

The media player provides a mechanism to turn the audio description on and off.

Foundational requirement: Audio description is in the target user's languageDeveloping

When audio description is provided as an alternative for visual information, it is provided in the target user’s language for the media.

Foundational requirement: Audio description equitably describes important visual informationDeveloping

Information about actions, charts or informative visuals, scene changes, and on-screen text that are important and are not described or spoken in the main soundtrack are included in the audio description.

Foundational requirement: Audio description is synchronizedDeveloping

The audio description is in sync with the visual content.

Foundational requirement: Audio description does not overlap other audioDeveloping

Audio description is provided during existing pauses in dialogue and does not overlap other important audio.

Foundational requirement: Audio description is adaptableDeveloping

Mechanisms are available that allow users to control the audio description volume independently from the audio volume of the video and to change the language of the audio description, if multiple languages are provided.

Supplemental requirement: Extended audio descriptionDeveloping

In cases where the existing pauses in a soundtrack are not long enough, the video pauses the visual to extend the audio track and provides an extended audio description to describe all of important visual information.

Supplemental requirement: Alternative language versions are availableDeveloping

Audio description in alternative languages to that of the media are available so that the user can choose to listen to the audio description in their preferred language.

Assertion: Style guideDeveloping

The script for the audio description is following an organization’s style guide.

  • Name of the style guide
  • Version (if any)
  • Date of release
  • Description
  • Example(s) of core guideline(items)
Assertion: Testing with usersDeveloping

Tests with users who need audio description were conducted and fixed issues based on findings.

  • Type of disabilities each user had
  • Number of users (for each type)
  • Date of testing
  • Examples of fixed issues based on the results
Assertion: Reviewed by content creatorsDeveloping

The audio description was reviewed by the person who created the video.

  • Role of the creator
  • Number of creators (for each Role)
  • Date (Period) of review
  • Examples of fixed issues based on the feedback
Assertion: Using human describersDeveloping

For live events, the organization has a human describer providing live audio description to the audience using assistive listening devices.

Assertion: Perfect set of alternativesDeveloping

As part of the organization’s standard media production procedures, the video producer creates the closed caption files, audio description, and descriptive transcript during the production cycle and then uploads them to their appropriate places during the publishing process.

  • Alternatives provided

2.1.6 Figure captions

Users can view figure captions even if not focused at figure.

Requirement: Persistent captionsExploratory
Editor's note

Needs additional research

Figure captions persist or can be made to persist even if the focus moves away.

2.1.7 Single sense

Users have content that does not rely on a single sense or perception.

Requirement: Use of hueExploratory
Editor's note

Needs additional research

Information conveyed by graphical elements does not rely on hue.

Requirement: Use of visual depthExploratory
Editor's note

Needs additional research

Information conveyed with visual depth is also conveyed programmatically and/or through text.

Requirement: Use of soundExploratory

Information conveyed with sound is also conveyed programmatically and/or through text.

Requirement: Use of spatial audioExploratory

Information that is conveyed with spatial audio is also conveyed programmatically and/or through text.

2.2 Text and wording

2.2.1 Text appearance

Users can read visually rendered text.

Requirement: Maximum text contrastExploratory
Editor's note

Needs additional research

The rendered text against its background meets a maximum contrast ratio test for its text appearance.

Requirement: Minimum text contrastExploratory
Editor's note

Needs additional research

The rendered text against its background meets a minimum contrast ratio test for its text appearance.

Requirement: Text sizeExploratory
Editor's note

Needs additional research

The rendered text meets a minimum font size and weight.

Requirement: Text styleExploratory

The rendered text does not use a decorative or cursive font face.

2.2.2 Text-to-speech

Users can access text content and its meaning with text-to-speech tools.

Requirement: Text-to-speech supportedExploratory
Editor's note

Needs additional research

Text content can be converted into speech.

Requirement: Human languageExploratory

The human language of the view and content within the view is programmatically available.

Requirement: Semantic text appearanceExploratory
Editor's note

Needs additional research

Meaning conveyed by text appearance is programmatically available.

2.2.3 Clear languageDeveloping

Users can understand the content without having to process complex or unclear language.

Editor's note

This guideline will include exceptions for poetic, scriptural, artistic, and other content whose main goal is expressive rather than informative.

To ensure this guideline works well across different languages, members of AG, COGA, and internationalization (i18n) agreed on an initial set of languages to pressure-test the guidance. The five “guardrail” languages are:

  • Arabic
  • English
  • Hindi
  • Mandarin
  • Russian

We started with the six official languages of the United Nations (UN). Then we removed French and Spanish because they are similar to English. We added Hindi because it is the most commonly spoken language that is not on the UN list.

The group of five languages includes a wide variety of language features, such as:

  • Right-to-left text layout
  • Vertical text layout
  • Tonal sounds that affect meaning

This list doesn’t include every language, but it helps keep the work manageable while making the guidance more useful for a wide audience. We will work with W3C’s Global Inclusion community group, the Internationalization (i18n) task force, and others to review and refine the testing and techniques for these requirements. We also plan to create guidance for translating the guidelines into more languages in the future.

Foundational requirement: Clear structureDeveloping

Content has a meaningful and understandable structure that clearly indicates the purpose of each section.

Foundational requirement: Short blocks of textDeveloping

Content is organized into short paragraphs or “chunks” to help users understand and remember the information.

Foundational requirement: Sentence structureDeveloping

Sentences are streamlined to avoid unnecessary words or phrases and complex structures such as clauses within clauses that can make it hard for users to focus on the main point.

Foundational requirement: Common wordsDeveloping

Common words are used, and definitions are available for uncommon words that the target audience is unlikely to know.

Editor's note

This requirement will include tests and techniques for content that is intended for specialized audiences rather than the general public.

Foundational requirement: AbbreviationsDeveloping

Explanations are available for the first use of abbreviations, acronyms, initialisms, and numeronyms.

Foundational requirement: Non-literal languageDeveloping

Explanations or unambiguous alternatives are available for non-literal language, such as idioms and metaphors.

Foundational requirement: Verb tenseDeveloping

The verb tense used is easiest to understand in context.

Foundational requirement: Numerical supplementsDeveloping

Alternatives are provided for numbers and numerical concepts.

Foundational requirement: Unambiguous numerical formattingDeveloping

Numerical information includes sufficient context to avoid confusion when presenting dates, temperatures, time, and Roman numerals.

Foundational requirement: Visual aidsDeveloping

Visual aids are available to supplement and aid understanding of complex ideas in written content, such as processes, workflows, relationships, or chronological information.

Foundational requirement: SummariesDeveloping

A summary is available for documents and articles that have more than 300 words.

Supplemental requirement: Topic sentenceDeveloping

For content intended to inform the user, each paragraph begins with a sentence stating the aim or purpose.

Supplemental requirement: Unambiguous pronunciationDeveloping

For Arabic and Hebrew, where letters or diacritics needed for phonetic reading are often omitted, an alternative version is provided with these missing elements included.

Assertion: Review processDeveloping
  • The organization has a documented process to review content for clear language before publication.
  • If the organization uses AI tools to generate or alter content, the organization has a documented process for a human to review and attest that the content is clear and conveys the intended meaning.
Assertion: Style guideDeveloping
  • The organization has a documented style guide that includes guidance on clear language and a policy that requires editors to follow the style guide.
  • The style guide includes guidance on clear words as well as clear numbers, such as avoiding or explaining Roman numerals, removing numerical information that is not essential for understanding the content, and providing explanations of essential numerical information to aid users with disabilities that impact cognitive accessibility.
Assertion: Training policyDeveloping
  • The organization has documented training material for content editors that includes guidance on clear language and a policy that editors are required to complete the training regularly.

2.3 Interactive components

2.3.1 Keyboard focus appearanceDeveloping

Users can see which element has keyboard focus.

Which foundational requirements apply?

For each focusable item:

  1. Is the user agent default focus indicator used?
  2. Is the focus indicator defined by the author?
Foundational requirement: Custom indicatorDeveloping

A custom focus indicator is used with sufficient size, change of contrast, adjacent contrast, distinct style and adjacency.

Foundational requirement: User agent default indicatorDeveloping

Focusable item uses the user agent default indicator.

Supplemental requirement: Supplementary indicatorsExploratory

@@

Assertion: Style guideExploratory

Focus indicators follow an organizational style guide.

2.3.2 Pointer focus appearance

Users can see the location of the pointer focus.

Requirement: Pointer visibleExploratory

There is a visible indicator of pointer focus.

2.3.4 Expected behavior

Users have interactive components that behave as expected.

Requirement: Consistent interactionExploratory

Interactive components with the same functionality behave consistently.

Requirement: Consistent labelsExploratory

Interactive components with the same functionality have consistent labels.

Requirement: Consistent visual designExploratory

Interactive components that have similar function and behavior have a consistent visual design.

Requirement: Control locationExploratory
Editor's note

Needs additional research

Interactive components are visually and programmatically located in conventional locations.

Requirement: ConventionsExploratory
Editor's note

Needs additional research

Interactive components follow established conventions.

Requirement: Familiar componentExploratory

Conventional interactive components are used.

Requirement: Reliable positioningExploratory

Interactive components retain their position unless a user changes the viewport or moves the component.

2.3.5 Control information

Users have information about interactive components that is identifiable and usable visually and using assistive technology.

Requirement: Control contrastExploratory
Editor's note

Needs additional research

Visual information required to identify user interface components and states meet a minimum contrast ratio test, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author.

Requirement: Control importanceExploratory
Editor's note

Needs additional research

The importance of interactive components is indicated.

Requirement: Control labelsExploratory

Interactive components have visible labels that identify the purpose of the component.

Requirement: Control updatesExploratory

Changes to interactive components’ names, roles, values or states are visually and programmatically indicated.

Requirement: Distinguishable controlsExploratory

Interactive components are visually distinguishable without interaction from static content and include visual cues on how to use them.

Requirement: Field constraintsExploratory

Field constraints and conditions (required line length, date format, password format, etc.) are available.

Requirement: Input labelsExploratory

Inputs have visible labels that identify the purpose of the input.

Requirement: Label in nameExploratory

The programmatic name includes the visual label.

Requirement: Name, role, value, stateExploratory

Accurate names, roles, values, and states are available for interactive components.

2.4 Input / operation

2.4.1 Keyboard interface input

Users can navigate and operate content using only the keyboard.

Foundational requirement: All elements keyboard actionableDeveloping

All elements that can be controlled or activated by pointer, audio (voice or other), gesture, camera input, or other means can be controlled or activated from the keyboard interface.

Note

Here, and throughout this section, “camera input” refers to user control using a camera as a motion sensor to detect gestures of any type, for example “in the air” gestures. It does not include, for example, a static QR code image on a web page.

Foundational requirement: All content keyboard accessibleDeveloping

All content that can be accessed by other input modalities can be accessed using keyboard interface only.

Note 1

All content includes content made available via hovers, right clicks, etc.

Note 2

Other input modalities include pointing devices, voice and speech recognition, gesture, camera input, and any other other means of input or control.

Note 3

The All Elements Keyboard-Actionable requirement allows you to navigate to all actionable elements but if the next element is 5 screens down - you also need to be able to access all the content. Also if the content is in expanding sections - you need to not just open them but also access all of the content - not just its actionable elements.

Note 4

A menu that opens and closes is an interactive group that consists of an icon or label (which opens and closes the menu - and is therefore an interactive element) and a group of interactive elements inside.

Foundational requirement: Bidirectional navigationDeveloping

It is always possible to move forward and backward at each point using keyboard navigation.

Editor's note

We are considering making this require that the navigation be symmetrical (ie., if you navigate forward and then backward you always end up back in the same place) but are interested in comments on this.

Foundational requirement: Conflicting keyboard commandsDeveloping

Author generated keyboard commands do not conflict with standard platform keyboard commands or they can be remapped.

Foundational requirement: Keyboard navigable if responsiveDeveloping

If the page / view uses responsive design, the page / view remains fully keyboard navigable.

Foundational requirement: No keyboard trapDeveloping

It is always possible to navigate away from an element after navigating to, entering, or activating the element by using a common keyboard navigation technique, or by using a technique for exiting is described on the page / view or on a page / view earlier in the process where it is used.

Foundational requirement: User control of keyboard focusDeveloping

When the keyboard focus is moved, one of the following is true:

  • The focus was moved under direct user control;
  • A new view such as a dialog is introduced and focus is moved to that view;
  • The user is informed of the potential keyboard focus move before it happens and given the chance to avoid the move;
  • The keyboard focus moves to the next item in keyboard navigation order automatically on completion of some user action.
Note

Examples of where it may be useful to “jump the user to some other location” (after of course asking the user if they want to move there) would be:

  • a form message that says “If you answer no, you can skip questions 8 through 15, would you like to skip to question 16”; and
  • when a form error is detected on submit and a message says “There is an error on the page, would you like to jump to it” (especially if it also provided information on what the error was).
Foundational requirement: Relevant tab order keyboard focusDeveloping

Except for skip links and other elements that are hidden but specifically added to aid keyboard navigation, tabbing does not move the keyboard focus into content that was not visible before the Tab (or Shift + Tab) key was entered.

Note 1

Accordions, dropdown menus, and ARIA tab panels are examples of expandable content. According to this requirement, these would not expand simply because they include an element in the tab-order contained in them. They would either not expand or would not have any tab-order elements in them.

Note 2

For example, a menu that expands when you tab to it, but then uses arrow keys to navigate in it would pass. But a menu that expands and then requires you to tab through all the newly-visible elements to navigate past it would fail.

2.4.2 Physical or cognitive effort when using keyboard

Users can use keyboard without unnecessary physical or cognitive effort.

Foundational requirement: Logical keyboard focus orderDeveloping

The keyboard focus moves through content in an order and way that preserves meaning and operability.

Foundational requirement: Standard or described navigation keysExploratory

If any keyboard action needed to navigate, perceive, and operate the full content of the page / view is not a common keyboard navigation technique, then it is described in the page / view where it is required or on a page / view earlier in the process where it is used.

Note

Any platform related functions are not the responsibility of the author as long as they are not overridden by the content. Examples:

  • Tab and Shift + Tab to move through elements
  • Sticky Keys functionality that allows single key activation of multi-key commands
Foundational requirement: Preserve keyboard focusDeveloping

When keyboard focus moves from one context to another within a web page, whether automatically or by user request, the keyboard focus is preserved so that, when the user goes back to the previous context, the keyboard focus is restored to its previous location except if that location no longer exists.

Note 1

An example of this would be when a modal dialog or other pop up opens.

Note 2

Best practice on placing focus when the previous focus location no longer exists, is to put focus on the focusable location just before the one that was removed. An example of this would be a list of subject-matter tags in a document, with each tag having a delete button. A user clicks on the delete button in a tag in the middle of the tag list. When the tag is deleted, focus is placed onto the tag that was before the now-deleted tag.

Note 3

This is also quite useful when moving between pages but this would usually have to be done by the browser unless the user is in some process where that information is stored in a cookie or on the server between pages in the process so that it still has the old location when the person returns to the page.

Assertion: Comparable keyboard effortDeveloping

Our user interface design principles include minimizing the difference between the number of input commands required when using the keyboard interface only and the number of commands when using other input modalities.

Note

Other input modalities include pointer and voice.

2.4.3 Pointer input

Pointer input is consistent and all functionality can be done with simple pointer input in a time and pressure insensitive way.

Foundational requirement: Consistent pointer cancellation - set of pages / viewsDeveloping

The method of pointer cancellation is consistent for each type of interaction within or set of views except where it is essential to be different.

Note

Where it is essential to be different, it can be helpful to alert the user.

Foundational requirement: Pointer cancellationDeveloping

For functionality that can be activated using a simple pointer input, 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.
Note 1

An example of Abort would be dragging where there is a pickup action on button down but it can be cancelled by dropping in pickup point or anywhere other than the drop area.

Note 2

Examples of places where action on down-event may be essential include Dutch auction or game trigger.

Foundational requirement: Pointer pressure alternativeDeveloping

Specific pointer pressure is not the only way of achieving any functionality, except where specific pressure is essential to the functionality.

Note

Specific pressure would be essential to a paintbrush feature or advance signature verification.

Foundational requirement: Pointer speed alternativeDeveloping

Specific pointer speed is not the only way of achieving any functionality, except where specific pointer speed is essential to the functionality.

Note

Specific pointer speed would be essential to a paintbrush feature, advanced signature verification, or time constrained gaming.

Foundational requirement: Simple pointer inputDeveloping

Any functionality that uses pointer input other than simple pointer input can also be operated by a simple pointer input or a sequence of simple pointer inputs that do not require timing.

Note 1

Examples of pointer input that are not simple pointer input are double clicking, swipe gestures, multipoint gestures like pinching or split tap or two-finger rotor, variable pressure or timing, and dragging movements.

Note 2

Complex pointer inputs are not banned, they just can’t be the only way to accomplish an action.

Note 3

Simple pointer input is different than single pointer input and is more restrictive than simply using a single pointer.

2.4.4 Speech and voice input

Provide alternatives to speech input for those who cannot speak, and facilitate speech control for those for whom it is most effective.

Foundational requirement: Speech alternativeDeveloping

Speech input is not the only way of achieving any functionality except where a speech input is essential to the functionality.

Foundational requirement: Real-time bidirectional voice communicationDeveloping

Wherever there is real-time bidirectional voice communication, a real-time text option is available.

2.4.5 Input operation

Users have the option to use different input techniques and combinations and switch between them.

Foundational requirement: Change keyboard focus with pointer deviceDeveloping

If content interferes with pointer or keyboard focus behavior of the user agent, then selecting anything on the view with a pointer moves the keyboard focus to that interactive element, even if the user drags off the element (so as to not activate it).

Note

An example of this is: a user scrolls a document down six screens, then clicks on a paragraph with their pointer. The user then presses the tab key, which moves the focus to the first interactive component after the position on the screen that was clicked, rather than from the previous position, six screens up the document.

Foundational requirement: Content on hover or keyboard focusDeveloping

When receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, and the visual presentation of the additional content is controlled by the author and not by the user agent, all of 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 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 keyboard focus trigger is removed, the user dismisses it, or its information is no longer valid.

Note 1

Examples of additional content controlled by the user agent include browser tooltips created through use of the HTML title attribute.

Note 2

Custom tooltips, sub-menus, and other non-modal popups that display on hover and keyboard focus are examples of additional content covered by this criterion.

Note 3

This applies to content that appears in addition to the triggering interactive element itself. Since hidden interactive elements that are made visible on keyboard focus (such as links used to skip to another part of a view) do not present additional content they are not covered by this requirement.

Foundational requirement: Gesture alternativeDeveloping

Gestures are not the only way of achieving any functionality, except where a gesture is essential to the functionality.

Foundational requirement: Input method flexibilityDeveloping

Where functionality, including input or navigation, are achievable using different input methods, users have the option to switch between those input methods at any time.

Note

This does not mean that all input technologies (pointer, keyboard, voice, gesture) need to be supported in one’s content, but if an input modality is supported, it is supported everywhere in the content except where a particular input method is essential to the functionality.

Foundational requirement: Use without body movementDeveloping

Full or gross body movement is not the only way of achieving any functionality, except where full or gross body movement is essential to the functionality.

Note

This includes both detection of body movement and actions to the device (e.g., shaking) that require body movement.

2.4.6 Authentication

Provide alternatives to authentication for those who cannot use some authentication methods usable by people without disabilities.

Foundational requirement: Biometric identificationDeveloping

Use of a biometric is not the only way to identify or authenticate.

Foundational requirement: Voice identificationDeveloping

Voice is not the only way to identify or authenticate.

2.5 Error handling

2.5.1 Correct errors

Users know about and can correct errors.

Supplemental requirement: Error associationDeveloping

Error notifications are programmatically associated with the error source so that users can access the error information while focused on the source of the error.

Requirement: Error cause associationDeveloping

When an error occurs that results from a user interaction with an interactive element or component (aka a cause), the element or component is visually and programmatically associated with the trigger.

Supplemental requirement: Error cause in notificationDeveloping

When an error occurs that results from an interactive element or component (aka a cause), an indicator of the trigger is included in the error notification. If the interactive element or component is located in a different part of a process, then the page or step in the process is included in the error notification.

Requirement: Error identificationDeveloping

Errors are visually identifiable without relying on only text, only color, or only symbols.

Supplemental requirement: Error linkedDeveloping

When an error notification is not adjacent to the item in error, a link to the error is provided.

Supplemental requirement: Error locationDeveloping

Error notifications are visually collocated with the item in error within the viewport, or provide a link to the source of the error which, when activated, moves the focus to the error.

Supplemental requirement: Error notification labelDeveloping

Error notifications include text with at least two of the following:

  • Error notifications are identified with an error icon in text.
  • Error notifications use a color that differentiates the error from other content.
  • Error notifications are labeled with text that indicates its an error.
Foundational requirement: Error notificationDeveloping

Errors that can be automatically detected are identified and described to the user.

Requirement: Error persistsDeveloping

Error notifications persist until the user dismisses them or the error is resolved.

Foundational requirement: Error suggestionDeveloping

When an error occurs and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.

Supplemental requirement: Make errors distinctDeveloping

Use a culturally relevant and familiar error symbol, color, and text to indicate errors.

2.5.2 Prevent errors

When users are submitting information, at least one of the following is true:

  • Users can review, confirm, and correct information before submitting
  • Information is validated and users can correct any errors found, or
  • Users can undo submissions.
Supplemental requirement: Submission confirmationDeveloping

When users submit information as part of a process, users are notified that submission was completed and what information was provided.

Supplemental requirement: Validate after data entryDeveloping

During data entry, ensure data validation occurs after the user enters data.

Supplemental requirement: Validate as you goDeveloping

When completing a multi-step process, validation for errors is completed before the user moves to the next step in the process.

Techniques could include in line error handling as well as step by step validation.

2.6 Animation and movement

2.6.1 Avoid physical harm

Users do not experience physical harm from content.

Requirement: Audio shiftingExploratory
Editor's note

Needs additional research

Audio shifting designed to create a perception of motion is avoided, or can be paused or prevented.

Requirement: FlashingExploratory

Flashing or strobing beyond thresholds defined by safety standards are avoided, or can be paused or prevented.

Requirement: MotionExploratory
Editor's note

Needs additional research

Visual motion and pseudo-motion that lasts longer than 5 seconds is avoided, or can be paused or prevented.

Requirement: Motion from interactionExploratory
Editor's note

Needs additional research

Visual motion and pseudo-motion triggered by interaction is avoided or can be prevented, unless the animation is essential to the functionality or the information being conveyed.

2.7 Layout

2.7.1 Relationships

Users can determine relationships between content both visually and using assistive technologies.

Requirement: Clear relationshipsExploratory

The relationships between parts of the content is clearly indicated.

Requirement: Clear starting pointExploratory

The starting point or home is visually and programmatically labeled.

Requirement: Distinguishable relationshipsExploratory
Editor's note

Needs additional research

Relationships that convey meaning between pieces of content are programmatically determinable. Note: Examples of relationships include items positioned next to each other, arranged in a hierarchy, or visually grouped.

Requirement: Distinguishable sectionsExploratory
Editor's note

Needs additional research

Sections are visually and programmatically distinguishable.

2.7.2 Recognizable layouts

Users have consistent and recognizable layouts available.

Requirement: Consistent orderExploratory

The relative order of content and interactions remain consistent throughout a workflow. Note: Relative order means that content can be added or removed, but repeated items are in the same order relative to each other.

Requirement: Familiar layoutExploratory

Conventional layouts are available.

Requirement: Information about optionsExploratory

Information required to understand options is visually and programmatically associated with the options.

2.7.3 Orientation

Users can determine their location in content both visually and using assistive technologies.

Requirement: Current locationExploratory
Editor's note

Needs additional research

The current location within the view, multi-step process, and product is visually and programmatically indicated.

Requirement: Multi-step processExploratory

Context is provided to orient the user in a site or multi-step process.

Requirement: Contextual informationExploratory

Contextual information is provided to help the user orient within the product.

2.7.4 Structure

Users can understand and navigate through the content using structure.

Requirement: Section labelsExploratory

Major sections of content have within them well structured, understandable visual and programmatic headings.

Requirement: Section lengthExploratory
Editor's note

Needs additional research

Content is organized into short sections of related content.

Requirement: Section purposeExploratory

The purpose of each section of the content is clearly indicated.

Requirement: Single ideaExploratory

The number of concepts within a segment of text is minimized.

Requirement: Topic sentenceExploratory

For text intended to inform the user, each paragraph of text begins with a topic sentence stating the aim or purpose.

Requirement: White spacingExploratory

Whitespace separates chunks of content.

Requirement: TitleExploratory

Content has a title or high-level description.

Requirement: ListsExploratory

Three or more items of related data are presented as bulleted or numbered lists.

Requirement: Numbered stepsExploratory

Steps in a multi-step process are numbered.

2.7.5 No obstruction

Users can percive and operate user interface components and navigation without obstruction.

Foundational requirement: No obstructionsDeveloping

Content that is essential for a user’s task or understanding is not permanently covered by non-dismissible or non-movable elements.

Foundational requirement: Clearly dismissable content overlaysDeveloping

When content temporarily overlays other content, it must be clearly dismissible or movable via standard interaction methods and its presence does not disrupt critical screen reader announcements or keyboard focus

Foundational requirement: Disabled controlsDeveloping

If a control is disabled, then information explaining why it is disabled and what actions the user needs to take to enable it is provided visually nad programmatically.

Supplemental requirement: Stable layoutExploratory

Content does not shift or reflow in a way that causes users to lose their place or makes previously visible content inaccessible without explicit user action.

Supplemental requirement: Consistent positioningDeveloping

If elements are designed to be persistent (e.g., sticky headers/footers), their position is predictable and do not overlap with primary content in a way that makes it unreadable or unusable.

Supplemental requirement: Implicit misdirectionExploratory

The design should avoid scenarios where disabling a control implicitly suggests a false pathway or intentionally hides the correct one.

Supplemental requirement: No infinite scrollingDeveloping

Content does not include infinite scrolling.

2.8 Consistency across views

2.8.1 Consistency

Users have consistent and alternative methods for navigation.

Requirement: Consistent navigationExploratory

Navigation elements remain consistent across views within the product.

Requirement: Multiple waysExploratory

The product provides at least two ways of navigating and finding information (Search, Scan, Site Map, Menu Structure, Breadcrumbs, contextual links, etc.).

Requirement: Persistent navigationExploratory

Navigation features are available regardless of screen size and magnification (responsive design).

2.9 Process and task completion

2.9.1 Avoid cognitive tasks

Users can complete tasks without needing to memorize nor complete advanced cognitive tasks.

Requirement: Allow automated entryExploratory

Automated input from user agents, third-party tools, or copy-and-paste is not prevented.

Requirement: No cognitive testsExploratory

Processes, including authentication, can be completed without puzzles, calculations, or other cognitive tests (essential exceptions would apply).

Requirement: No memorizationExploratory
Editor's note

Needs additional research

Processes can be completed without memorizing and recalling information from previous stages of the process.

2.9.2 Adequate time

Users have enough time to read and use content.

Requirement: Adjust timing at startExploratory

For each process with a time limit, a mechanism exists to disable or extend the limit before the time limit starts.

Requirement: Adjust timing at timeoutExploratory

For each process with a time limit, a mechanism exists to disable or extend the time limit at timeout.

Requirement: Disable timeoutExploratory

For each process with a time limit, a mechanism exists to disable the limit.

2.9.3 Unnecessary steps

Users can complete tasks without unnecessary steps.

Requirement: Optional informationExploratory

Processes can be completed without being forced to read or understand unnecessary content.

Requirement: Optional inputExploratory

Processes can be completed without entering unnecessary information.

2.9.4 Avoid deception

Users do not encounter deception when completing tasks, unless essential to the task.

Foundational requirement: Changes in agreementDeveloping

A user is notified before any change in terms of agreement to a continuing process, service, or task, and is given the opportunity to provide consent to continue.

Foundational requirement: No misleading wordingDeveloping

Controls do not include double negatives, false statements, or other misleading wording.

Foundational requirement: No artificial pressureDeveloping

Process completion does not include artificial time limits

Note: Implying to a user that they will lose a benefit if they don’t act immediately is an artificial time limit.

Foundational requirement: No misinformationDeveloping

Processes can be completed without navigating misinformation.

Foundational requirement: No hidden preselectionsDeveloping

During process completion, preselected options that impact finance, privacy or safety are visibly and programmatically available to the user by default, exept when the user selected these options previously in the process.

Foundational requirement: No redirectionExploratory
Editor's note

Needs additional research

A mechanism is available to alert users they are exiting the site. Users are notified before they exit a site.

Foundational requirement: No sneakingExploratory

When completing a process, all financial, privacy or safety related information and choices that are provided to the user.

Supplemental requirement: No emotionally misleading designsDeveloping

Systems do not threaten individuals or restate decisions in a degrading way.

Supplemental requirement: No misdirectionDeveloping

Systems do not draw users attention away from information that impacts finances, privacy or safety by visually emphasizing other information.

Supplemental requirement: No naggingExploratory
Editor's note

Needs additional research

Once a user declines a request, the system does not ask again.

Assertion: No stressDeveloping

Usability testing has been conducted with people with cognitive and mental health related disabilities to assure the process does not cause unnecessary anxiety and stress.

2.9.5 Retain information

Users do not have to reenter information or redo work.

Requirement: Go back in processExploratory

In a multi-step process, the interface supports stepping backwards in a process and returning to the current point without data loss.

Requirement: Redundant entryExploratory

Information previously entered by or provided to the user that is required to be entered again in the same process is either auto-populated, or available for the user to select.

Requirement: Save progressExploratory

Data entry and other task completion processes allow saving and resuming from the current step in the task.

2.9.6 Complete tasks

Users understand how to complete tasks.

Requirement: Action requiredExploratory

In a process, the interface indicates when user input or action is required to proceed to the next step.

Requirement: Inform at start of processExploratory

Information needed to complete a multi-step process is provided at the start of the process, including:

  • number of steps it might take (if known in advance),
  • details of any resources needed to perform the task, and
  • overview of the process and next step.
Requirement: Steps and instructionsExploratory

The steps and instructions needed to complete a multi-step process are available.

2.10 Policy and protection

2.10.1 Content source

Users can determine when content is provided by a Third Party

Supplemental requirement: CitationExploratory
Editor's note

Needs additional research

The author or source of the primary content is visually and programmatically indicated.

Supplemental requirement: Indicate third party contentExploratory
Editor's note

Needs additional research

Third-party content (AI, Advertising, etc.) is visually and programmatically indicated.

2.10.2 Information privacy

When providing private and sensitive information, users understand:

  • That the information requested is private and sensitive,
  • How the information requested will be used, and
  • The risks involved in providing the information.
Foundational requirement: Access to informationDeveloping

Private or sensitive information is available to the person to which it applies (e.g., logging in to personal information, clearance for access to information, downloadable version, persistent way to access information via an icon or button). (e.g. personal medical records/information, account information, etc.)

Supplemental requirement: Accessible privacy settingsDeveloping

When the amount of information shared can be adjusted, the method of adjusting the amount of information causes a minimal cognitive burden.

Foundational requirement: Acknowledge information sharingDeveloping

When private or sensitive disability information will be disclosed or used by third parties or algorithms (including AI), the user is notified and must acknowledge the notification to proceed.

Foundational requirement: At data collectionDeveloping

When information about assistive technology use or disability related settings or patterns of behavior are captured, a way is provided for users to turn off the collection or manage the resulting data.

Foundational requirement: Disability information privacyDeveloping

Disability related vulnerability information is not disclosed to or used by third parties and algorithms (including AI, “user navigation trackers” for UX folks to see how people use the page and possibly give AT information to UX teams). This should include implied disability, such as noticing difficulties with numbers, or use of language suggest mental health disability or vulnerability.

Foundational requirement: Global privacy settingsDeveloping

Privacy settings from the operating system, user agent, and application are honored.

Foundational requirement: Notify about sensitive informationDeveloping

When private or sensitive information is displayed, notify the user and provide a mechanism to hide the information.

Assertion: Safe contentDeveloping

Content that may be inappropriate or cause harm as identified by an existing standard, policy, or regulation OR identified through user testing is programmatically (and visually?) indicated and a mechanism to avoid it is provided.

Assertion: Security proceduresDeveloping

Private and sensitive information is handled according to [named security procedures] and reviews are conducted.

Supplemental requirement: Supported decision makingDeveloping
Editor's note

Needs additional research

The interface provides a mechanism to support decision making while enabling user autonomy.

2.10.3 Agreement and risk

Users understand the benefits, risks and consequences of options they select.

Foundational requirement: Agreement indicatedDeveloping

The interface indicates the legal, financial, privacy or security related consequences, before a user enters a legal, financial, privacy, or security related agreement.

Foundational requirement: Comparable riskDeveloping

When people with disabilities are required to use alternative or additional processes or content not used by people without disabilities, use of the alternative does not expose them to additional risk.

Supplemental requirement: Risk statementsDeveloping

The interface states the benefits, risks and potential consequences of choices.

2.10.4 Algorithms

Users are not disadvantaged or harmed by by algorithms.

Assertion: Inclusive data setDeveloping

Data sets have been trained using representative and unbiased disability related information that is proportional to the general population.

Assertion: No harm from algorithmsDeveloping

User testing and ethics reviews have been conducted to minimize the possibility that algorithms cause harm to people with disabilities.

2.11 Help and feedback

2.11.1 Help available

Users have help available.

Requirement: Consistent helpExploratory
Editor's note

Needs additional research

Help is labeled consistently and available in a consistent visual and programmatic location.

Requirement: Contextual helpExploratory

Contextual help is available.

Requirement: Conversational supportExploratory

Conversational support allowing both text and verbal modes is available.

Requirement: Data visualizationsExploratory
Editor's note

Needs additional research

Help is available to understand and use data visualizations.

Requirement: New interfacesExploratory
Editor's note

Needs additional research

When interfaces dramatically change (due to redesign), a mechanism to learn the new interface or revert to the older design is available.

Requirement: Personalizable helpExploratory
Editor's note

Needs additional research

Help is adaptable and personalizable.

Requirement: Sensory characteristicsExploratory

Instructions and help do not rely on sensory characteristics.

Requirement: Support availableExploratory
Editor's note

Needs additional research

Accessible support is available during data entry, task completion and search.

2.11.2 Supplemental content

Users have supplemental content available.

Requirement: Number supplementsExploratory

Text or visual alternatives are available for numerical concepts.

Requirement: Text supplementsExploratory
Editor's note

Needs additional research

Visual illustrations, pictures, and images are available to help explain complex ideas, events, and processes.

2.11.3 Feedback

Users can provide feedback to authors.

Requirement: Feedback mechanismExploratory

A mechanism is available to provide feedback to authors.

2.12 User control

2.12.1 Control text

Users can control text presentation.

Requirement: Adjust colorExploratory

Text and background colors can be customized.

Requirement: Adjust backgroundExploratory

Patterns, designs, or images placed behind text are avoided or can be removed by the user.

Requirement: Font size meaningExploratory

When font size conveys visual meaning (such as headings), the text maintains its meaning and purpose when text is resized.

Requirement: Text customizationExploratory

Users can change the text style (like font and size) and the layout (such as spacing and single column) to fit their needs.

2.12.2 Adjustable viewport

Users can transform size and orientation of content presentation to make it viewable and usable.

Requirement: OrientationExploratory

Content orientation allows the user to read the language presented without changing head or body position.

Requirement: ReflowExploratory

Content can be viewed in multiple viewport sizes, orientations, and zoom levels — without loss of content, functionality, meaningful relationships, and with scrolling only occurring in one direction.

2.12.3 Transform content

Users can transform content to make it understandable.

Requirement: Alternative presentationExploratory
Editor's note

Needs additional research

Complex information or instructions for complex processes are available in multiple presentation formats.

Requirement: Content markupExploratory

Role and priority of content is programmatically determinable.

Requirement: SummaryExploratory

Access to a plain-language summary, abstract, or executive summaries is available.

Requirement: Transform contentExploratory
Editor's note

Needs additional research

Content can be transformed to make its purpose clearer.

2.12.4 Media control

Users can control media and media alternative.

Requirement: Adjust captionsExploratory

The position and formatting of captions can be changed.

Requirement: Audio controlExploratory

Audio can be turned off, while still playing the video, and without affecting the system sound.

Requirement: Interactive audio alternativeExploratory
Editor's note

Needs additional research

Alternatives for audio include the ability to search and look up terms.

Requirement: Media alternative controlExploratory

Captions and audio descriptions can be turned on and off.

Requirement: Media chaptersExploratory
Editor's note

Needs additional research

Media can be navigated by chapters.

2.12.5 Control interruptions

Users can control interruptions.

Requirement: Control notificationsExploratory

The timing and positioning of notifications and other interruptions can be changed, suppressed or saved, except interruptions involving an emergency.

2.12.6 Control possible harm

Users can control potential sources of harm.

Requirement: Disturbing contentExploratory
Editor's note

Needs additional research

Warnings are available about content that may be emotionally disturbing, and the disturbing content can be hidden.

Requirement: Haptic stimulationExploratory
Editor's note

Needs additional research

Haptic feedback can be reduced or turned off.

Requirement: TriggersExploratory
Editor's note

Needs additional research

Warnings are available about triggering content, and the warnings and triggering content can be hidden.

Requirement: VerbosityExploratory
Editor's note

Needs additional research

Overwhelming wordiness can be reduced or turned off.

Requirement: Visual stimulationExploratory
Editor's note

Needs additional research

Visual stimulation from combinations of density, color, movement, etc. can be reduced or turned off.

2.12.7 User agent support

Users can control content settings from their User Agents including Assistive Technology.

Requirement: Assistive technology controlExploratory

Content can be controlled using assistive and adaptive technology.

Requirement: PrintingExploratory
Editor's note

Needs additional research

Printing respects user’s content presentation preferences.

Requirement: User settingsExploratory

User settings are honored.

Requirement: Virtual cursorExploratory

Assistive technologies can access content and interactions when using mechanisms that convey alternative points of regard or focus (i.e. virtual cursor).

3. ConformanceExploratory

This section (with its subsections) provides requirements which must be followed to conform to the specification, meaning it is normative.

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY and MUST in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3.1 Conformance

Plain language summary of Conformance

You might want to make a claim that your content or product meets the WCAG 3.0 guidelines. If it does meet the guidelines, we call this “conformance”.

If you want to make a formal conformance claim, you must use the process described in this document. Conformance claims are not required and your content can conform to WCAG 3.0, even if you don’t want to make a claim.

There are two types of content in this document:

  • Normative: what you must do to meet the guidelines.
  • Informative: advice to help you meet the guidelines. This is also called non-normative.

We are experimenting with different conformance approaches for WCAG 3.0. Once we have developed enough guidelines, we will test how well each works.

End of summary for Conformance

WCAG 3.0 will use a different conformance model than WCAG 2.2 in order to meet its requirements. Developing and vetting the conformance model is a large portion of the work AG needs to complete over the next few years.

AG is exploring a model based on Foundational Requirements, Supplemental Requirements, and Assertions.

The most basic level of conformance will require meeting all of the Foundational Requirements. This set will be somewhat comparable to WCAG 2.2 Level AA.

Higher levels of conformance will be defined and met using Supplemental Requirements and Assertions. AG will be exploring whether meeting the higher levels would work best based on points, percentages, or predefined sets of requirements (modules).

Other conformance concepts AG continues to explore the following include conformance levels, issue severity, adjectival ratings and pre-assessment checks.

See Explainer for W3C Accessibility Guidelines (WCAG) 3.0 for more information.

3.1.1 Only accessibility-supported ways of using technologies

The concept of "accessibility-supported" is to account for the variety of user agents and scenarios. How does an author know that a particular technique for meeting a guideline will work in practice with user agents that are used by real people?

The intent is for the responsibility of testing with user agents to vary depending on the level of conformance.

At the foundational level of conformance, assumptions can be made by authors that methods and techniques provided by WCAG 3.0 work. At higher levels of conformance the author may need to test that a technique works, or check that available user agents meet the requirement, or a combination of both.

This approach means the Working Group will ensure that methods and techniques included do have reasonably wide and international support from user agents, and there are sufficient techniques to meet each requirement.

The intent is that WCAG 3.0 will use a content management system to support tagging of methods/techniques with support information. There should also be a process where interested parties can provide information.

An "accessibility support set" is used at higher levels of conformance to define which user agents and assistive technologies you test with. It would be included in a conformance claim, and enables authors to use techniques that are not provided with WCAG 3.0.

An exception for long-present bugs in assistive technology is still under discussion.

3.1.2 Defining conformance scopeExploratory

When evaluating the accessibility of content, WCAG 3.0 requires the guidelines apply to a specific scope. While the scope can be an all content within a digital product, it is usually one or more subsets of the whole. Reasons for this include:

  • Large amounts of content are impractical to evaluate comprehensively using anything beyond automated evaluation of items;
  • In many cases, content changes frequently, causing evaluation to be accurate only for a specific moment in time;
  • Some content is more important to the majority of users than other content; and
  • Content that mostly meets the requirements but has problems can interfere with the user’s ability to complete a process.

WCAG 3.0 therefore defines two ways to scope content: views and processes. Evaluation is done on one or more complete views or processes, and conformance is determined on the basis of one or more complete views or processes.

Conformance is defined only for processes and views. However, a conformance claim may be made to cover one process and view, a series of processes and views, or multiple related processes and views. All unique steps in a process MUST be represented in the set of views. Views outside of the process MAY also be included in the scope.

Editor's note

We recognize that representative sampling is an important strategy that large and complex sites use to assess accessibility. While it is not addressed within this document at this time, our intent is to later address it within this document or in a separate document before the guidelines reach the Candidate Recommendation stage. We welcome your suggestions and feedback about the best way to incorporate representative sampling in WCAG 3.0.

4. GlossaryExploratory

This section (with its subsections) provides requirements which must be followed to conform to the specification, meaning it is normative.

Note

Many of the terms defined here have common meanings. When terms appear with a link to the definition, the meaning is as formally defined here. When terms appear without a link to the definition, their meaning is not explicitly related to the formal definition here. These definitions are in progress and may evolve as the document evolves.

Editor's note

This glossary includes terms used by content that has reached a maturity level of Developing or higher. The definitions themselves include a maturity level and may mature at a different pace than the content that refers to them. The AGWG will work with other taskforces and groups to harmonize terminology across documents as much as is possible.

Accessibility support setDeveloping

group of user agents and assistive technologies you test with

Editor's note

The AGWG is considering defining a default set of user agents and assistive technologies that they use when validating guidelines.

Accessibility support sets may vary based on language, region, or situation.

If you are not using the default accessibility set, the conformance report should indicate what set is being used.

Accessibility supportedDeveloping

supported by in at least 2 major free browsers on every operating system and/or available in assistive technologies used by 80% cumulatively of the AT users on each operating system for each type of AT used

Actively availableDeveloping

available for the user to read and use any actionable items included

AssertionDeveloping

formal claim of fact, attributed to a person or organization. An attributable and documented statement of fact regarding procedures practiced in the development and maintenance of the content or product to improve accessibility

Assistive technologyDeveloping

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements of users with disabilities that go beyond those offered by mainstream user agents

Note 1

Functionality provided by assistive technology includes alternative presentations (e.g., as synthesized speech or magnified content), alternative input methods (e.g., voice), additional navigation or orientation mechanisms, and content transformations (e.g., to make tables more accessible).

Note 2

Assistive technologies often communicate data and messages with mainstream user agents by using and monitoring APIs.

Note 3

The distinction between mainstream user agents and assistive technologies is not absolute. Many mainstream user agents provide some features to assist individuals with disabilities. The basic difference is that mainstream user agents target broad and diverse audiences that usually include people with and without disabilities. Assistive technologies target narrowly defined populations of users with specific disabilities. The assistance provided by an assistive technology is more specific and appropriate to the needs of its target users. The mainstream user agent may provide important functionality to assistive technologies like retrieving web content from program objects or parsing markup into identifiable bundles.

Audio describerDeveloping

person who provides verbal descriptions of visual elements in media, cultural spaces, and live performances to make content and experiences more accessible to individuals who are blind or have low vision

Note

They will describe actions, settings, costumes, and facial expressions, inserting these descriptions into pauses within the dialogue or audio.

Audio descriptionDeveloping

narration added to the soundtrack to describe important visual details that cannot be understood from the main soundtrack alone

Note

For audiovisual media, audio description provides information about actions, characters, scene changes, on-screen text, and other visual content.

Audio description is also sometimes called “video description”, “described video”, “visual description”, or “descriptive narration”.

In standard audio description, narration is added during existing pauses in dialogue. See also extended audio description.

If all important visual information is already provided in the main audio track, no additional audio description track is necessary.

Automated evaluationDeveloping

evaluation conducted using software tools, typically evaluating code-level features and applying heuristics for other tests

Note

Automated testing is contrasted with other types of testing that involve human judgement or experience. Semi-automated evaluation allows machines to guide humans to areas that need inspection. The emerging field of testing conducted via machine learning is not included in this definition.

Blocks of textDeveloping

continuous text with multiple sentences that is not separated by structural elements such as table cells, regions

CARTDeveloping

communication Access Realtime Translation, or CART, is a type of live captioning provided by trained captioners, using specialized software along with phonetic keyboards or stenography methods, to produce real-time visual captioning for meeting and event participants

Note

CART is available primarily in English, with some providers providing French, Spanish, and other languages on demand. It is not available for Japanese and some other languages.

CART is sometimes referred to as “real-time captioning”.

CaptionsDeveloping

time-synchronized visual and/or text alternative that communicates the audio portion of a work of multimedia (for example, a movie or podcast recording)

Note

Captions are similar to dialogue-only subtitles, except captions convey not only the content of spoken dialogue, but also equivalents for non-dialogue audio information needed to understand the program content, including sound effects, music, laughter, speaker identification and location.

In some countries, captions are called subtitles.

Change of viewport within a page/viewDeveloping

change of content/context that causes the users keyboard navigation point to change where they have the option to move back out of the new content/context

Note 1

“within a page/view is part of this term because - if the new viewport/content/context is within the same page/view going back etc. would be under the control of the author. If moving to another page/view - perhaps on a different site - the current author would not have control and this would be a requirement on the user agent.

Note 2

This is different from Change of Context in WCAG 2.x major changes that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously.

Closed captionsDeveloping

captions that are decoded into chunks known as “caption frames” that are synchronized with the media

Note

Closed captions can be turned on and off with some players, and can often be read using assistive technology.

Closed systemDeveloping

information technology that prevents users from easily attaching or installing assistive technologies. For example, kiosk, calculator, vending machines, etc

Closely availableExploratory

available in the currently perceivable content, or after one activation of an interactive element

Common keyboard navigation techniqueDeveloping

keyboard navigation technique that is the same across most or all applications and platforms and can therefore be relied upon by users who need to navigate by keyboard alone

Note

A sufficient listing of common keyboard navigation techniques for use by authors can be found in the WCAG common keyboard navigation techniques list

Complex pointer inputDeveloping

any pointer input other than a single pointer input

ComponentDeveloping

grouping of interactive elements for a distinct function

ConformanceDeveloping

satisfying all the requirements of the guidelines. Conformance is an important part of following the guidelines even when not making a formal Conformance Claim

See the Conformance section for more information.

Conformance scopeDeveloping

set of views and/or pages selected to be part of a conformance claim. Where a view or page is part of a process, all the views or pages in the process must be included

Note

How a person or organisation selects the set is not defined in WCAG3. There maybe informative guidance on selecting a suitable set in future, and regional laws or regulations may require a particular methodology.

ContentDeveloping

information and sensory experience to be communicated to the user by an interface, including code or markup that defines the content’s structure, presentation, and interactions

Contrast ratio testPlaceholder
Editor's note

To be defined.

Decorative imagePlaceholder
Editor's note

To be defined.

Default direction of textPlaceholder
Editor's note

To be defined.

Default orientationDeveloping

single orientation that a platform uses to view content by default

DeprecateDeveloping

declare something outdated and in the process of being phased out, usually in favor of a specified replacement

Deprecated documents are no longer recommended for use and may cease to exist in the future.

Diverse set of usersPlaceholder
Editor's note

To be defined.

Down eventDeveloping

platform event that occurs when the trigger stimulus of a pointer is depressed

Note

The down-event may have different names on different platforms, such as “touchstart” or “mousedown”.

ElementPlaceholder
Editor's note

To be defined.

Essential exceptionDeveloping

exception because there is no way to carry out the function without doing it this way or fundamentally changing the functionality

EvaluationDeveloping

process of examining content for conformance to these guidelines

Note

Different approaches to evaluation include automated evaluation, semi-automated evaluation, human evaluation, and user testing.

Extended audio descriptionDeveloping

audio description that is added to audiovisual media by pausing the video to allow for additional time to add audio description

Note

This technique is only used when the sense of the video would be lost without the additional audio description and the pauses between dialogue or narration are too short.

Figure captionsDeveloping

title, brief explanation, or comment that accompanies a work of visual media and is always visible on the page

Functional needDeveloping

statement that describes a specific gap in one’s ability, or a specific mismatch between ability and the designed environment or context

GestureDeveloping

motion made by the body or a body part used to communicate to technology

GuidelineDeveloping

high-level, plain-language outcome statements used to organize requirements

Note

Guidelines provide a high-level, plain-language outcome statements for managers, policy makers, individuals who are new to accessibility, and other individuals who need to understand the concepts but not dive into the technical details. They provide an easy-to-understand way of organizing and presenting the requirements so that non-experts can learn about and understand the concepts.

Each guideline includes a unique, descriptive name along with a high-level plain-language summary. Guidelines address functional needs on specific topics, such as contrast, forms, readability, and more.

Guidelines group related requirements and are technology-independent.

High cognitive loadPlaceholder
Editor's note

To be defined.

Human evaluationDeveloping

evaluation conducted by a human, typically to apply human judgement to tests that cannot be fully automatically evaluated

Note

Human evaluation is contrasted with automated evaluation which is done entirely by machine, though it includes semi-automated evaluation which allows machines to guide humans to areas that need inspection. Human evaluation involves inspection of content features, by contrast with user testing which directly tests the experience of users with content.

ImagePlaceholder
Editor's note

To be defined.

Image rolePlaceholder
Editor's note

To be defined.

Image typePlaceholder
Editor's note

To be defined.

InformativeDeveloping

content provided for information purposes and not required for conformance. Also refered to as non-normative

Interactive elementDeveloping

part of the interface that responds to user input and can have a distinct programmatically determinable name

Note

In contrast to non-interactive elements. For example, headings or paragraphs.

Interactive groupDeveloping

grouping of interactive elements for a distinct function. It may also contain non-interactive elements

Note 1

A component could also include static elements (e.g. instructional text), but must include interactive elements.

Note 2

A grouping of static elements (which are not interactive) fit in the “content” category (an umbrella term for everything perceivable).

Note 3

Interactive groups could be nested.

ItemsDeveloping

smallest testable unit for testing scope

Note

Items could be interactive components such as a drop down menu, a link, or a media player.

They could also be units of content such as a phrase, a paragraph, a label or error message, an icon, or an image.

Keyboard focusDeveloping

point in the content where any keyboard actions would take effect

Keyboard interfaceDeveloping

API (Application Programming Interface) where software gets “keystrokes” from

Note

“Keystrokes” that are passed to the software from the “keyboard interface” may come from a wide variety of sources including but not limited to a scanning program, sip-and-puff morse code software, speech recognition software, AI of all sorts, as well as other keyboard substitutes or special keyboards.

MechanismDeveloping

process or technique for achieving a result

Note 1

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies.

Note 2

The mechanism needs to meet all success criteria for the conformance level claimed.

MethodDeveloping

detailed information, either technology-specific or technology-agnostic, on ways to meet the requirement as well as tests and scoring information

Navigated sequentiallyDeveloping

navigated in the order defined for advancing focus (from one element to the next) using a keyboard interface

Non-interactive elementDeveloping

part of the interface that does not respond to user input and does not include sub-parts

Note 1

If a paragraph included a link, the text either side of the link would be considered a static element, but not the paragraph as a whole.

Note 2

Letters within text do not constitute a “smaller part”.

Non-literal languageDeveloping

words or phrases used in a way that are beyond their standard or dictionary meaning to express deeper, more complex ideas

Note

This is also called figurative language.

To understand the content, users have to interpret the implied meaning behind the words, rather than just their literal or direct meaning.

Examples include:

  • allusions
  • hyperbole
  • idioms
  • irony
  • jokes
  • litotes
  • metaphors
  • metonymies
  • onomatopoeias
  • oxymorons
  • personification
  • puns
  • sarcasm
  • similes
Non-web softwareDeveloping

software that does not qualify as web content

NormativeDeveloping

content whose instructions are required for conformance

Open captionsDeveloping

captions that are visual equivalent images of text that are embedded in video

Note

Open captions are also known as burned-in, baked-on, or hard-coded captions. Open captions cannot be turned off and cannot be read using assistive technology.

PageDeveloping

non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together

Note

Where a URI is available and represents a unique set of content, that would be the preferred conformance unit.

Path-based gestureDeveloping

gesture that depends on the path of the pointer input and not just its endpoints

Note

Path based gesture includes both time dependent and non-time dependent path-based gestures.

PlatformDeveloping

software, or collection of layers of software, that lie below the subject software and provide services to the subject software and that allows the subject software to be isolated from the hardware, drivers, and other software below

Note 1

Platform software both makes it easier for subject software to run on different hardware, and provides the subject software with many services (e.g. functions, utilities, libraries) that make the subject software easier to write, keep updated, and work more uniformly with other subject software.

Note 2

A particular software component might play the role of a platform in some situations and a client in others. For example a browser is a platform for the content of the page but it also relies on the operating system below it.

Note 3

The platform is the context in which the product exists.

Point of regardExploratory

position in rendered content that the user is presumed to be viewing. The dimensions of the point of regard can vary

Note

The point of regard is almost always within the viewport, but it can exceed the spatial or temporal dimensions of the viewport. See rendered content for more information about viewport dimensions.

The point of regard can also refer to a particular moment in time for content that changes over time. For example, an audio-only presentation.

User agents can determine the point of regard in a number of ways, including based on viewport position in content, keyboard focus, and selection.

PointerPlaceholder
Editor's note

To be defined.

Private and sensitive informationDeveloping

private and sensitive information

ProcessDeveloping

series of views or pages associated with user actions, where actions required to complete an activity are performed, often in a certain order, regardless of the technologies used or whether it spans different sites or domains

ProductDeveloping

testing scope that is a combination of all items, views, and task flows that make up the web site, set of web pages, web app, etc

Note

The context for the product would be the platform.

Programmatically determinableDeveloping

meaning of the content and all its important attributes can be determined by software functionality that is accessibility supported

Purely decorativeDeveloping

content that, if removed, does not affect the meaning or functionality of the page

Relied uponDeveloping

content would not conform if that technology is turned off or is not supported

RequirementDeveloping

result of practices that reduce or eliminate barriers that people with disabilities experience

SectionDeveloping

self-contained portion of content that deals with one or more related topics or thoughts

Note

A section may consist of one or more paragraphs and include graphics, tables, lists and sub-sections.

Semi-automated evaluationDeveloping

evaluation conducted using machines to guide humans to areas that need inspection

Note

Semi-automated evaluation involves components of automated evaluation and human evaluation.

Simple pointer inputDeveloping

input event that involves only a single ‘click’ event or a ‘button down’ and ‘button up’ pair of events with no movement between

Note

Examples of things that are not simple pointer actions include double clicks, dragging motions, gestures, and any use of multipoint input or gestures, and the simultaneous use of a mouse and keyboard.

Single pointerDeveloping

input modality that only targets a single point on the page/screen at a time – such as a mouse, single finger on a touch screen, or stylus

Note

Single pointer interactions include clicks, double clicks, taps, dragging motions, and single-finger swipe gestures. In contrast, multipoint interactions involve the use of two or more pointers at the same time, such as two-finger interactions on a touchscreen, or the simultaneous use of a mouse and stylus.

Single pointer inputDeveloping

input modality that only targets a single point on the view at a time – such as a mouse, single finger on a touch screen, or stylus

Note 1

Single pointer interactions include clicks, double clicks, taps, dragging motions, and single-finger swipe gestures. In contrast, multipoint interactions involve the use of two or more pointers at the same time, such as two-finger interactions on a touchscreen, or the simultaneous use of a mouse and stylus.

Note 2

Single pointer input is in contrast to multipoint input such as two, three or more fingers or pointers touching the surface, or gesturing in the air, at the same time.

Note 3

Activation is usually by click or tap but can also be by programmatic simulation of a click or tap or other similar simple activation.

Standard platform keyboard commandsDeveloping

keyboard commands that are the same across most or platforms and are relied upon by users who need to navigate by keyboard alone

Note

A sufficient listing of common keyboard navigation techniques for use by authors can be found in the WCAG standard keyboard navigation techniques list.

SubtitlesDeveloping

captions that are displayed with a work of media that translate or transcribe the dialogue or narrative

Note

Subtitles are synchronized with the soundtrack in real-time and can include spoken dialogue, sound effects, and other auditory information.

Task flowDeveloping

testing scope that includes a series views that support a specified user activity

Note

A task flow may include a subset of items in a view or a group of views. Only the part of the views that support the user activity are included in a test of the task flow.

TechnologyDeveloping

mechanism for encoding instructions to be rendered, played or executed by user agents

Note 1

As used in these guidelines “web technology” and the word “technology” (when used alone) both refer to web content technologies.

Note 2

Web content technologies may include markup languages, data formats, or programming languages that authors may use alone or in combination to create end-user experiences.

Temporary change of contextPlaceholder
Editor's note

To be defined.

TestDeveloping

mechanism to evaluate implementation of a method

TextDeveloping

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language

Two-dimensional contentExploratory
Editor's note

To be defined.

Unambiguous numerical formattingPlaceholder
Editor's note

To be defined.

Under the control of the providerDeveloping

where the provider is able to influence the content and its functionality

Note

This could be by directly creating the content themselves or by having influence by means of financial or other reward or removal of reward to the author of the content.

Up eventDeveloping

platform event that occurs when the trigger stimulus of a pointer is released

Note

The up-event may have different names on different platforms, such as “touchend” or “mouseup”.

User agentDeveloping

software that retrieves and presents external content for users

User interface contextDeveloping

user interface with a specific layout and associated components

Note

If more than X% of the associated components are changed, it is a new user interface context.

User manipulable textDeveloping

text which the user can adjust

Note

This could include, but is not limited to, changing:

  • Line, word or letter spacing
  • Color
  • Line length — being able to control width of block of text
  • Typographic alignment — justified, flushed right/left, centered
  • Wrapping
  • Columns — number of columns in one-dimensional content
  • Margins
  • Underlining, italics, bold
  • Font face, size, width
  • Capitalization — all caps, small caps, alternating case
  • End of line hyphenation
  • Links
User needDeveloping

end goal a user has when starting a process through digital means

User testingDeveloping

evaluation of content by observation of how users with specific functional needs are able to complete a process and how the content meets the relevant requirements

ViewDeveloping

content that is actively available in a viewport including that which can be scrolled or panned to, and any additional content that is included by expansion while leaving the rest of the content in the viewport actively available

Note

A modal dialog box would constitute a new view because the other content in the viewport is no longer actively available.

ViewportDeveloping

object in which the platform presents content

Note 1

The author has no control of the viewport and almost always has no idea what is presented in a viewport (e.g. what is on screen) because it is provided by the platform. On browsers the hardware platform is isolated from the content.

Note 2

Content can be presented through one or more viewports. Viewports include windows, frames, loudspeakers, and virtual magnifying glasses. A viewport may contain another viewport. For example, nested frames. Interface components created by the user agent such as prompts, menus, and alerts are not viewports.

A. Privacy Considerations

Editor's note

The content of this document has not matured enough to identify privacy considerations. Reviewers of this draft should consider whether requirements of the conformance model could impact privacy.

B. Security Considerations

Editor's note

The content of this document has not matured enough to identify security considerations. Reviewers of this draft should consider whether requirements of the conformance model could impact security.

C. Change log

This section shows substantive changes made in WCAG 3.0 since the First Public Working Draft was published in 21 January 2021.

The full commit history to WCAG 3.0 and commit history to Silver is available.

D. Acknowledgements

Additional information about participation in the Accessibility Guidelines Working Group (AG WG) can be found on the Working Group home page.

D.1 Contributors to the development of this document

D.2 Previous contributors to the development of this document

Abi James, Abi Roper, Alastair Campbell, Alice Boxhall, Alistair Garrison, Amani Ali, Andrew Kirkpatrick, Andrew Somers, Andy Heath, Angela Hooker, Aparna Pasi, Avneesh Singh, Azlan Cuttilan, Ben Tillyer, Betsy Furler, Brooks Newton, Bruce Bailey, Bryan Trogdon, Caryn Pagel, Charles Hall, Charles Nevile, Chris Loiselle, Chris McMeeking, Christian Perera, Christy Owens, Chuck Adams, Cybele Sack, Daniel Bjorge, Daniel Henderson-Ede, Darryl Lehmann, David Fazio, David MacDonald, David Sloan, David Swallow, Dean Hamack, Detlev Fischer, DJ Chase, E.A. Draffan, Eleanor Loiacono, Francis Storr, Frederick Boland, Garenne Bigby, Gez Lemon, Giacomo Petri, Glenda Sims, Greg Lowney, Gregg Vanderheiden, Gundula Niemann, Imelda Llanos, Jaeil Song, JaEun Jemma Ku, Jake Abma, Jan McSorley, Janina Sajka, Jaunita George, Jeanne Spellman, Jeff Kline, Jennifer Chadwick, Jennifer Delisi, Jennifer Strickland, Jennison Asuncion, Jill Power, Jim Allan, Joe Cronin, John Foliot, John Kirkwood, John McNabb, John Northup, John Rochford, Jon Avila, Joshue O’Connor, Judy Brewer, Julie Rawe, Justine Pascalides, Karen Schriver, Katharina Herzog, Kathleen Wahlbin, Katie Haritos-Shea, Katy Brickley, Kelsey Collister, Kim Dirks, Kimberly Patch, Laura Carlson, Laura Miller, Léonie Watson, Lisa Seeman-Kestenbaum, Lori Samuels, Lucy Greco, Luis Garcia, Lyn Muldrow, Makoto Ueki, Marc Johlic, Marie Bergeron, Mark Tanner, Mary Jo Mueller, Matt Garrish, Matthew King, Melanie Philipp, Melina Maria Möhnle, Michael Cooper, Michael Crabb, Michael Elledge, Michael Weiss, Michellanne Li, Michelle Lana, Mike Crabb, Mike Gower, Nicaise Dogbo, Nicholas Trefonides, Omar Bonilla, Patrick Lauke, Paul Adam, Peter Korn, Peter McNally, Pietro Cirrincione, Poornima Badhan Subramanian, Rachael Bradley Montgomery, Rain Breaw Michaels, Ralph de Rooij, Rebecca Monteleone, Rick Boardman, Ruoxi Ran, Ruth Spina, Ryan Hemphill, Sarah Horton, Sarah Pulis, Scott Hollier, Scott O’Hara, Shadi Abou-Zahra, Shannon Urban, Shari Butler, Shawn Henry, Shawn Lauriat, Shawn Thompson, Sheri Byrne-Haber, Shrirang Sahasrabudhe, Shwetank Dixit, Stacey Lumley, Stein Erik Skotkjerra, Stephen Repsher, Steve Lee, Sukriti Chadha, Susi Pallero, Suzanne Taylor, sweta wakodkar, Takayuki Watanabe, Thomas Logan, Thomas Westin, Tiffany Burtin, Tim Boland, Todd Libby, Todd Marquis Boutin, Victoria Clark, Wayne Dick, Wendy Chisholm, Wendy Reid, Wilco Fiers.

D.3 Research Partners

These researchers selected a Silver research question, did the research, and graciously allowed us to use the results.

D.4 Enabling funders

This publication has been funded in part with U.S. Federal funds from the Health and Human Services, National Institute on Disability, Independent Living, and Rehabilitation Research (NIDILRR), initially under contract number ED-OSE-10-C-0067, then under contract number HHSP23301500054C, and now under HHS75P00120P00168. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Health and Human Services or the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.

E. References

E.1 Normative references

[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174

E.2 Informative references

[ATAG20]
Authoring Tool Accessibility Guidelines (ATAG) 2.0. Jan Richards; Jeanne F Spellman; Jutta Treviranus. W3C. 24 September 2015. W3C Recommendation. URL: https://www.w3.org/TR/ATAG20/
[css]
CSS Snapshot 2023. Chris Lilley; Elika Etemad; Tab Atkins Jr.; Florian Rivoal. W3C. 7 December 2023. W3C Working Group Note. URL: https://www.w3.org/TR/css-2023/
[UAAG20]
User Agent Accessibility Guidelines (UAAG) 2.0. James Allan; Greg Lowney; Kimberly Patch; Jeanne F Spellman. W3C. 15 December 2015. W3C Working Group Note. URL: https://www.w3.org/TR/UAAG20/
[WCAG22]
Web Content Accessibility Guidelines (WCAG) 2.2. Michael Cooper; Andrew Kirkpatrick; Alastair Campbell; Rachael Bradley Montgomery; Charles Adams. W3C. 12 December 2024. W3C Recommendation. URL: https://www.w3.org/TR/WCAG22/