In 2021, I gave a lecture with a brief analysis of the contents of the WCAG 3 document. It was one of the early versions of the document, and a lot has changed since then. So, what better way to follow up than by writing a new article about the current status of the document?
This new version of the guidelines aims to be easy to understand and go beyond the WCAG documentation by addressing usability and user testing. Although it looks very different from previous versions, its structure incorporates the requirements of earlier versions as well as new accessibility guidelines.
What I am going to describe here is based on the March 2026 Working Draft. This means that the document will still undergo changes before it eventually becomes a W3C Recommendation—and that may take some time. That is why the W3C has added labels throughout virtually the entire document to indicate the status of each area. They are:
- Placeholder: This content is temporary. All of it is expected to be replaced.
- Exploratory: This content has not yet been refined. Details and definitions may be missing.
- Developing: Details have been added, but they still need further development.
- Refining: This content is ready for widespread public review and experimental adoption.
- Mature: The Working Group considers this content ready to be part of the Recommendation.
The review of this document included some translations of terms and an analysis of the guidelines. All translations made in this article are informal and are provided for reference only.
Requirements and levels of conformance
Currently, the document has 12 groups containing 45 guidelines. Each guideline contains Essential Requirements (core requirements) and Supplementary Requirements (supplemental requirements), defined as follows:
Essential requirements: Requirements that must be met to achieve conformance. They include requirements that ensure that:
- content is detectable by user agents and assistive technologies (AT);
- content is conveyed through multiple senses and can be used through multiple input modalities;
- the content does not cause immediate physical harm; and
- the necessary support is available, such as captions, text alternatives, and expanded forms of abbreviations.
Supplementary requirements: Requirements that complement the essential set. They include:
- quality checks;
- stricter or higher levels than those of a comparable essential requirement;
- requirements that are currently more difficult or expensive to implement; and
- requirements that may apply in certain situations.
This means we will no longer have the A, AA, and AAA conformance levels. They have been replaced by Bronze, Silver, and Gold classifications based on conformance with the functional needs of users.
- Bronze: Minimum level. Must comply with all essential requirements plus some supplementary requirements.
- Silver: Complies with all essential requirements plus a larger number of supplementary requirements than the Bronze level.
- Gold: Complies with all essential requirements plus an even larger number of supplementary requirements than the Silver level.
Guidelines
Each guideline contained in a group has a title, number, description, and a list of requirements. All of them have appropriate labels according to their maturity level in the document.
Each requirement has an expandable section containing the procedures for testing the requirement and the expected results, such as in the following example:
2.1 Images and media — In development
Guideline 2.1.1 — Alternatives to images
Users have equivalent alternatives to images.Essential Requirement: Detectable Images — Under Development
Non-decorative images are detectable.Applies when
- the content includes non-decorative images.
Tests
This section is non-normative.Procedure
For each non-decorative image:
- Check the code to determine whether it has been marked in a way that makes it detectable; or
- For technologies where the code cannot be verified, use a screen reader to test whether the image is detectable.
Expected results
- Condition #1 or #2 is true.
Each requirement has a link to a section of the repository on GitHub containing the discussion and development of the requirement.
The entire document cannot be explained here, but I think it is worth providing a brief summary of each group of guidelines, highlighting some of the newest and most interesting ones.
2.1 Images and media
A group of guidelines for audiovisual content, such as images, video, and audio.
2.1.1 — Alternatives for images
This guideline focuses on image accessibility, such as ensuring that non-decorative images are detectable by users or assistive technologies and that decorative images are hidden. It also addresses alternatives to images, such as text equivalents.
2.1.2 — Alternatives for media
In addition to what we already know as transcripts and available alternative media, requirements such as speaker identification, identification of the speaker’s language, and selecting an accessible video player are also present.
2.1.3 — Alternatives for non-textual content
There is currently only one requirement related to ensuring that non-textual content has an equivalent text alternative.
2.1.4 — Captions
In addition to the requirements already present in WCAG 2.2, requirements for captions in immersive environments and guidelines for caption controls have been added.
2.1.5 — Audio descriptions
In addition to the existing requirements, a new requirement for audio descriptions has been added: the possibility of adjusting the audio description language when it is available.
2.1.6 — Figure captions
There are no requirements yet.
2.1.7 — Single-sense
A new guideline stating that content should not depend solely on a user’s single sense. It groups requirements related to hue, contrast, visual depth, and spatial audio.
2.2 Text and drafting
A group of guidelines for the publication of text content.
2.2.1 — Text appearance
This guideline groups adjustments and customization options for text, such as allowing users to increase font size and change colors, as well as making these adjustments reusable.
2.2.2 — Text-to-speech
It ensures that text is accessible to users, such as allowing text and language to be discoverable. A new requirement related to numeric metadata ensures that numerical information is presented in a way that is accessible to users.
2.2.3 — Clear language
Guidelines for writing in plain language. They include abbreviations, explanations of non-literal language, and avoiding unnecessary words.
2.3 Interactive components
This group addresses specific guidelines for interaction components, such as keyboard and pointer input.
2.3.1 — Keyboard focus appearance
Guidance regarding the visual perception of keyboard focus, such as focus size and contrast.
2.3.2 — Pointer focus appearance
In addition to keyboard focus, pointer focus should be noticeable, especially when it involves activating a component.
2.3.3 — Browsing by content
Users must be able to navigate content, so the order of focus must be appropriate.
2.3.4 — Expected behavior
The behavior of components must be predictable for users, offering consistent interactions and conventional patterns.
2.3.5 — Information from controls
Controls for interactive components must be perceptible to users, with sufficient contrast and clearly defined and related names and labels.
2.4 Input / operation
Guidance for making user data input, such as form fields, accessible and making interfaces easier to operate.
2.4.1 — Input via keyboard interface
This brings together existing keyboard accessibility guidelines and adds others, such as documenting customized keys, avoiding keyboard conflicts, ensuring keyboard navigation even in responsive layouts, and controlling focus.
2.4.2 — Physical or cognitive effort when using the keyboard
This guideline aims to reduce the effort required when navigating by keyboard. It includes guidance on describing navigation keys, avoiding repetitive links, and ensuring that the required effort is compatible with the interface.
2.4.3 — Input by pointer
Guidance for accessible use of pointers, such as a mouse or touchscreen. It contains pointer-control guidelines, such as allowing cancellation, and adds requirements related to avoiding actions that require specific pointer pressure or speed.
2.4.4 — Input by speech and voice
A new guideline for voice input controls. It advises that interfaces should not rely solely on voice controls and should provide a text alternative for communication. This is particularly important as we increasingly use voice-controlled personal assistants that often respond through audio.
2.4.5 — Input operation
Offers options for data entry, such as filling out form fields and interacting with the interface. There are guidelines on focus, mouse hovering, and gestures, as well as new requirements, such as avoiding features that depend exclusively on body movements or eye positioning.
2.4.6 — Authentication
Provides guidance to ensure that applications do not rely exclusively on biometrics or voice identification for user authentication.
2.5 Error handling
Guidance to facilitate users’ ability to perceive and correct errors.
2.5.1 — Fix errors
Various guidelines on how to help users correct errors. They include guidance on error reporting, suggestions, alternative ways to indicate errors, persistent messages, and more.
2.5.2 — Prevent errors
Guidelines to help prevent users from making mistakes, including requirements for error prevention, identifying submission status, data validation, and reviewing information before submitting a form.
2.6 Animation and motion
Requirements to prevent moving content from causing discomfort to users or interfering with their ability to use the interface.
2.6.1 — Avoid physical harm
In addition to the guidelines from previous versions regarding blinking content, there are guidelines on haptic stimulation, audio adjustments, and reviewing the type of content. The focus is not limited to blinking content; violent content is also addressed.
2.7 Layout
Specific guidance for developing accessible, semantically structured layouts that work with assistive technologies.
2.7.1 — Recognizable layouts
Guidance to ensure that layouts are accessible and follow conventional accessible patterns, or that their accessibility has been reviewed.
2.7.2 — User guidance
Groups requirements that help users understand where they are within a page or application. These include guidelines on page titles and new requirements, such as listing all the steps of a multi-step action and providing the ability to return to the beginning of a process.
2.7.3 — Structure
Ensures that the structure allows users to navigate and understand the content. This includes guidelines on element relationships, content blocks, headings, and programmatically defined sections.
2.7.4 — No obstruction
Guidance for content that appears on top of and obscures other content, allowing users to uncover or access the content that is being covered.
2.8 Consistency between views
Guidance for maintaining visual, structural, and navigational consistency.
2.8.1 — Consistency
Groups guidance to ensure structural and navigational consistency, reducing users’ cognitive load when navigating multiple pages or processes.
2.9 Process and completion of tasks
Guidance to facilitate the process and completion of tasks by users.
2.9.1 — Avoid exclusionary cognitive tasks
Certain tasks can be difficult because of cognitive load, such as memorizing information. Therefore, providing automated inputs and alternatives for cognitive tasks is important.
2.9.2 — Adequate time
Groups guidelines related to time limits, such as giving users enough time to perform tasks or avoiding unnecessary time limits.
2.9.3 — Avoiding mistakes
These guidelines are related to usability testing conducted to mitigate user errors when using an application.
2.9.4 — Retain information
In multi-step forms, users should be able to go back to previous steps and have previously entered or selected data preserved. This also includes allowing users to save their progress.
2.9.5 — Complete tasks
Guidance to facilitate task completion, such as clearly indicating mandatory information before the task begins and providing available process instructions.
2.9.6 — Unnecessary steps
Review multi-step processes to identify and avoid unnecessary steps.
2.10 Policy and protection
New guidance to protect users while browsing and using a web application.
2.10.1 — Risk
The risks and consequences of choices made when using an application must be described before the user completes the action, such as when signing a document.
2.10.2 — Algorithms
There are also requirements addressing algorithmic decisions when they may cause problems for users with disabilities.
2.11 Help and feedback
Guidance for providing help to users while they are using an application.
2.11.1 — Help available
In addition to existing guidance on help, this document also adds explanations for disabled buttons and a review of the application’s decision-making processes.
2.11.2 — Feedback
Provide users with a feedback mechanism.
2.12 User control
Ensures that users can control the application interface and its components, including when using assistive technologies.
2.12.1 — Control of assistive technology
Allow access to and control of the application through assistive technologies, including the possibility of adjusting settings and notifications.
2.12.2 — Text control
There are no text-control requirements yet.
2.12.3 — Adjustable viewing area
These are guidelines from the previous version, such as not blocking device orientation, allowing text reflow, and adapting the layout.
2.12.4 — Media control
Specific guidance to allow users to control media and alternative media, such as adjusting audio and searching for alternative media.
2.12.5 — Content changes
Guidance for informing users about content that has changed, such as changes in content, focus, or even user-agent notifications.
Conclusion
Although the document has evolved significantly, there is still no expected date for it to become a W3C Recommendation. Because it is still a Working Draft, many things can still change, be added, or be removed from the document.
What catches my attention about this document is that the technical aspects are very well covered, building on previous WCAG documentation. The document also addresses important current issues, such as algorithms and haptic interfaces. Another notable new feature is the greater emphasis on usability testing to make applications better for everyone.
I also found the organization of the document much better, with a focus on users’ functional needs. This is something that has already been introduced in the ABNT NBR 17225 standard for web accessibility.
Even though there is no forecast for these guidelines to become a W3C Recommendation, it is important to be familiar with these good practices, most of which can already be incorporated into our web applications. Broadening the scope of accessibility is good for everyone.
