Explainer for W3C Accessibility Guidelines (WCAG) 3.0

W3C Group Draft Note

More details about this document
This version:
https://www.w3.org/TR/2024/DNOTE-wcag-3.0-explainer-20241212/
Latest published version:
https://www.w3.org/TR/wcag-3.0-explainer/
Latest editor's draft:
https://w3c.github.io/wcag3/explainer/
History:
https://www.w3.org/standards/history/wcag-3.0-explainer/
Commit history
Editors:
(Library of Congress)
(Oracle)
(Nomensa)
(W3C)
(TetraLogical)
(Intel Corporation)
Feedback:
GitHub w3c/wcag3 (pull requests, new issue, open issues)

Copyright © 2021-2024 World Wide Web Consortium. W3C® liability, trademark and document use rules apply.

Abstract

The Explainer for WCAG 3.0 accompanies the draft of W3C Accessibility Guidelines (WCAG) 3.0. It provides an overview of the history and goals of WCAG 3.0. This document also describes the current thinking on the structure of the guidelines and the conformance model. The guidelines, conformance model, and related work are still evolving.

Information on the current schedule is included below with a link to a more detailed timeline.

See WCAG 3 Introduction for more details about this work 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 updated draft of the WCAG 3.0 Explainer. It is informative, not normative, and is not expected to become a W3C Recommendation. It provides background on W3C Accessibility Guidelines (WCAG) 3.0.

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 public-agwg-comments@w3.org (comment archive). In-progress updates to the guidelines can be viewed in the public editors’ draft.

This document was published by the Accessibility Guidelines Working Group as a Group Draft Note using the Note track.

Group Draft Notes are not endorsed by W3C nor 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.

The W3C Patent Policy does not carry any licensing requirements or commitments on this document.

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

1. Introduction

W3C Accessibility Guidelines (WCAG) 3.0 is a successor to Web Content Accessibility Guidelines 2.2 [WCAG22] and previous versions. It does not deprecate WCAG 2. It may incorporate some content from User Agent Accessibility Guidelines 2.0 [UAAG20] and Authoring Tool Accessibility Guidelines 2.0 [ATAG20] where it assists authors in meeting guidelines. These versions provided a model that kept them relevant for over 10 years. Changing technology and changing needs of people with disabilities require a new model to address content accessibility more comprehensively.

This Explainer includes:

Editor's note

The structure, guidelines, and conformance model are still in draft. The Accessibility Guidelines Working Group welcomes public comments on the proposed approach.

2. Goals

The goal of WCAG is to provide information that can be used to improve the accessibility of products on a variety of platforms. WCAG 3.0 will use a model that allows it to:

Additional goals for WCAG 3.0 are written in Requirements for WCAG 3.0. These are based on the Silver research, the results from the Silver Design Sprint, and input from the Accessibility Guidelines Working Group, the Silver Task Force, and the Silver Community Group.

2.1 Goals for Inclusion

The creation process for the WCAG 3.0 guidelines should:

Editor's note

W3C strives to be as inclusive as possible, and has actively sought participation and input from a broad range of stakeholder groups. We recognize, however, that there is always room for improvement in practices to support inclusion and representation. As you evaluate this document, please consider whether there are ways the Working Group can better support your review, feedback, or inclusion within the process of creating this standard. We welcome feedback on this question as part of your comments.

2.2 Out of Scope

Several items are out of scope for WCAG 3.0:

3. WCAG 3.0 Background and Development History

WCAG 3.0 originally had a project name of "Silver", so the original groups working on it and much of the early design work carries that project name. The Silver Task Force of the Accessibility Guidelines Working Group (AG) and the W3C Silver Community group partnered to produce the needs, requirements, and structure for the new accessibility guidance. They worked on Silver from 2017-2023. During that time they:

  1. Developed a list of Web Content Accessibility Guidelines stakeholders and their job stories
  2. Researched needs for a new major version of the Web Content Accessibility Guidelines; (Silver Research Project)
  3. Developed problem statements and opportunities to improve accessibility guidance;
  4. Received input from industry leaders for directions to proceed to address the problem statements; The full Final Report of the Silver Design Sprint is incorrectly labeled as a draft. It contains all the information on the Design Sprint.
  5. Drafted Requirements for WCAG3;
  6. Created and tested prototypes for aspects of the project; and
  7. Created a First Public Working Draft of WCAG3 and three updated Working Drafts.

4. Current Process for Creating WCAG 3.0

The AG uses an iterative approach to creating WCAG 3.0. Each piece of content will evolve over time, increasing in maturity. As a result, the document is a work-in-progress.

Because different parts of the document have different maturity levels, each normative section includes a status that indicates:

The status indicators, from least to most mature, are:

The working group aims to publish two new drafts each year. Each draft will include targeted questions for the public to consider. Responses will help advance the work. Content will evolve and there may be changes to layout and style that are not yet reflected in all parts of the present release and will be reflected in future releases.

5. WCAG 3.0 StructureExploratory

WCAG 3.0 includes both normative and informative guidance. This guidance is organized into:

Details on each are below.

By default, guidelines are organized by what is tested. WCAG 3.0 will provide a version, similar to the existing QuickRef, that incorporates tags to allow readers to reorganize and filter the content. For example, content will be tagged Perceivable, Operable, Understandable, and Robust so that readers can view WCAG 3.0 criteria in the same structure as WCAG 2.

