W3C Accessibility Guidelines (WCAG) 3.0

W3C Working Draft

More details about this document
This version:
https://www.w3.org/TR/2024/WD-wcag-3.0-20240528/
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:
(TetraLogical)
(Library of Congress)
(Oracle)
(Nomensa)
(W3C)
Former editors:
(W3C)
(Google, Inc.)
Project Manager:
(Deque Systems, Inc.)
Feedback:
GitHub w3c/wcag3 (pull requests, new issue, open issues)
[email protected] 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 outcomes to determine whether the need has been met. Guidelines are also supported by technology-specific methods to meet each outcome.

This specification is expected to be updated regularly to keep pace with changing technology by updating and adding methods, outcomes, 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 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 technical reports index at https://www.w3.org/TR/.

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, send email to [email protected] (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 a Working Draft using the Recommendation track.

Publication as a Working 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 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 which 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?

This draft includes an updated list of the potential outcomes which we are exploring. The list of outcomes is longer than a listing of Success Criteria in WCAG 2.2 because the intent at this stage is to be as inclusive as possible of potential outcomes. The final set of outcomes in WCAG 3 will be different than what is in this draft. Outcomes will be added, combined, and removed. We also expect changes to the text of the Outcomes. Only some of the Outcomes will be required at the base level of conformance.

The purpose of publishing this initial list is to:

We did not make changes to conformance related sections and we did not publish an updated WCAG 3 Explainer.

1.1 About WCAG 3

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 supports this evolution by focusing on the functional needs of users. These needs are then supported by outcomes and technology-specific methods to meet those needs. 

WCAG 3 is a successor to Web Content Accessibility Guidelines 2.2 [WCAG22] and previous versions, but does not deprecate WCAG 2. It will also incorporate 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. The WCAG 3 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 outcomes to determine whether the need has been met. Guidelines are also supported by technology-specific methods to meet each outcome.

Content that conforms to WCAG 2.2 A and AA is expected to meet most of the minimum conformance level of this new standard but, since WCAG 3 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 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.

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

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 functional categories of disabilities, general guidelines, outcomes that can be tested, a rich collection of methods, resource links, and code samples.

The following guidelines are an initial list of potential outcomes 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.

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 the content of the entire section. Please consider 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 become requirements.

The outcomes 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 outcomes may be best addressed by authoring tools or at the platform level. Many outcomes 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 outcome.

Please consider the following questions when reviewing this list of outcomes:

  • What outcomes are needed to make web content accessible and are missing from this list?
  • What research supports or refutes these outcomes?
  • Are outcomes listed here out of the scope of accessibility guidance and why?

To provide feedback, please file a GitHub issue or send email to [email protected] (comment archive).

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 outcomes 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 [email protected] (comment archive).

End of note

Animation and movement

Audio shiftingExploratory

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

Editor's note

Needs additional research

End of note

Flashing and strobingExploratory

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

MotionExploratory

Visual motion and pseudo-motion after a specified time is avoided; or can be paused or prevented.

Editor's note

Needs additional research

End of note

Forms, inputs, and errors

Allow automated entryExploratory

Automated input from user agents, 3rd party tools, or copy-and-paste is supported.

Error associationExploratory

Error notifications are programmatically associated with the error source.

Error identificationExploratory

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

Error notificationExploratory

Error notifications are provided when an error occurs that describe the error and either provide instructions to fix the error or state that the system is at fault.

Input instructionsExploratory

Input constraints or conditions (required line length, date format, password format, etc) are programmatically and visually indicated.

Input labelsExploratory

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

Persistent error notificationExploratory

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

Visible errorExploratory

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

Editor's note

Needs additional research

End of note

Processes and task completion

Adequate timeExploratory

Enough time is provided to read and use content.

Editor's note

Needs additional research

End of note

Action requiredExploratory

The interface indicates when user input or action is required to proceed.

Avoid manipulationExploratory

Tasks can be completed without navigating misinformation or redirections.

Editor's note

Needs additional research

End of note

Go back in processExploratory

The interface supports stepping backwards in a process and returning to the current point without data loss.

Inform at startExploratory

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

  • estimated time or number of steps it might take,
  • details of any resources needed to perform the task, and
  • overview of the process and next step.

No cognitive testsExploratory

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

No memorizationExploratory

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

Editor's note

Needs additional research

End of note

Optimized processesExploratory

Tasks can be completed without reading or understanding unnecessary content.

Optional informationExploratory

Tasks can be completed without entering unnecessary information.

PreselectionsExploratory

Preselections are visible during task completion.

Save progressExploratory

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

Steps and directionExploratory

The steps and directions needed to complete a process are visually and programmatically indicated.

Task completion documentationExploratory

For tasks where labels and instructions cannot provide sufficient instructions for completion, detailed documentation on task completion is available.

Editor's note

Needs additional research

End of note

Image and media alternatives

AI editableExploratory

Auto generated text descriptions are editable by content creator.

Editor's note

Needs additional research

End of note

Audio alternative in preferred languageExploratory

Equivalent audio alternatives are available in the preferred language.

Audio descriptionsExploratory

Equivalent visual alternatives are available as synchronized audio in the media.

CaptionsExploratory

Equivalent audio alternatives are available as synchronized captions in the media.

Complex image alternativeExploratory

Equivalent text alternatives are available for complex images.

Context in image alternativeExploratory

Image alternatives include context.

Editor's note

Needs additional research

End of note

Decorative image alternativeExploratory

Equivalent descriptive text alternatives are available for decorative images.

Needs additional research

Descriptive transcriptsExploratory

Equivalent audio and visual alternatives to audio and video alternatives are available in descriptive transcripts.

Finding media alternativesExploratory

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

Editor's note

Needs additional research

End of note

Identify autogenerated textExploratory

Auto generated text alternatives are identified.

Editor's note

Needs additional research

End of note

Image alternativesExploratory

Equivalent text alternatives are available for images that convey content.

Image roleExploratory

The role and importance of images are programmatically indicated.

Editor's note

Needs additional research

End of note

Image typeExploratory

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

Editor's note

Needs additional research

End of note

Images-of-Text alternativesExploratory

Equivalent text alternatives are available for images of text.

Non-text alternativesExploratory

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

Non-verbal cuesExploratory

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

Editor's note

Needs additional research

End of note

Persistent figure captionsExploratory

Figure captions persist or can be made to persist.

Editor's note

Needs additional research

End of note

Use of colorExploratory

Information is not conveyed with color alone.

Use of visual depthExploratory

Information is not conveyed with visual depth alone.

Editor's note

Needs additional research

End of note

Use of soundExploratory

Information is not conveyed with sound alone.

Use of spatial audioExploratory

Information is not conveyed with spatial audio alone.

Interactive components

Behavior of controlsExploratory

Controls and inputs with the same functionality behave consistently.

Change focus with pointer deviceExploratory

Selecting an element with a ‘pointer’ sets the focus to that element.

Control labelsExploratory

Controls have visible labels that identify the purpose of the controls.

ConventionsExploratory

Controls follow established conventions.

Editor's note

Needs additional research

End of note

Consistent labelsExploratory

Controls and inputs with the same functionality have consistent labels.

Control importanceExploratory

The importance of controls is visually and programmatically indicated.

Editor's note

Needs additional research

End of note

Control updatesExploratory

Changes to control or input name, roles, values or states are visually and programmatically indicated.

Deceptive controlsExploratory

Controls and interactions are not deceptively designed (invisible, incorrectly labeled, placement, etc.).

Editor's note

Needs additional research

End of note

Distinguishable controlsExploratory

Controls are visually distinct from static content and include visual cues on how to use them.

Hover informationExploratory

Components which trigger a 'change of context' are indicated, or the change of context can be reversed.

Interaction indicators contrastExploratory

Interaction indicators meet a ‘minimum contrast ratio text’ and meet a minimum thickness.

Editor's note

Needs additional research

End of note

Input controlExploratory

Interactive components are available to all navigation and input methods.

Name, role, value, stateExploratory

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

Non-Text contrastExploratory

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.

Editor's note

Needs additional research

End of note

Notify on changeExploratory

Notification is provided when previously viewed content changes.

Notify before activationExploratory

Controls that can alter the order of content convey their purpose prior to activation, and convey their impact on content order when activated.

Restore focusExploratory

The focus or point of regard is restored to its previous location after a temporary change of view.

Relevant focusExploratory

The focus order does not include repetitive, hidden, or static elements.

Target sizeExploratory

All functionality can be used without needing to accurately position a pointer.

Visual design of controlsExploratory

Controls that have similar function and behavior have a consistent visual design.

Input / operation

Comparable keyboard effortExploratory

The number of input commands required to complete a task using the keyboard is similar to the number of input commands when using other input modalities.

Editor's note

Needs additional research

End of note

Consistent keyboard interactionExploratory

Keyboard interface interactions are consistent.

Focus in viewportExploratory

The focus does not move to a position outside the current viewport, unless a mechanism is available to return to the previous focus point.

Gestures & draggingExploratory

Every function that can be operated by a pointer, can be operated by a ‘single pointer input’ or a sequence of single pointer inputs, without limitations on timing for input.

Keyboard commandsExploratory

Application keyboard commands do not conflict with platform commands, and the user is informed of non-standard commands.

Keyboard focus locationExploratory

The keyboard focus is visually indicated.

Keyboard onlyExploratory

All functionality can be performed through the keyboard interface only, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

No keyboard trapExploratory

If keyboard focus can be moved to an interactive component, then the keyboard focus can be moved away from that component.

Pointer-agnosticExploratory

Functionality which supports pointers can be used by any pointing device supported by the platform.

Pointer cancellationExploratory

Pointer cancellation is consistent.

Pointer locationExploratory

Users are able to determine where the pointer is located.

Specific pressureExploratory

Click activation using a pointer device does not require applying a specific pressure.

Editor's note

Needs additional research

End of note

Speed insensitiveExploratory

Use of a pointer does not require a particular speed of pointer movement or click activation.

Keyboard modeExploratory

The keyboard input mode is indicated.

Use without body movementExploratory

All functionality can be done without needing to move their body, except for accessibility supported input devices.

Use without device movementExploratory

All functionality can be done without needing to move the hardware device.

Varied inputsExploratory

Any input modality available on a platform can be used concurrently.

Layout

Clear navigationExploratory

Navigation elements are visually and programmatically differentiated from static content.

Clear relationshipsExploratory

The relationships between parts of the content is clearly indicated.

Clear starting pointExploratory

The starting point or home is visually and programmatically labeled.

CitationExploratory

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

Editor's note

Needs additional research

End of note

Consistent orderExploratory

The order of content and interactions remain consistent throughout a workflow.

Content orientationExploratory

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

Control locationExploratory

Controls are visually and programmatically located in an expected location.

Editor's note

Needs additional research

End of note

Current locationExploratory

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

Distinguishable relationshipsExploratory

Meaningful associations between distinct pieces of content are programmatically determinable.

Editor's note

Needs additional research

End of note

Distinguishable sectionsExploratory

Sections are visually and programmatically distinguishable.

Editor's note

Needs additional research

End of note

Familiar components and layoutExploratory

Common components and layouts are used.

Focus retentionExploratory

A user can focus on a content “area,” such as a modal or pop=up, then resume their view of all content using a limited number of steps.

Indicate 3rd party contentExploratory

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

Editor's note

Needs additional research

End of note

Interface redesignExploratory

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

Editor's note

Needs additional research

End of note

Multistep processExploratory

Provides context that orients the user in a site or multi-step process.

Notification of changeExploratory

Changes in content and updates notify users, regardless of the update speed.

Order of contentExploratory

Related information is grouped together within a visual and programmatic structure.

Organized contentExploratory

Provides context that orients the user in a site or multi-step process.

Reliable positioningExploratory

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

Section headersExploratory

Sections of content have well structured, understandable visual and programmatic headings.

Section lengthExploratory

Content is organized into short sections of related content.

Editor's note

Needs additional research

End of note

Section purposeExploratory

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

Visual stimulationExploratory

Use does not cause visual overstimulation.

Editor's note

Needs additional research

End of note

White spacingExploratory

Whitespace separates chunks of content.

Consistency across views

Consistent navigationExploratory

Navigation elements remain consistent across views within the product.

Multiple waysExploratory

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

Persistent navigationExploratory

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

Policy and Protection

Algorithm biasExploratory

Algorithms (including AI) used are not biased against people with disabilities.

Editor's note

Needs additional research

End of note

Clear agreementExploratory

The interface clearly indicates when a user is entering an agreement or submitting data.

Editor's note

Needs additional research

End of note

Disability information privacyExploratory

Disability information is not disclosed to or used by third parties and algorithms (including AI).

Editor's note

Needs additional research

End of note

Exploitive behaviorsExploratory

Task completion does not include exploitive behaviors.

Editor's note

Needs additional research

End of note

RedirectionExploratory

A mechanism is available to prevent fraudulent redirection or alert users they are exiting the site.

Editor's note

Needs additional research

End of note

Sensitive informationExploratory

Prompts to hide and remove sensitive information from observers are available.

Editor's note

Needs additional research

End of note

Social media algorithmExploratory

A mechanism is available to understand and control social media algorithms.

Editor's note

Needs additional research

End of note

Text and Wording

Acronyms and abbreviationsExploratory

The expanded form or meaning of abbreviations and acronyms is available.

Ambiguous numerical formattingExploratory

Alternative formats for ambiguous number formats are available.

Ambiguous pronunciationExploratory

All letters and diacritics needed to phonetically read words are available.

Appropriate toneExploratory

The language and tone used is respectful and appropriate to the topic or subject matter.

Editor's note

Needs additional research

End of note

Conveying importance without sizingExploratory

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

Double negativesExploratory

Content does not include double negatives to express a positive unless it is standard usage for that language or dialect.

Figurative languageExploratory

Explanations for figurative and non-literal language [such as jokes, sarcasm, hyperbole, metaphors, similes, and idioms] are available.

Interface VerbosityExploratory

The interface avoids overwhelming verbosity.

Editor's note

Needs additional research

End of note

ListsExploratory

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

Maximum text contrastExploratory

The rendered text against its background meets a maximum ‘contrast ratio test’ for its text appearance and use.

Editor's note

Needs additional research

End of note

Minimum text contrastExploratory

The rendered text against its background meets a minimum ‘contrast ratio test’ for its text appearance and use.

Editor's note

Needs additional research

End of note

Numbered stepsExploratory

Steps in a multi-step process are numbered.

Risk statementsExploratory

Clear explanations of the risks and consequences of choices, including use, are stated.

Editor's note

Needs additional research

End of note

Semantic text appearanceExploratory

Meaning conveyed by text appearance is programmatically available.

Editor's note

Needs additional research

End of note

Sentence voiceExploratory

The voice used is easiest to understand in context.

Editor's note

Needs additional research

End of note

Single ideaExploratory

Each segment of text [such as sentence, paragraph, bullet] presents one concept.

SummaryExploratory

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

Supplements to numerical conceptsExploratory

Text or visual alternatives are available for numerical concepts.

Text minimumExploratory

The rendered text meets a minimum font size and weight.

Editor's note

Needs additional research

End of note

Text styleExploratory

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

Text-to-speech supportedExploratory

Text content can be converted into speech.

Editor's note

Needs additional research

End of note

TitleExploratory

Content has a title or high-level description.

Topic sentenceExploratory

Each paragraph of text begins with a topic sentence stating the aim or purpose.

Uncommon wordsExploratory

Definitions for uncommon or new words are available.

Editor's note

Needs additional research

End of note

Unnecessary words or phrasesExploratory

Sentences are concise, without unnecessary filler words and phrases.

Verb tenseExploratory

The verb tense used is easiest to understand in context.

Editor's note

Needs additional research

End of note

Help and feedback

Consistent helpExploratory

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

Editor's note

Needs additional research

End of note

Contextual helpExploratory

Contextual help is available.

Conversational supportExploratory

Conversational support is available that allows both text and verbal communication.

Data visualization helpExploratory

Help understanding and using data visualizations is available.

Editor's note

Needs additional research

End of note

Feedback mechanismExploratory

Feedback can be provided.

Help using new interfacesExploratory

Help using new or changed interfaces is available.

Editor's note

Needs additional research

End of note

Personalizable helpExploratory

Adaptable/personalizable help is available.

Editor's note

Needs additional research

End of note

Sensory characteristicsExploratory

Instructions and help do not rely on sensory characteristics.

Supplements to textExploratory

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

Editor's note

Needs additional research

End of note

Support availableExploratory

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

Editor's note

Needs additional research

End of note

User Control

Adjust colorExploratory

Text and background colors can be customized.

Alternative presentationExploratory

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

Editor's note

Needs additional research

End of note

AT controlExploratory

Content can be controlled using assistive and adaptive technology.

Audio controlExploratory

Audio can be turned off, independent of the system audio, while allowing video to play.

Caption controlExploratory

The position and formatting of captions can be changed.

Chunk contentExploratory

Large amounts of data can be broken into smaller chunks.

Clear backgroundExploratory

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

Control interruptionsExploratory

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

Disturbing contentExploratory

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

Editor's note

Needs additional research

End of note

Haptic stimulationExploratory

Haptic feedback can be reduced or turned off.

Editor's note

Needs additional research

End of note

Interactive audio alternativeExploratory

The ability to look up terms within audio alternatives is available.

Editor's note

Needs additional research

End of note

Media alternative controlExploratory

Captions and audio descriptions can be turned on and off.

Media chaptersExploratory

Media can be navigated by chapters.

Editor's note

Needs additional research

End of note

Preferences apply to printing.Exploratory

Printing respects user’s content presentation preferences.

Editor's note

Needs additional research

End of note

ReflowExploratory

Content can be viewed in multiple size viewports, orientations, and zoom levels without loss of content, functionality and meaningful relationships and with scrolling only occurring in 1 direction.

Text CustomizationExploratory

Text appearance [font, size, etc] and layout [spacing, single column] can be customized by the user.

3rd party content presentationExploratory

Advertising and other third-party content that obscures the primary content can be moved or removed before interacting with it.

Editor's note

Needs additional research

End of note

Transform contentExploratory

Content can be transformed to make its purpose clearer.

Editor's note

Needs additional research

End of note

TriggersExploratory

Triggering content is indicated and the content and trigger warnings can be hidden.

Editor's note

Needs additional research

End of note

User settingsExploratory

User settings are honored when using or reviewing content.

Virtual cursorExploratory

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

3. ConformanceExploratory

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

Plain language summary of Conformance

You might want to make a claim that your content or product meets the WCAG 3 guidelines. If it does meet the guidelines, we call this “conformance.” To conform to WCAG 3, your test results must show that your project is accessible.

If you want to make a formal conformance claim, you must use the process described in this document. However, conformance claims are not required and your content can conform to WCAG 3, even if you don’t want to make a claim. You can still use this process to test your project’s accessibility.

There are two types of content in this document:

There are a variety of ways to say what is required in WCAG 3. We are experimenting with different approaches. Once we have developed enough guidelines, we will test how well each works. Here are some of the ideas for WCAG 3 requirements:

We intend to address the following topics in the future, but for now, you can skip them.

End of summary for Conformance

3.1 Normative requirements

In addition to this section, the Guidelines and Conformance sections in WCAG 3 provide normative content and define requirements that impact conformance claims. Introductory material, appendices, sections marked as non-normative, diagrams, examples, and notes are informative (non-normative). Non-normative material provides advisory information to help interpret the guidelines but does not create requirements that impact a conformance claim.

The key words MAY, MUST, MUST NOT, NOT RECOMMENDED, RECOMMENDED, SHOULD, and SHOULD NOT 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.2 Approaches to conformance

WCAG 3 will include a new conformance model to address a wider range of user needs, test a wider range of technologies and support new approaches to testing. We are exploring several approaches to conformance. After studying the comments on the previous draft, these are the concepts that showed promise. We are giving an overview in this draft, but we continue to test the combination of the concepts.

There are several goals for this new conformance model:

  1. Develop a model that encourages web sites to continue to improve accessibility (vs. stopping at the previous AA level);
  2. Better reflect the lived experience of people with disabilities, who successfully use sites that have some content that does not meet WCAG 2.0 AA, or who encounter barriers with sites that meet WCAG 2.0 AA; and
  3. Allow for bugs and oversight by content authors, provided the impact of them upon users with disabilities is not substantial.

The proposed approaches can fit together in a variety of ways. We will be testing these approaches and others for validity, reliability, sensitivity, adequacy, complexity and equity. We welcome suggestions on ways to improve these approaches to better meet these criteria and concerns about how they might affect accessibility. The working group plans to select from or even replace these options based on feedback, prototyping, and testing.

There are two main approaches to evaluating accessibility that are promising. There are also detailed ideas that support these approaches. The two main approaches are:

There are additional ideas that support these two approaches and can be used or combined in many different ways.

The details of these approaches change as we assemble them into a coherent whole. This draft gives a high level overview of these approaches so we can give an update and receive feedback on the individual approaches we are considering.

Editor's note

As we continue developing conformance, we seek input on the following:

  • Which option has the best chance of adoption and why?
  • How well do these approaches support regulatory needs?
  • How will these approaches be integrated into a conformance model (including levels or scores)?

Next steps include:

  • Further refine options,
  • Test the validity, reliability, sensitivity, adequacy, complexity and equity of the various models using these approaches, and
  • Write sample guidelines to test out each option.

End of note

3.3 Outcomes and methodsDeveloping

Editor's note

As we continue developing outcomes and methods, we seek input on how well the approach to outcomes, assertions and tests defined here supports additional requirements not addressed in 2.2.

Next steps include:

  • Get feedback from designers, developers, and other communities on wording choice,
  • Finalize names and descriptions of scope and tests,
  • Develop detailed examples of methods and tests,
  • As we develop example outcomes and methods, further explore conditions and how multiple measurements might be used to meet an outcome.
  • Address all GitHub issues under test types and terminology milestone.

End of note

3.3.1 Outcomes

Outcomes are verifiable statements that allow testers to reliably determine if the content being evaluated satisfies the user needs identified in the Guideline. All outcomes and assertions that relate to a Guideline will be listed together to encourage adoption of higher levels of accessibility.

Each outcome is associated with at least one method. Methods are informative and kept in how to documents. Each method contains techniques for meeting the outcome, examples, resources, and sets of tests for evaluating the outcome. Methods can apply to a specific technology, such as HTML, or can be more generic where the advice applies no matter what technology, such as the methods supporting the Clear Language guideline.

Outcomes are written so that testers can determine the accessibility of technologies based solely on the outcome, even when methods do not yet exist for those technologies.

3.3.2 Testing outcomes

3.3.2.1 Types of tests

WCAG 3 includes two (2) types of tests which are evaluated:

  • Quantifiable tests: Tests where there is a high degree of consistency between test results from different testers. Examples include testing whether certain properties exist in the content or if they match a value specified by the requirement.
  • Qualitative tests: Tests that rely on a qualitative evaluation based on existing criteria. Test results may vary between testers who understand the criteria. One example is evaluating the quality of alternative text used to meet a requirement for alternative text.

Most tests have prescribed ways to meet the test. In some cases, the ways to meet the test will change based on a specific condition being met (example: the human language of the content).

Although content may satisfy all outcomes using quantifiable and qualitative tests, the content may not always be usable by people with a wide variety of disabilities. The assertions (see Section 3.4.1 Assertions) are designed to address this problem.

3.3.2.1.1 Quantifiable tests

Quantifiable tests rely on measuring properties of the content based on nominal values. The test results are objectively verifiable, and avoid variation of test results between different testers. Values are quantifiable. They could be boolean (true/false), for example to check the presence of titles, text alternatives, and accessible names. Other values could include numerical thresholds; for example, to check color luminosity ratios.

Each method using quantifiable tests includes:

  • the values being tested; and
  • an algorithm to measure the properties of the content based on the values.
3.3.2.1.2 Qualitative tests

Qualitative tests rely on evaluating content based on a set of defined qualities and exceptions. The set of qualities and exceptions limit the scope of decisions, to minimize variation of test results arrived at by different testers. Still, some level of qualitative assessment is required, therefore the accuracy of the test results also depends on the knowledge and context of the testers to some degree.

Each method using qualitative tests includes:

  • the defined qualities being tested; and
  • guidance on evaluating how well the content meets the defined qualities.
3.3.2.2 Test scopes

Testing outcomes use items, views, user processes, and the product to define what is being tested.

Items are the smallest testable unit. They may be interactive components such as a drop down menu, a link, or a media player. They may also be units of content such as a word, a phrase, a label or error message, an icon, or an image.

Views include all content visually and programmatically available without a substantive change. Conceptually, views correspond to the definition of a web page as used in WCAG 2, but are not restricted to content meeting that definition. For example, a view could be considered a “screen” in a mobile app or a layer of web content – such as a modal.

User processes are a series of user actions, and the distinct interactive views and items that support the actions, where each action is required to complete an activity. A user process may include a subset of items in a view or a group of views.

Examples of a process include:

  • Logging into a web site and being recognized as an authenticated user;
  • Ordering an item, in which case the process includes the entire set of tasks from searching for the item, adding it to the shopping cart, paying for it, and receiving confirmation;
  • Submitting tax information, from start to end of the process; and
  • Interacting with other users in a virtual reality environment.

A process is comprised of one or more views or subsets of views. Only the part of the views that support the user process are included in a test of the user process.

The product is the combination of items, views, and user processes that collectively comprise the web site, set of web pages, web app, etc.

3.3.2.3 Conditions

Some tests only apply in certain situations. Testing may occasionally require determining and referencing which specifications are being tested. Methods will note whether a test always applies or under what conditions a test applies. Both quantitative and qualitative tests can be conditional.

3.4 Assertions and proceduresDeveloping

Editor's note

As we continue developing this content, we seek input on the following:

  • Can assertions be used to record accessibility work that is not required in the guidelines? This could include advance work on guidance not yet added to the guidelines.
  • What optional supporting documentation should organizations provide with an assertion?
  • Is there a need for WCAG 3 to require proof of an assertion, and if so, what documentation should be required as proof?
  • Should assertions be dated, expire, or be reviewed on a regular basis?
  • Can steps in a procedure duplicate tests in other parts of the guidelines? If so, how should those be handled?
  • Can assertions exist outside of conformance? For example, can they be used as an internal benchmark rather than for a claim of conformance?
  • Can assertions be used at the most basic level of conformance? If so, how?
  • How can small organizations use assertions without unrealistic burden?
  • As written, outcomes and assertions are at the same level. Would moving assertions to the test level be more effective?
  • The AGWG is considering whether and how assertions can be applied to the Bronze level.
  • The AGWG is considering what will qualify as a procedure in WCAG 3. A procedure may be limited to guidance:
    • approved by AGWG and listed in WCAG,
    • that references publicly published guidance, or
    • that meets criteria specified in WCAG
    or it may be any process that an organization uses to improve accessibility. Comments or criticism of these alternatives is welcome.

Next steps include:

  • Better define procedure,
  • Develop detailed examples of methods and test,
  • Test the accuracy, reliability, repeatability, etc. of this approach

End of note

3.4.1 Assertions

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

3.4.2 Using assertions

Assertions may supplement methods in one or more outcomes. Assertions should only be used on outcomes and guidelines that allow assertions. Organizations can make an assertion that they followed a procedure to claim conformance. Results when testing assertions are true/false - the organization making the assertion either provided the required documentation or it did not.

Procedures used in assertions may be implemented at the organization level, during design and development, or during testing.

Examples of procedures that may be used during implementation might include:

  • Training,
  • FTE (Full Time Equivalent) assignments,
  • Skills testing,
  • Coordination and documentation of accessibility processes, or
  • Setting the priority for remediation.

Examples of procedures that may be used to evaluate accessibility might include:

  • Usability testing,
  • Heuristic evaluation, or
  • Assistive technology testing.

3.4.3 Documenting assertions

Assertions must be documented as part of the conformance claim process. The required information may also be made available through the web site.

Assertions might include the following information:

  • The statement being asserted,
  • The date of the assertion,
  • The date or date range the procedure was completed,
  • The scope of the assertion,
  • Contact information for the person or group making the assertion, and
  • The outcome(s) or guideline(s) supported by the assertion.
Editor's note

An alternative to specifying assertions at the outcome or guideline level might be to require the assertion apply to the scope of the conformance claim.

End of note

3.4.4 Supporting documentation for assertions

WCAG recommends maintaining additional information that an organization can use to improve or validate procedures and assertions. WCAG will not require organizations to provide supporting documentation to conform.

3.4.5 Testing assertions

The quality of an assertion can be tested based on how well the assertion meets the documentation requirements for assertions (See Documenting Assertions). Conforming to WCAG does not require testing supporting documentation; however, organizations may decide to adopt additional documentation requirements based on the procedure being asserted.

3.5 Conformance levelsExploratory

WCAG 3 defines three levels of conformance: bronze, silver, and gold. While it is easy to replicate the WCAG 2 A, AA, AAA by renaming the levels, there is an opportunity to improve accessibility for people with disabilities by using a more advanced approach.

Bronze is the minimum conformance level. Content that does not meet the requirements of the bronze level does not conform to WCAG 3. To reach Bronze level, the scope claimed in the conformance statement must pass a subset of outcomes and assertions. The subset will require enough outcomes and assertions to improve equity across functional needs.

Silver level incentivizes organizations to go further to improve accessibility. One possibility that we are examining is that Silver level points can accumulate even prior to completing bronze but are not usable until Bronze is achieved. The goal is to encourage organizations to go beyond the minimum, especially where organizations want to be recognized for their efforts to go beyond minimum accessibility.

Gold level identifies measures we want to include for those organizations that do achieve Silver so that some can stand out as exemplary, cutting edge, and role models. There are a number of ideas that will be developed further once more of the conformance structure is solidified.

3.6 Issue severityExploratory

Editor's note

Severity rating could contribute towards scoring and prioritization.

As we continue developing this content, we seek input on the following:

  1. Is every issue critical to someone, making this concept invalid?
  2. How best to assign severity, particularly if testers have different ideas on what is critical?
  3. How do we incorporate context/process/task? Is that part of scoping, or issue severity? Both are important to the end result.
  4. What to do with non-critical issues?
  5. If included, how will situations where severity depends on context be handled?
  6. Can the matrix inform designation of functional categories? For example, the Text Alternative Available outcome.
  7. How will issue severity fit into levels? For example:
    • “Bronze” could be an absence of any critical or high issues;
    • “Silver” could be an absence of any critical, high, or medium issues.
  8. How to account for cumulative issues becoming critical?
  9. Would another approach be more effective, for example assigning critical issues after testing is complete based on task or type of task rather than by test?

Next steps include:

  • Testing the assumption that some failures cause a greater impact to users than others or whether all guidelines and contexts are important to some individuals.
  • Explore whether the concept of issue severity can be applied consistently and effectively.

End of note

Outcomes may allow for the concept of varying severity. High severity issues are those which prevent users from completing user processes (tasks).

Tests could include critical issues. Each test could have a category of severity, so some tests will be flagged as causing a critical issue.

3.7 Adjectival ratingsExploratory

Adjectival Ratings allow test results to go beyond Pass or Fail to show progress towards a goal or exceeding a goal. Example of Possible adjectival ratings are:

Outcomes or guidelines could be evaluated using adjectival ratings on both directly quantifiable outcomes and qualitative measures that are asserted. Outcomes might be assigned an adjectival rating based on methods used to meet the outcome and issue severity. Guidelines might be assigned an adjectival rating based on the outcomes and assertions completed under the guideline.

3.8 PercentagesExploratory

Editor's note

We are exploring whether percentages could apply to Bronze but have not found a model to date where this works without adding complexity and time needed for testing.

As we continue developing this content, we seek input on the following:

  • How can percentages be used in a way that is equitable across disabilities?

End of note

In this approach, percentage of outcomes and assertions passed or percentage passed at a certain adjectival rating might be used to conform to Silver and Gold levels.

3.9 Pre-assessment checksExploratory

Pre-Assessment checks are tests or criteria that implementers can use to determine if they are ready to assess conformance. The intent of specifying these would be to help implementers prepare for conformance testing, not to create a new level of conformance. Examples of pre-assessment checks might be:

3.10 Only accessibility-supported ways of using technologiesPlaceholder

Editor's note

We continue to explore how the WCAG 2 concept of accessibility-supported fits into proposed conformance models.

End of note

3.11 Defining conformance scopeExploratory

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

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

End of note

3.12 Conformance requirementsExploratory

For technology to conform to WCAG 3, the following conformance requirements apply:

  1. Conformance level - Content MUST meet the requirements of the selected conformance level.

3.13 Conformance claimsExploratory

Conformance claims are not required. Authors can conform to WCAG 3 without making a claim. The material below describes how to make a conformance claim if that option is chosen.

3.13.1 Required components of a conformance claim

A conformance claim MUST include the following information:

  1. Date of the claim;
  2. Guidelines title, version and URI W3C Accessibility Guidelines 3.0 at https://www.w3.org/TR/wcag-3.0/
  3. Conformance level satisfied: (bronze, silver, or gold);
  4. A concise description of the views and processes, such as a list of URIs for which the claim is made, including any state changes which lead to a new view; and
  5. The technology including the hardware, software, and assistive technology used to test the claim.

3.13.2 Example conformance claim

On 12 August 2020, the following 10 views and 2 processes conform to WCAG 3 at a bronze level. Processes were selected because they are the most common activities on the web site and include 4 unique views. The other 6 views are the most commonly used.

These were tested using Firefox and Chrome on a Windows platform. The assistive technology used included JAWS and Dragon.

3.14 Conforming alternative versionPlaceholder

Editor's note

We continue to explore how the WCAG 2 concept of conforming alternative versions fit into proposed conformance models.

End of note

4. User-generated contentExploratory

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

Plain language summary of User-generated content

User-generated content is content written by the public and customers. WCAG 3.0 may use different advice or steps for user-generated content to improve accessibility than for content created by the publisher. WCAG 3.0 proposes that organizations identify user-generated content and identify the steps taken to encourage accessibility.

End of summary for User-generated content

Editor's note

It remains to be determined how to address user-generated content that has accessibility issues; and to define what minimum thresholds might be acceptable. We expect WCAG 3 to provide this guidance within individual guidelines and outcomes and to support testing for conformance. The working group is looking at alternative requirements to apply to user-generated content guideline by guideline, and is seeking feedback on what would serve as reasonable requirements on how to best support accessibility in user-generated content with known (or anticipated) accessibility issues.

One example would be “alternative text”. The Authoring Tool Accessibility Guidelines (ATAG) has specific guidance for providing a mechanism for alternative text. The ATAG 2.0 Guideline B.2.3 - “Assist authors with managing alternative content for non-text content” could be adapted to provide specific, guideline-related guidance for user generated alternative text.

The working group intends to more thoroughly address the contents and the location of an accessibility statement in a future draft.

End of note

Web content publishers may include content provided by the users of their digital products. We refer to such content as “user-generated content”.

Examples of user-generated content include:

User-generated content is provided for publication by visitors where the content platform specifically welcomes and encourages it. User-generated content is content that is submitted through a user interface designed specifically for members of the public and customers. Use of the same user interface as an authoring tool for publication of content by agents of the publisher (such as employees, contractors, or authorized volunteers) acting on behalf of the publisher does not make that content user-generated content. The purpose of the user-generated content conformance section is to allow WCAG 3 outcomes and methods to require additional or different steps to improve the accessibility of user-generated content.

An important part of WCAG conformance is the specific guidance that is associated with individual WCAG 3 guidelines and outcomes. Not all WCAG 3 guidelines will have unique outcomes and testing for user-generated content. Unless user-generated content requirements are specified in a particular guideline, that guideline applies as written whether or not the content is user generated.

The web content publisher should identify all locations of user-generated content (such as commentary on hosted content, product descriptions for consumer to consumer for sale listings, and restaurant reviews) and perform standard accessibility evaluation analysis for each. If there are no accessibility issues, the user-generated content is fully conforming.

4.1 Steps to conform

If accessibility issues are identified, or if the web site author wants to proactively address potential accessibility issues that might arise from user-generated content, then all of the following must be indicated alongside the user-generated content or in an accessibility statement published on the web site or product that is linked from the view or page in a consistent location:

  1. Clearly identify where user-generated content can be found on the publisher’s digital product (perhaps by id href);
  2. Clearly identify the steps taken to encourage accessibility in user-generated content such as prompting the user for alternative text for their uploaded images before they are accepted and prohibiting text attributes except as they are part of semantic markup such as strong, headings, etc.;

5. 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.

End of note

Adequacy

Adequacy is subtle metric, but important to WCAG 3 proposals. Adequacy describes if the formulas being used to process and score the accessibility testing results are using such a small interval that small changes in accessibility do not cause large changes in scoring. Benchmarking Web Accessibility Metrics, Vigo, Lopes, O Connor, Brajnik, Yesilada 2011.

Adjectival Ratings

A system to report evaluation results as a set of human-understandable adjectives.

Assertion

A 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.

Automated evaluation

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

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.

Best Practice

Methods which are not required and meet a higher requirement than methods required to conform to Bronze.

Complexity

Complexity refers to the resources required to accomplish the conformance testing. These could be crawler time, or time for human judgment testing. This would be a useful metric to have to answer the question of how much time WCAG 3 takes to test as compared to WCAG 2. Benchmarking Web Accessibility Metrics, Vigo, Lopes, O Connor, Brajnik, Yesilada 2011.

Conformance

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 Conformance.

Deprecate

To 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.

Equity

Equity is the outcome of processes and actions that ensure the spectrum of human reality obtains what is needed to participate, not solely access. As equity relates to WCAG it is about the impact the standards/guidelines have on people with disabilities, along with actually including people with disabilities in the work.

Evaluation
The process of examining content for conformance to these guidelines.
Different approaches to evaluation include automated evaluation, semi-automated evaluation, human evaluation, and user testing.
Functional need

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

Guideline

High-level, plain-language content used to organize outcomes.

Guidelines provide a high-level, plain-language version of the content 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 outcomes 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 outcomes and are technology-independent.

Human evaluation

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

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.

Informative

Content provided for information purposes and not required for conformance.

Method

Detailed information, either technology-specific or technology-agnostic, on ways to meet the outcome as well as tests and scoring information.

Normative

Content whose instructions are required for conformance.

Outcome

Result of practices that reduce or eliminate barriers that people with disabilities experience.

See Outcomes.

Point of Regard

The position in rendered content that the user is presumed to be viewing. The dimensions of the point of regard can vary. For example,it can be a two-dimensional area (e.g. content rendered through a two-dimensional graphical viewport), or a point (e.g. a moment during an audio rendering or a cursor position in a graphical rendering), or a range of text (e.g. focused text), or a two-dimensional area (e.g. content rendered through a two-dimensional graphical viewport). The point of regard is almost always within the viewport, but it can exceed the spatial or temporal dimensions of the viewport (see the definition of 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 (e.g. 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.

Process

A sequence of steps that need to be completed to accomplish an activity / task from end-to-end.

Reliability

The reproducibility and consistency of scores i.e. the extent to which they are the same when evaluations of the same resources are carried out in different contexts (different tools, different people, different goals, different time). This would be particularly useful to ensure that similar results are achieved by different testers. It would also be useful to see if different testers would select the same path or off-path decisions. Representative sampling tests also fit in this category. Benchmarking Web Accessibility Metrics, Vigo, Lopes, O Connor, Brajnik, Yesilada 2011.

Semi-Automated Evaluation

Evaluation conducted using machines to guide humans to areas that need inspection.

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

Sensitivity

Sensitivity of a metric is related to the extent that changes in the output of the metric are quantitatively related to changes of the accessibility of the web site being analyzed. This metric is useful for determining if the conformance proposal captures the impact of the severity of accessibility barriers on the final score and if different disabilities are treated equally by the proposal. Benchmarking Web Accessibility Metrics, Vigo, Lopes, O Connor, Brajnik, Yesilada 2011.

Set of Tests

A group of tests that supports a method.

Test

Mechanism to evaluate implementation of a method.

Technique

Technology-specific approach to follow a method.

User need

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

User testing

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 outcomes.

Validity

The extent to which the measurements obtained by a metric reflect the accessibility of the web site to which it is applied. Does the rating that a web site or digital product achieve in any conformance proposal actually reflect the rating that it should get? Benchmarking Web Accessibility Metrics, Vigo, Lopes, O Connor, Brajnik, Yesilada 2011. Accessed on 29 July 2020

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.

End of note

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.

End of note

C. Guidelines development methodology

Plain language summary of Guidelines development methodology

WCAG 3 includes some of the information from WCAG 2, guidelines for tools to create web content (ATAG), and guidelines for browsers, media players, and similar software (UAAG). The WCAG 3 design is based on research. You can read more about the Requirements for WCAG 3.0.

End of summary for Guidelines development methodology

C.1 Relationship to other W3C guidelines

The Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG20] were designed to be technology neutral, and have stayed relevant for over 10 years. The Authoring Tool Accessibility Guidelines (ATAG) 2.0 [ATAG20] provide guidance for various types of software that assist people in writing accessible content. User Agent Accessibility Guidelines (UAAG) 2.0 [UAAG20] offers useful guidance to user agent developers and has been implemented on an individual success criterion basis.

These guidelines have normative guidance for content and helpful implementation advice for authoring tools, user agents, and assistive technologies.

For more details about differences from previous guidelines, see Appendix: Differences From WCAG 2.

C.2 Goals and requirements

The goal of WCAG 3 and supporting documents is to make digital products including web, ePub, PDF, applications, mobile apps, and other emerging technologies more accessible and usable to people with disabilities. It is the intention for WCAG 3 to meet this goal by supporting a wider set of user needs, using new approaches to testing, and allowing more frequent maintenance of guidelines to keep pace with accelerating technology change. The hope is that WCAG 3 will make it significantly easier for both beginners and experts to create accessible digital products that support the needs of people with disabilities.

Research and design work performed by the Silver Task Force identified key requirements needed to improve upon the existing WCAG 2 structure. These requirements, presented in the Requirements for WCAG 3 document, shaped the guidelines that follow and should be taken into account when evaluating and updating the guidelines.

D. Differences from WCAG 2

D.1 Outcomes

Outcomes are different from WCAG 2 success criteria. Compared to success criteria, outcomes are written to be:

The design of outcomes allows more varied needs of people with disabilities than could have been included in WCAG 2. 

Methods map approximately to WCAG 2 Techniques documents.

D.2 Approximate mapping of WCAG 2 and WCAG 3 documentation

WCAG 2 WCAG 3
Success Criteria Outcomes
Techniques Methods
Understanding How-to

E. Change log

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

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

F. Acknowledgements

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

F.1 Participants who made notable contributions to the creation of this document

This section documents participants who made significant contributions in leadership or participating in subgroups.

F.2 Prior Contributors

F.2.1 Participants of the Silver Task Force and Silver Community Group who contributed to the 2021 and 2020 versions of this document

  • Jake Abma
  • Charles Adams
  • Jennison Asuncion
  • Bruce Bailey
  • Frederick Boland
  • Omar Bonilla
  • Alice Boxhall
  • Rachael Bradley Montgomery
  • Shari Butler
  • Sheri Byrne-Haber
  • Jennifer Chadwick
  • Wendy Chisholm
  • Victoria Clark
  • Kelsey Collister
  • Joshue O Connor
  • Michael Cooper
  • Michael Crabb
  • Joe Cronin
  • Kim Dirks
  • David Fazio
  • Wilco Fiers
  • Detlev Fischer
  • John Foliot
  • Luis Garcia
  • Lucy Greco
  • Charles Hall
  • Ryan Hemphill
  • Katharina Herzog
  • Scott Hollier
  • Angela Hooker
  • Sarah Horton
  • Matthew King
  • Andrew Kirkpatrick
  • John Kirkwood
  • Peter Korn
  • JaEun Ku
  • Shawn Lauriat
  • Michellanne Li
  • Todd Libby
  • Imelda Llanos
  • Thomas Logan
  • Eleanor Loiacono
  • Chris Loiselle
  • David MacDonald
  • John McNabb
  • Peter McNally
  • Jan McSorley
  • Mary Jo Mueller
  • Lyn Muldrow
  • Charles Nevile
  • Christy Owens
  • Kimberly Patch
  • Christian Perera
  • Melanie Philipp
  • Jill Power
  • Sarah Pulis
  • John Rochford
  • Abi Roper
  • Cybele Sack
  • Shrirang Sahasrabudhe
  • Janina Sajka
  • Karen Schriver
  • Stein Erik Skotkjerra
  • David Sloan
  • Andrew Somers
  • Jeanne Spellman
  • Ruth Spina
  • Francis Storr
  • David Swallow
  • Mark Tanner
  • Suzanne Taylor
  • Makoto Ueki
  • Sweta Wakodkar
  • Takayuki Watanabe
  • Léonie Watson
  • Thomas Westin

F.2.2 Participants of the Accessibility Guidelines Working Group who reviewed the 2021 and 2020 versions of this document

  • Jake Abma
  • Shadi Abou-Zahra
  • Chuck Adams
  • Amani Ali
  • Jim Allan
  • Paul Adam
  • Jon Avila
  • Bruce Bailey
  • Garenne Bigby
  • Rachael Bradley Montgomery
  • Judy Brewer
  • Shari Butler
  • Alastair Campbell
  • Laura Carlson
  • Pietro Cirrincione
  • Michael Cooper
  • Jennifer Delisi
  • Wayne Dick
  • Kim Dirks
  • Shwetank Dixit
  • Nicaise Dogbo
  • E.A. Draffan
  • Michael Elledge
  • David Fazio
  • Wilco Fiers
  • Detlev Fischer
  • John Foliot
  • Betsy Furler
  • Matt Garrish
  • Alistair Garrison
  • Michael Gower
  • Charles Hall
  • Katie Haritos-Shea
  • Andy Heath
  • Shawn Henry
  • Sarah Horton
  • Abi James
  • Marc Johlic
  • Andrew Kirkpatrick
  • John Kirkwood
  • Peter Korn
  • JaEun Ku
  • Patrick Lauke
  • Shawn Lauriat
  • Steve Lee
  • Chris Loiselle
  • Greg Lowney
  • David MacDonald
  • Chris McMeeking
  • Jan McSorley
  • Melina Möhnle
  • Mary Jo Mueller
  • Gundula Niemann
  • Brooks Newton
  • Caryn Pagel
  • Justine Pascalides
  • Kim Patch
  • Melanie Philipp
  • Ruoxi Ran
  • Stephen Repsher
  • John Rochford
  • Cybele Sack
  • Janina Sajka
  • Lisa Seeman-Kestenbaum
  • Glenda Sims
  • Avneesh Singh
  • Andrew Somers
  • Jaeil Song
  • Jeanne Spellman
  • Makoto Ueki
  • Kathleen Wahlbin
  • Léonie Watson

F.2.3 Research Partners

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

  • David Sloan and Sarah Horton, The Paciello Group, WCAG Success Criteria Usability Study
  • Scott Hollier et al, Curtin University, Internet of Things (IoT) Education: Implications for Students with Disabilities
  • Peter McNally, Bentley University, WCAG Use by UX Professionals
  • Dr. Michael Crabb, University of Dundee, Student research papers on Silver topics
  • Eleanor Loiacono, Worcester Polytechnic Institute Web Accessibility Perceptions (Student project from Worcester Polytechnic Institute)

F.3 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.

G. References

G.1 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/
[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
[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/
[WCAG20]
Web Content Accessibility Guidelines (WCAG) 2.0. Ben Caldwell; Michael Cooper; Loretta Guarino Reid; Gregg Vanderheiden et al. W3C. 11 December 2008. W3C Recommendation. URL: https://www.w3.org/TR/WCAG20/
[WCAG22]
Web Content Accessibility Guidelines (WCAG) 2.2. Michael Cooper; Andrew Kirkpatrick; Alastair Campbell; Rachael Bradley Montgomery; Charles Adams. W3C. 5 October 2023. W3C Recommendation. URL: https://www.w3.org/TR/WCAG22/