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-20241212/
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)
[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 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 technical reports index at https://www.w3.org/TR/.

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

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

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 [email protected] (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 [email protected] (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
Foundational requirement: Equivalent text alternativeDeveloping

Equivalent text alternative is available for image that conveys content.

Foundational requirement: Detectable imageDeveloping
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

Auto generated text descriptions are editable by content creator.

Editor's note

Needs additional research

Assertion: Style guideExploratory

Text alternatives follow an organizational style guide.

2.1.2 Media alternatives

Users have equivalent alternatives for media content.

Requirement: Audio descriptionsExploratory

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

Requirement: CaptionsExploratory

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

Requirement: Descriptive transcriptsExploratory

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

Requirement: Findable media alternativesExploratory

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

Editor's note

Needs additional research

Requirement: Preferred languageExploratory

Equivalent audio alternatives are available in the preferred language.

Editor's note

Needs additional research

Requirement: 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

2.1.3 Nontext alternatives

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

Requirement: Nontext contentExploratory

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

Editor's note

Needs additional research

2.1.4 Figure captions

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

Requirement: Persistent captionsExploratory

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

Editor's note

Needs additional research

2.1.5 Single sense

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

Requirement: Use of hueExploratory

Information conveyed by graphical elements does not rely on hue.

Editor's note

Needs additional research

Requirement: Use of visual depthExploratory

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

Editor's note

Needs additional research

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

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

Editor's note

Needs additional research

Requirement: Minimum text contrast

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

Editor's note

Needs additional research

Requirement: Text sizeExploratory

The rendered text meets a minimum font size and weight.

Editor's note

Needs additional research

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

Text content can be converted into speech.

Editor's note

Needs additional research

Requirement: Human languageExploratory

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

Requirement: Semantic text appearanceExploratory

Meaning conveyed by text appearance is programmatically available.

Editor's note

Needs additional research

2.2.3 Clear meaningDeveloping

Users can access explanations of or alternatives to ambiguous text content.

Which foundational requirements apply?

For each item of ambiguous text, such as non-literal text, abbreviations and acronyms, ambiguous numbers, or text missing letters or diacritics:

  1. Is the text presented in a way that is available to user agents, including assistive technology (AT)?
  2. Does the accessibility support set meet Explain ambiguous text or provide an unambiguous alternative?
    • Yes, pass. Stop.
    • No, continue.
  3. Does the author meet Explain ambiguous text or provide an unambiguous alternative?
    • Yes, pass. Stop.
    • No, fail.

Exception

  • If the purpose is to showcase works of art or fiction, such as a poetry journal or fictional stories, this guideline does not apply. However, if the purpose is to educate students about art or fiction, then this guideline applies.
Foundational requirement: Detectable text

Text is programmatically determinable

Foundational requirement: Unambiguous text

Explain ambiguous text or provide an unambiguous alternative.

2.2.4 Simplified written content

Users are not required to navigate complex words or sentence structures in order to understand content.

Requirement: Appropriate toneExploratory

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

Editor's note

Needs additional research

Requirement: Double negativesExploratory

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

Requirement: Sentence voiceExploratory

The voice used is easiest to understand in context.

Editor's note

Needs additional research

Requirement: Uncommon wordsExploratory

Definitions for uncommon or new words are available.

Editor's note

Needs additional research

Requirement: Unnecessary words or phrasesExploratory

Sentences are concise, without unnecessary filler words and phrases.

Requirement: Verb tenseExploratory

The verb tense used is easiest to understand in context.

Editor's note

Needs additional research

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

@@

Requirement: Exploratory
Style guide

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

Interactive components are visually and programmatically located in conventional locations.

Editor's note

Needs additional research

Requirement: ConventionsExploratory

Interactive components follow established conventions.

Editor's note

Needs additional research

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

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

Requirement: Control importanceExploratory

The importance of interactive components is indicated.

Editor's note

Needs additional research

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 Input operation

Users can use different input techniques and combinations and switch between them.

Requirement: Concurrent inputsExploratory

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

Requirement: Hover informationExploratory

Users can dismiss additional content (triggered by hover) without moving the pointer, unless the additional content communicates an input error or does not obscure or replace other content.

Requirement: Input controlExploratory

Interactive components are available to all navigation and input methods.

2.4.2 Content changes

Users are aware of changes to content or context.

Requirement: Notify about changeExploratory

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

Requirement: Notify on changeExploratory

Notification is provided when viewing content that was previously viewed is changed.

Requirement: Inform before activationExploratory

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

Requirement: Reverse change of contextExploratory

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

2.4.3 Target size

Users are not required to accurately position a pointer in order to view or operate content.

Requirement: Target size minimumExploratory

The combined target size and spacing to adjacent targets is at least 24x24 pixels

Requirement: Target size optimumExploratory

The combined target size and spacing to adjacent targets is at least 48x48 pixels.

2.4.4 Keyboard operation

Users can navigate and operate content using only the keyboard focus.

Requirement: 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

Requirement: Conflicting keyboard commandsExploratory

Authored keyboard commands do not conflict with platform commands or they can be remapped.

Requirement: Consistent keyboard interactionExploratory

Keyboard interface interactions are consistent.

Requirement: Keyboard modeExploratory

If the keyboard is non-hardware (such as a virtual keyboard), the keyboard input mode is indicated.

Requirement: Keyboard onlyExploratory

All functionality must be accessible through the keyboard, except when a task requires input based on the user's specific input action.

Requirement: No keyboard trapExploratory

If keyboard focus can be moved to an interactive component, then the keyboard focus can be moved away from that component, or the component can be dismissed, with focus returning to the previous point.

Requirement: Non-standard commandsExploratory

The user is informed of non-standard authored keyboard commands.

2.4.5 Gestures

Users are not required to use gestures or dragging to view or operate content.

Requirement: Change focus with pointer deviceExploratory

Selecting an interactive component with a pointer sets the focus to that element.

Requirement: Complex pointer inputsExploratory

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 requiring certain timing.

Requirement: Pointer-agnosticExploratory

Functionality which supports pointers is available to any pointer device supported by the platform.

Requirement: Pointer cancellationExploratory

The method of pointer cancellation is consistent.

Requirement: Specific pressureExploratory

Where specific pressures are used, they can be adjusted and/or disabled without loss of function.

Editor's note

Needs additional research

Requirement: Speed insensitiveExploratory

Where specific speeds are used, they can be adjusted and/or disabled without loss of function.

Editor's note

Needs additional research

2.4.6 Motion input

Users are not required to move their bodies or devices to operate functionality.

Requirement: Use without body movementExploratory

All functionality that requires full or gross body movement may also be accomplished with a standard input device.

Requirement: Use without device movementExploratory

All functionality can be completed without reorienting or repositioning hardware devices.

2.5 Error handling

2.5.1 Correct mistakes

Users know about and can correct mistakes.

Requirement: Error associationExploratory

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 identificationExploratory

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

Requirement: Error notificationExploratory

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

Requirement: Persistent errorsExploratory

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

Requirement: Visible errorsExploratory

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

2.6 Animation and movement

2.6.1 Avoid physical harm

Users do not experience physical harm from content.

Requirement: 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

Requirement: FlashingExploratory

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

Requirement: MotionExploratory

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

Editor's note

Needs additional research

Requirement: Motion from interactionExploratory

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.

Editor's note

Needs additional research

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

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.

Editor's note

Needs additional research

Requirement: Distinguishable sectionsExploratory

Sections are visually and programmatically distinguishable.

Editor's note

Needs additional research

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

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

Editor's note

Needs additional research

Requirement: Multistep processExploratory

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

Requirement: Contextual informationExploratory

Provide contextual information 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

Content is organized into short sections of related content.

Editor's note

Needs additional research

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.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, 3rd 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

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

Editor's note

Needs additional research

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.

Requirement: Deceptive controlsExploratory

Interactive components are not deceptively designed.

Editor's note

Needs additional research

Requirement: Exploitive behaviorsExploratory

Process completion does not include exploitive behaviors.

Editor's note

Needs additional research

Requirement: MisinformationExploratory

Processes can be completed without navigating misinformation or redirections.

Editor's note

Needs additional research

Requirement: PreselectionsExploratory

Preselected options are visible by default during process completion without additional interactions.

Requirement: RedirectionExploratory

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

Editor's note

Needs additional research

2.9.5 Retain information

Users do not have to reenter information or redo work.

Requirement: Go back in processExploratory

In a multistep 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. c

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 multistep process are available

2.10 Policy and protection

2.10.1 Content source

Users can determine when content is provided by a Third Party

Requirement: CitationExploratory

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

Editor's note

Needs additional research

Requirement: Indicate 3rd party contentExploratory

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

Editor's note

Needs additional research

Requirement: Obscuring primary contentExploratory

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

Editor's note

Needs additional research

2.10.2 Security and privacy

Users’ safety, security or privacy are not decreased by accessibility measures.

Requirement: Clear agreementExploratory

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

Editor's note

Needs additional research

Requirement: Disability information privacyExploratory

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

Editor's note

Needs additional research

Requirement: Sensitive informationExploratory

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

Editor's note

Needs additional research

Requirement: Risk statementsExploratory

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

Editor's note

Needs additional research

2.10.3 Algorithms

Users are not disadvantaged by algorithms.

Requirement: Algorithm biasExploratory

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

Editor's note

Needs additional research

Requirement: Social media algorithmExploratory

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

Editor's note

Needs additional research

2.11 Help and feedback

2.11.1 Help available

Users have help available.

Requirement: Consistent helpExploratory

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

Editor's note

Needs additional research

Requirement: Contextual helpExploratory

Contextual help is available.

Requirement: Conversational supportExploratory

Conversational support allowing both text and verbal modes is available.

Requirement: Data visualizationsExploratory

Help is available to understand and use data visualizations.

Editor's note

Needs additional research

Requirement: New interfacesExploratory

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

Requirement: Personalizable helpExploratory

Help is adaptable and personalizable.

Editor's note

Needs additional research

Requirement: Sensory characteristicsExploratory

Instructions and help do not rely on sensory characteristics.

Requirement: Support availableExploratory

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

Editor's note

Needs additional research

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

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

Editor's note

Needs additional research

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

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

Editor's note

Needs additional research

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

Content can be transformed to make its purpose clearer.

Editor's note

Needs additional research

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

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

Editor's note

Needs additional research

Requirement: Media alternative controlExploratory

Captions and audio descriptions can be turned on and off.

Requirement: Media chaptersExploratory

Media can be navigated by chapters.

Editor's note

Needs additional research

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

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

Editor's note

Needs additional research

Requirement: Haptic stimulationExploratory

Haptic feedback can be reduced or turned off.

Editor's note

Needs additional research

Requirement: TriggersExploratory

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

Editor's note

Needs additional research

Requirement: VerbosityExploratory

Overwhelming wordiness can be reduced or turned off.

Editor's note

Needs additional research

Requirement: Visual stimulationExploratory

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

Editor's note

Needs additional research

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

Printing respects user's content presentation preferences.

Editor's note

Needs additional research

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

Ambiguous numbers
Editor's note

To be defined.

Accessibility support setDeveloping

The group of user-agents and assistive technologies you test with.

Editor's note

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

AssertionDeveloping

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.

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

Content
Editor's note

To be defined.

Contrast ratio test
Editor's note

To be defined.

Decorative image
Editor's note

To be defined.

DeprecateDeveloping

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.

Element
Editor's note

To be defined.

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 needDeveloping

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

GuidelineDeveloping

High-level, plain-language outcome statements used to organize requirements.

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.

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.

Image
Editor's note

To be defined.

Image role
Editor's note

To be defined.

Image type
Editor's note

To be defined.

InformativeDeveloping

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

Interactive component
Editor's note

To be defined.

ItemsDeveloping

The smallest testable unit for testing scope. They 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.

MethodDeveloping

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

Non-literal text

Non-literal text uses words or phrases in a way that goes beyond their standard or dictionary meaning to express deeper, more complex ideas. This is also called figurative language. To understand it, users have to interpret the implied meaning behind the words, rather than just their literal or direct meaning.

Examples: Allusions, hyperbole, idioms, irony, jokes, litotes, metaphors, metonymies, onomatopoeias, oxymorons, personification, puns, sarcasm, and similes. More detailed examples are available in the Methods section.

NormativeDeveloping

Content whose instructions are required for conformance.

Pointer
Editor's note

To be defined.

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.

ProductDeveloping

Testing scope that is a combination of all items, views, and task flows that comprise the web site, set of web pages, web app, etc.

Programmatically determinable
Editor's note

To be defined.

Requirement

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

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.

Single pointer input
Editor's note

To be defined.

Task flowDeveloping

Testing scope that includes a series views that support a specified user activity. 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.

TestDeveloping

Mechanism to evaluate implementation of a method.

Text
Editor's note

To be defined.

User agent
Editor's note

To be defined.

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

ViewDeveloping

Testing scope that includes all content visually and programmatically available without a significant 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 dialog.

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/
[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. 5 October 2023. W3C Recommendation. URL: https://www.w3.org/TR/WCAG22/