5.1 Guidelines

Guidelines are written as plain language, user-centered outcomes statements.

Guidelines include high-level, plain-language information for managers, policy makers, individuals who are new to accessibility, and other individuals who need to understand the concepts but not the technical details. They provide an easy-to-understand way of organizing and presenting the outcomes so that anyone can learn about and understand the concepts.

Guidelines are normative.

Guidelines are technology-agnostic and address functional needs on specific topics, such as contrast, forms, readability, and more. Foundational requirements, supplemental requirements, and assertions that relate to a Guideline are listed together to encourage adoption of higher levels of accessibility.

5.2 Requirements and Methods

Each Guideline contains multiple Requirements:

Requirements reduce or eliminate barriers that people with disabilities experience. Requirements are designed for use by developers, testers, and other technical specialists.

Requirements are normative.

Each set of Foundational Requirements are organized into a decision tree to show the relationship between requirements and to allow for accessibility-supported solutions in the future.

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

Editor's note

The AG has discussed also including "Recommendations" at the same level as Supplemental Requirements. Recommendations would be things which could help improve accessibility but may not be objectively testable. They could contribute to levels of conformance above Foundational.

5.3 Assertions

An Assertion is a formal claim of fact, attributed to a person or organization. In WCAG 3.0, 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.

5.3.1 Using Assertions

Assertions may supplement Requirements to meet a Guideline. Not all Guidelines include Assertions. Guidelines that include Assertions, list the Assertions with the Requirements. Organizations can make an assertion that they followed a procedure as part of a conformance claim. Assertions can be made in addition to foundational requirements but do not replace foundational requirements.

Editor's note

The working group will consider whether assertions may be used to meet guidelines when requirements are not available.

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

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
  • Testing with assistive technology.

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.

5.3.2 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 requirement(s) or guideline(s) supported by the assertion.
Editor's note

AG will continue developing requirements and methods. Each publication will include additional examples, and/or more mature examples for public comment.

AG's next steps include:

  • Define criteria for which requirements are foundational and which are supplemental.
  • Develop mature examples of 2 guidelines with associated requirements, methods, tests, and How to documentation.
  • Mature all guidelines to the developing stage.
  • Further explore how conditional requirements and alternate ways to measure might be used to meet Guidelines.

AG will also continue to explore the use of assertions and welcomes feedback on the following questions:

  • 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.0 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, assertions are collocated with requirements. Would moving assertions to a different location be more effective?
  • AG is considering what will qualify as a procedure in WCAG 3.0. A procedure may be limited to guidance:
    • approved by AG 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.

6. TestingExploratory

6.1 Types of tests

WCAG 3.0 includes two types of tests which are evaluated:

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. For example, different human languages have different readability metrics.

6.2 Example Tests

Tests may be objective or subjective. For example, from WCAG 2:

Both these tests are objectively verifiable. They are not subject to variation of results between different testers.

Alternatively, again from WCAG 2:

These tests include a subjective determination of whether they are adequately met.

6.3 Scope

Testing uses items, views, task flow, and the product to define the scope of what is being tested.

Items are the smallest testable unit. 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.

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

Task flows are 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.

Examples of a task flow include:

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

6.4 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 quantifiable and qualitative tests can be conditional.

Example conditions include:

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

7. Conformance ApproachExploratory

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. Drafts will include maturity models for public review and comment.

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 provisions (modules).

7.1 Additional Concepts

Key concepts AG has and previously considered and continues to explore the following:

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

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.

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

8. User-generated contentPlaceholder

Summary

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.

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

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.0 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.0 guidelines and outcomes. Not all WCAG 3.0 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.

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

9. Schedule

AG is currently chartered through November 2025. The schedule through that time period is maintained at WCAG 3.0 Timeline.

AG will continue to iterate within a single normative document with informative supporting documentation. After exploring other options such as breaking the content into modules, the group determined that the fastest way forward at this time is to continue creating a single document with varying levels of maturity. We will revisit whether mature content can be published as informative modules as part of the next charter period, when content is more mature.

A final schedule will be delivered as part of this charter period. WCAG 3.0 will not be published until it covers at least as much as WCAG 2.2.

10. GlossaryExploratory

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.

Assistive technology

Software (or hardware), separate from the authoring tool, that provides functionality to meet the requirements of people with disabilities.

Authoring Tool

Any web-based or non-web-based application(s) that can be used by authors (alone or collaboratively) to create or modify web content for use by other people (other authors or end users).

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.

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

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.

Documenting assertions
Editor's note

To be defined.

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.

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.

Programmatically
Editor's note

To be defined.

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.

Significant change
Editor's note

To be defined.

Technology agnostic
Editor's note

To be defined.

Test

Mechanism to evaluate implementation of a method.

User activity
Editor's note

To be defined.

User agent

Any software that retrieves, renders and facilitates end user interaction with web content (e.g. web browsers, browser plug-ins, media players).

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.

A. Acknowledgements

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

A.1 Contributors to the development of this document

A.2 Prior Contributors

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

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

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

B. References

B.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/
[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/
[WCAG3]
W3C Accessibility Guidelines (WCAG) 3.0. World Wide Web Consortium. 28 May 2024. URL: https://www.w3.org/TR/2024/WD-wcag-3.0-20240528/