From 58110ff65bfbda13af4aa2e8adbec15ce7f06a65 Mon Sep 17 00:00:00 2001 From: w3cgruntbot <87540780+w3cgruntbot@users.noreply.github.com> Date: Thu, 19 Dec 2024 19:39:23 +0000 Subject: [PATCH] :robot: Deploy to GitHub Pages: 9383b93391f44964394166c30df2cb42bde554e0 from branch refs/heads/WCAG-2.1 --- guidelines/guidelines.css | 14 +- guidelines/index.html | 4708 +++++++++++++++++++--------- guidelines/relative-luminance.html | 362 +++ 3 files changed, 3549 insertions(+), 1535 deletions(-) create mode 100644 guidelines/relative-luminance.html diff --git a/guidelines/guidelines.css b/guidelines/guidelines.css index f8ede25671..ef3be40bf0 100644 --- a/guidelines/guidelines.css +++ b/guidelines/guidelines.css @@ -34,11 +34,6 @@ dd.new, dd.proposed, dd.changed { display: block; width: 25%; hyphens: none; - padding: 1em; - display: flex; - flex-direction: column; - gap: .5em; - margin-left: 2em; } .sc dt { display: list-item; @@ -55,7 +50,8 @@ dd.new, dd.proposed, dd.changed { div.note-title, div.ednote-title { color: #008400 } -a.internalDFN[title]:hover, .internalDFN[title]:active, a.internalDFN[title]:focus { - cursor: help; -} -span.screenreader {position: absolute; left: -10000px} \ No newline at end of file +/* make links in W3C masthead bold, since we can't make them underline */ +span.screenreader {position: absolute; left: -10000px} +.head p:not(.copyright) > a, .head > a:first-child { + font-weight: bold; +} \ No newline at end of file diff --git a/guidelines/index.html b/guidelines/index.html index 06007cc6e5..9d3e500bf5 100644 --- a/guidelines/index.html +++ b/guidelines/index.html @@ -1,305 +1,113 @@ -
+ + -+ Copyright + © + 2020-2024 + World Wide Web Consortium. + W3C® + liability, + trademark and + document use rules apply. +
+Web Content Accessibility Guidelines (WCAG) 2.1 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content more accessible to a wider range of people with disabilities, including accommodations for blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and combinations of these, and some accommodation for learning disabilities and cognitive limitations; but will not address every user need for people with these disabilities. These guidelines address accessibility of web content on desktops, laptops, tablets, and mobile devices. Following these guidelines will also often make Web content more usable to users in general.
+WCAG 2.1 success criteria are written as testable statements that are not technology-specific. Guidance about satisfying the success criteria in specific technologies, as well as general information about interpreting the success criteria, is provided in separate documents. See Web Content Accessibility Guidelines (WCAG) Overview for an introduction and links to WCAG technical and educational material.
+WCAG 2.1 extends Web Content Accessibility Guidelines 2.0 [WCAG20], which was published as a W3C Recommendation December 2008. Content that conforms to WCAG 2.1 also conforms to WCAG 2.0. The WG intends that for policies requiring conformance to WCAG 2.0, WCAG 2.1 can provide an alternate means of conformance. The publication of WCAG 2.1 does not deprecate or supersede WCAG 2.0. While WCAG 2.0 remains a W3C Recommendation, the W3C advises the use of WCAG 2.1 to maximize future applicability of accessibility efforts. The W3C also encourages use of the most current version of WCAG when developing or updating Web accessibility policies.
+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 a Recommendation of WCAG 2.1 by the Accessibility Guidelines Working Group. This incorporates errata and are described in the change log. At some point additional changes might be incorporated into an Edited or Amended Recommendation.
+To comment, file an issue in the W3C WCAG GitHub repository. Although the proposed Success Criteria in this document reference issues tracking discussion, 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).
++ This document was published by the Accessibility Guidelines Working Group as + an Editor's Draft. +
Publication as an Editor's Draft does not + imply endorsement by W3C and its Members.
+ This is a draft document and may be updated, replaced or obsoleted by other + documents at any time. It is inappropriate to cite this document as other + than work in progress. -
+ This document was produced by a group + operating under the + W3C Patent + Policy. + -
- Copyright © - 2017-2018 - - W3C® - (MIT, - ERCIM, - Keio, Beihang). + 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. - W3C liability, - trademark and - document use - rules apply. -
-Web Content Accessibility Guidelines (WCAG) 2.1 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content more accessible to a wider range of people with disabilities, including accommodations for blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and combinations of these, and some accommodation for learning disabilities and cognitive limitations; but will not address every user need for people with these disabilities. These guidelines address accessibility of web content on desktops, laptops, tablets, and mobile devices. Following these guidelines will also often make Web content more usable to users in general.
-WCAG 2.1 success criteria are written as testable statements that are not technology-specific. Guidance about satisfying the success criteria in specific technologies, as well as general information about interpreting the success criteria, is provided in separate documents. See Web Content Accessibility Guidelines (WCAG) Overview for an introduction and links to WCAG technical and educational material.
-WCAG 2.1 extends Web Content Accessibility Guidelines 2.0 [WCAG20], which was published as a W3C Recommendation December 2008. Content that conforms to WCAG 2.1 also conforms to WCAG 2.0. The WG intends that for policies requiring conformance to WCAG 2.0, WCAG 2.1 can provide an alternate means of conformance. The publication of WCAG 2.1 does not deprecate or supersede WCAG 2.0. While WCAG 2.0 remains a W3C Recommendation, the W3C advises the use of WCAG 2.1 to maximize future applicability of accessibility efforts. The W3C also encourages use of the most current version of WCAG when developing or updating Web accessibility policies.
-- This section describes the status of this document at the time of its publication. Other documents may supersede this document. 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 Editors' Draft of Web Content Accessibility Guidelines (WCAG) 2.1. WCAG 2.1 is a W3C Recommendation. This draft incorporates errata and are described in the change log. At some point these changes might be incorporated into a Edited or Amended Recommendation.
To comment, file an issue in the W3C WCAG GitHub repository. Although the proposed Success Criteria in this document reference issues tracking discussion, 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).
- This document was published by the Accessibility Guidelines Working Group as an Editor's Draft. - -
- - Comments regarding this document are welcome. - Please send them to - public-agwg-comments@w3.org - (archives). - -
- Publication as an Editor's Draft does not imply endorsement by the W3C - Membership. 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 1 February 2018 W3C Process Document. -
This section is non-normative.
-+ This document is governed by the + 03 November 2023 W3C Process Document. +
This section is non-normative.
+ +Web Content Accessibility Guidelines (WCAG) 2.1 defines how to make Web content more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees, and combinations of disability. These guidelines also make Web content more usable by older individuals with changing abilities due to aging and often improve usability for users in general.
-WCAG 2.1 is developed through the W3C process in cooperation with individuals and organizations around the world, with a goal of providing a shared standard for Web content accessibility that meets the needs of individuals, organizations, and governments internationally. WCAG 2.1 builds on WCAG 2.0 [WCAG20], which in turn built on WCAG 1.0 [WAI-WEBCONTENT] and is designed to apply broadly to different Web technologies now and in the future, and to be testable with a combination of automated testing and human evaluation. For an introduction to WCAG, see the Web Content Accessibility Guidelines (WCAG) Overview.
+WCAG 2.1 is developed through the W3C process in cooperation with individuals and organizations around the world, with a goal of providing a shared standard for Web content accessibility that meets the needs of individuals, organizations, and governments internationally. WCAG 2.1 builds on WCAG 2.0 [WCAG20], which in turn built on WCAG 1.0 [WAI-WEBCONTENT] and is designed to apply broadly to different Web technologies now and in the future, and to be testable with a combination of automated testing and human evaluation. For an introduction to WCAG, see the Web Content Accessibility Guidelines (WCAG) Overview.
-Significant challenges were encountered in defining additional criteria to address cognitive, language, and learning disabilities, including a short timeline for development as well as challenges in reaching consensus on testability, implementability, and international considerations of proposals. Work will carry on in this area in future versions of WCAG. We encourage authors to refer to our supplemental guidance on improving inclusion for people with disabilities, including learning and cognitive disabilities, people with low-vision, and more.
+Significant challenges were encountered in defining additional criteria to address cognitive, language, and learning disabilities, including a short timeline for development as well as challenges in reaching consensus on testability, implementability, and international considerations of proposals. Work will carry on in this area in future versions of WCAG. We encourage authors to refer to our supplemental guidance on improving inclusion for people with disabilities, including learning and cognitive disabilities, people with low-vision, and more.
Web accessibility depends not only on accessible content but also on accessible Web browsers and other user agents. Authoring tools also have an important role in Web accessibility. For an overview of how these components of Web development and interaction work together, see:
Where this document refers to WCAG 2
it is intended to mean any and all versions of WCAG that start with 2.
The individuals and organizations that use WCAG vary widely and include Web designers and developers, policy makers, purchasing agents, teachers, and students. In order to meet the varying needs of this audience, several layers of guidance are provided including overall principles, general guidelines, testable success criteria and a rich collection of sufficient techniques, advisory techniques, and documented common failures with examples, resource links and code.
All of these layers of guidance (principles, guidelines, success criteria, and sufficient and advisory techniques) work together to provide guidance on how to make content more accessible. Authors are encouraged to view and apply all layers that they are able to, including the advisory techniques, in order to best address the needs of the widest possible range of users.
Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas. Authors are encouraged to consider the full range of techniques, including the advisory techniques, as well as to seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community. Metadata may assist users in finding content most suitable for their needs.
The WCAG 2.1 document is designed to meet the needs of those who need a stable, referenceable technical standard. Other documents, called supporting documents, are based on the WCAG 2.1 document and address other important purposes, including the ability to be updated to describe how WCAG would be applied with new technologies. Supporting documents include:
The WCAG Documents - A diagram and description of how the technical documents are related and linked.
See Web Content Accessibility Guidelines (WCAG) Overview for a description of the WCAG 2.1 supporting material, including education resources related to WCAG 2. Additional resources covering topics such as the business case for Web accessibility, planning implementation to improve the accessibility of Web sites, and accessibility policies are listed in WAI Resources.
+See Web Content Accessibility Guidelines (WCAG) Overview for a description of the WCAG 2.1 supporting material, including education resources related to WCAG 2. Additional resources covering topics such as the business case for Web accessibility, planning implementation to improve the accessibility of Web sites, and accessibility policies are listed in WAI Resources.
WCAG 2.1 meets a set of requirements for WCAG 2.1 which, in turn, inherit requirements from WCAG 2.0. Requirements structure the overall framework of guidelines and ensure backwards compatibility. The Working Group also used a less formal set of acceptance criteria for success criteria, to help ensure success criteria are similar in style and quality to those in WCAG 2.0. These requirements constrained what could be included in WCAG 2.1. This constraint was important to preserve its nature as a dot-release of WCAG 2.
+WCAG 2.1 meets a set of requirements for WCAG 2.1 which, in turn, inherit requirements from WCAG 2.0. Requirements structure the overall framework of guidelines and ensure backwards compatibility. The Working Group also used a less formal set of acceptance criteria for success criteria, to help ensure success criteria are similar in style and quality to those in WCAG 2.0. These requirements constrained what could be included in WCAG 2.1. This constraint was important to preserve its nature as a dot-release of WCAG 2.
WCAG 2.1 was initiated with the goal to improve accessibility guidance for three major groups: users with cognitive or learning disabilities, users with low vision, and users with disabilities on mobile devices. Many ways to meet these needs were proposed and evaluated, and a set of these were refined by the Working Group. Structural requirements inherited from WCAG 2.0, clarity and impact of proposals, and timeline led to the final set of success criteria included in this version. The Working Group considers that WCAG 2.1 incrementally advances web content accessibility guidance for all these areas, but underscores that not all user needs are met by these guidelines.
WCAG 2.1 builds on and is backwards compatible with WCAG 2.0, meaning web pages that conform to WCAG 2.1 also conform to WCAG 2.0. Authors that are required by policy to conform with WCAG 2.0 will be able to update content to WCAG 2.1 without losing conformance with WCAG 2.0. Authors following both sets of guidelines should be aware of the following differences:
-WCAG 2.1 extends WCAG 2.0 by adding new success criteria, definitions to support them, guidelines to organize the additions, and a couple additions to the conformance section. This additive approach helps to make it clear that sites which conform to WCAG 2.1 also conform to WCAG 2.0, thereby meeting conformance obligations that are specific to WCAG 2.0. The Accessibility Guidelines Working Group recommends that sites adopt WCAG 2.1 as their new conformance target, even if formal obligations mention WCAG 2.0, to provide improved accessibility and to anticipate future policy changes.
The following Success Criteria are new in WCAG 2.1:
Many of these success criteria reference new terms that have also been added to the glossary and form part of the normative requirements of the success criteria.
+The new success criteria may reference new terms that have also been added to the glossary and form part of the normative requirements of the success criteria.
In the Conformance section, a third note about page variants has been added to Full Pages, and an option for machine-readable metadata added to Optional Components of a Conformance Claim.
In order to avoid confusion for implementers for whom backwards compatibility to WCAG 2.0 is important, new success criteria in WCAG 2.1 have been appended to the end of the set of success criteria within their guideline. This avoids the need to change the section number of success criteria from WCAG 2.0, which would be caused by inserting new success criteria between existing success criteria in the guideline, but it means success criteria in each guideline are no longer grouped by conformance level. The order of success criteria within each guideline does not imply information about conformance level; only the conformance level indicator (A / AA / AAA) on the success criterion itself indicates this. The WCAG 2.1 Quick Reference provides ways to view success criteria grouped by conformance level, along with many other filter and sort options.
WCAG 2.1 uses the same conformance model as WCAG 2.0 with a couple additions, which is described in the Conformance section. It is intended that sites that conform to WCAG 2.1 also conform to WCAG 2.0, which means they meet the requirements of any policies that reference WCAG 2.0, while also better meeting the needs of users on the current Web.
In parallel with WCAG 2.1, the Accessibility Guidelines Working Group is developing another major version of accessibility guidelines. The result of this work is expected to be a more substantial restructuring of web accessibility guidance than would be realistic for dot-releases of WCAG 2. The work follows a research-focused, user-centered design methodology to produce the most effective and flexible outcome, including the roles of content authoring, user agent support, and authoring tool support. This is a multi-year effort, so WCAG 2.1 is needed as an interim measure to provide updated web accessibility guidance to reflect changes on the web since the publication of WCAG 2.0. The Working Group might also develop additional interim versions, continuing with WCAG 2.2, on a similar short timeline to provide additional support while the major version is completed.
Information and user interface components must be presentable to users in ways they can perceive.
-Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
+Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
-(Level A)
+(Level A)
-All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. +
All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.
If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2 for additional requirements for controls and content that accepts user input.) +
If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2 for additional requirements for controls and content that accepts user input.)
@@ -673,7 +447,7 @@If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text +
If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
@@ -683,13 +457,13 @@If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text +
If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
-If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented - in a way that it can be ignored by assistive technology. +
If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented + in a way that it can be ignored by assistive technology.
Provide alternatives for time-based media.
+Provide alternatives for time-based media.
-(Level A)
-For prerecorded - audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled as such: +
(Level A)
+ +For prerecorded + audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled as such:
An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only content. +
An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only content.