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.
+
Web Content Accessibility Guidelines (WCAG) 2.2 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.2 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.2 extends Web Content Accessibility Guidelines 2.1 [[!WCAG21]], which was published as a W3C Recommendation June 2018. Content that conforms to WCAG 2.2 also conforms to WCAG 2.0 and WCAG 2.1. The WG intends that for policies requiring conformance to WCAG 2.0 or WCAG 2.1, WCAG 2.2 can provide an alternate means of conformance. The publication of WCAG 2.2 does not deprecate or supersede WCAG 2.0 or WCAG 2.1. While WCAG 2.0 and WCAG 2.1 remain W3C Recommendations, the W3C advises the use of WCAG 2.2 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.
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).
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).
Introduction
Background on WCAG 2
-
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.
+
Web Content Accessibility Guidelines (WCAG) 2.2 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.2 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.2 builds on WCAG 2.0 [[!WCAG20]] and WCAG 2.1 [[!WCAG21]], 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.
@@ -48,81 +48,65 @@
WCAG 2 Layers of Guidance
Guidelines - Under the principles are guidelines. The 13 guidelines provide the basic goals that authors should work toward in order to make content more accessible to users with different disabilities. The guidelines are not testable, but provide the framework and overall objectives to help authors understand the success criteria and better implement the techniques.
-
Success Criteria - For each guideline, testable success criteria are provided to allow WCAG 2.1 to be used where requirements and conformance testing are necessary such as in design specification, purchasing, regulation, and contractual agreements. In order to meet the needs of different groups and different situations, three levels of conformance are defined: A (lowest), AA, and AAA (highest). Additional information on WCAG levels can be found in Understanding Levels of Conformance.
+
Success Criteria - For each guideline, testable success criteria are provided to allow WCAG 2.2 to be used where requirements and conformance testing are necessary such as in design specification, purchasing, regulation, and contractual agreements. In order to meet the needs of different groups and different situations, three levels of conformance are defined: A (lowest), AA, and AAA (highest). Additional information on WCAG levels can be found in Understanding Levels of Conformance.
-
Sufficient and Advisory Techniques - For each of the guidelines and success criteria in the WCAG 2.1 document itself, the working group has also documented a wide variety of techniques. The techniques are informative and fall into two categories: those that are sufficient for meeting the success criteria and those that are advisory. The advisory techniques go beyond what is required by the individual success criteria and allow authors to better address the guidelines. Some advisory techniques address accessibility barriers that are not covered by the testable success criteria. Where common failures are known, these are also documented. See also Sufficient and Advisory Techniques in Understanding WCAG 2.1.
+
Sufficient and Advisory Techniques - For each of the guidelines and success criteria in the WCAG 2.2 document itself, the working group has also documented a wide variety of techniques. The techniques are informative and fall into two categories: those that are sufficient for meeting the success criteria and those that are advisory. The advisory techniques go beyond what is required by the individual success criteria and allow authors to better address the guidelines. Some advisory techniques address accessibility barriers that are not covered by the testable success criteria. Where common failures are known, these are also documented. See also Sufficient and Advisory Techniques in Understanding WCAG 2.2.
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.
-
WCAG 2.1 Supporting Documents
-
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:
+
WCAG 2.2 Supporting Documents
+
The WCAG 2.2 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.2 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:
-
How to Meet WCAG 2.1 - A customizable quick reference to WCAG 2.1 that includes all of the guidelines, success criteria, and techniques for authors to use as they are developing and evaluating Web content. This includes content from WCAG 2.0 and WCAG 2.1 and can be filtered in many ways to help authors focus on relevant content.
+
How to Meet WCAG 2.2 - A customizable quick reference to WCAG 2.2 that includes all of the guidelines, success criteria, and techniques for authors to use as they are developing and evaluating Web content. This includes content from WCAG 2.0 and WCAG 2.2 and can be filtered in many ways to help authors focus on relevant content.
-
Understanding WCAG 2.1 - A guide to understanding and implementing WCAG 2.1. There is a short "Understanding" document for each guideline and success criterion in WCAG 2.1 as well as key topics.
+
Understanding WCAG 2.2 - A guide to understanding and implementing WCAG 2.2. There is a short "Understanding" document for each guideline and success criterion in WCAG 2.2 as well as key topics.
-
Techniques for WCAG 2.1 - A collection of techniques and common failures, each in a separate document that includes a description, examples, code and tests.
+
Techniques for WCAG 2.2 - A collection of techniques and common failures, each in a separate document that includes a description, examples, code and tests.
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.2 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.
-
Requirements for WCAG 2.1
-
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.
+
Requirements for WCAG 2.2
+
WCAG 2.2 meets a set of requirements for WCAG 2.2 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.2. This constraint was important to preserve its nature as a dot-release of WCAG 2.
Comparison with WCAG 2.0
-
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.2 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.2 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.2 builds on and is backwards compatible with WCAG 2.0, meaning web pages that conform to WCAG 2.2 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.2 without losing conformance with WCAG 2.0. Authors following both sets of guidelines should be aware of the following differences:
-
New Features in WCAG 2.1
-
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:
+
New Features in WCAG 2.2
+
WCAG 2.2 extends WCAG 2.0 and WCAG 2.1 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.2 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.2 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.2:
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.
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.
+
Numbering in WCAG 2.2
+
In order to avoid confusion for implementers for whom backwards compatibility to WCAG 2.0 is important, new success criteria in WCAG 2.2 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.2 Quick Reference provides ways to view success criteria grouped by conformance level, along with many other filter and sort options.
-
Conformance to WCAG 2.1
-
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.
+
Conformance to WCAG 2.2
+
WCAG 2.2 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.2 also conform to WCAG 2.0 and WCAG 2.1, which means they meet the requirements of any policies that reference WCAG 2.0 or WCAG 2.1, while also better meeting the needs of users on the current Web.
Later Versions of Accessibility Guidelines
-
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.
+
In parallel with WCAG 2.2, 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.2 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.
@@ -380,18 +364,18 @@
Compatible
Conformance
-
This section lists requirements for conformance to WCAG 2.1. It also gives information about how to make conformance claims, which are optional. Finally, it describes what it means to be accessibility supported, since only accessibility-supported ways of using technologies can be relied upon for conformance. Understanding Conformance includes further explanation of the accessibility-supported concept.
+
This section lists requirements for conformance to WCAG 2.2. It also gives information about how to make conformance claims, which are optional. Finally, it describes what it means to be accessibility supported, since only accessibility-supported ways of using technologies can be relied upon for conformance. Understanding Conformance includes further explanation of the accessibility-supported concept.
Interpreting Normative Requirements
-
The main content of WCAG 2.1 is normative and defines requirements that impact conformance claims. Introductory material, appendices, sections marked as "non-normative", diagrams, examples, and notes are informative (non-normative). Non-normative material provides advisory information to help interpret the guidelines but does not create requirements that impact a conformance claim.
+
The main content of WCAG 2.2 is normative and defines requirements that impact conformance claims. Introductory material, appendices, sections marked as "non-normative", diagrams, examples, and notes are informative (non-normative). Non-normative material provides advisory information to help interpret the guidelines but does not create requirements that impact a conformance claim.
The key words MAY, MUST, MUST NOT, NOT RECOMMENDED, RECOMMENDED, SHOULD, and SHOULD NOT are to be interpreted as described in [[RFC2119]].
Conformance Requirements
-
In order for a Web page to conform to WCAG 2.1, all of the following conformance requirements must be satisfied:
+
In order for a Web page to conform to WCAG 2.2, all of the following conformance requirements must be satisfied:
Conformance Level
@@ -455,10 +439,10 @@
Conformance Claims (Optional)
Required Components of a Conformance Claim
-
Conformance claims are not required. Authors can conform to WCAG 2.1 without making a claim. However, if a conformance claim is made, then the conformance claim must include the following information:
+
Conformance claims are not required. Authors can conform to WCAG 2.2 without making a claim. However, if a conformance claim is made, then the conformance claim must include the following information:
A concise description of the Web pages, such as a list of URIs for which the claim is made, including whether subdomains are included in the claim.
@@ -501,7 +485,7 @@
Statement of Partial Conformance - Third Party Content
OR
-
A "statement of partial conformance" may be made that the page does not conform, but could conform if certain parts were removed. The form of that statement would be, "This page does not conform, but would conform to WCAG 2.1 at level X if the following parts from uncontrolled sources were removed." In addition, the following would also be true of uncontrolled content that is described in the statement of partial conformance:
+
A "statement of partial conformance" may be made that the page does not conform, but could conform if certain parts were removed. The form of that statement would be, "This page does not conform, but would conform to WCAG 2.2 at level X if the following parts from uncontrolled sources were removed." In addition, the following would also be true of uncontrolled content that is described in the statement of partial conformance:
It is not content that is under the author's control.
It is described in a way that users can identify (e.g., they cannot be described as "all parts that we do not control" unless they are clearly marked as such.)
@@ -512,7 +496,7 @@
Statement of Partial Conformance - Third Party Content
Statement of Partial Conformance - Language
-
A "statement of partial conformance due to language" may be made when the page does not conform, but would conform if accessibility support existed for (all of) the language(s) used on the page. The form of that statement would be, "This page does not conform, but would conform to WCAG 2.1 at level X if accessibility support existed for the following language(s):"
+
A "statement of partial conformance due to language" may be made when the page does not conform, but would conform if accessibility support existed for (all of) the language(s) used on the page. The form of that statement would be, "This page does not conform, but would conform to WCAG 2.2 at level X if accessibility support existed for the following language(s):"
@@ -719,8 +703,8 @@
Glossary
Change Log
-
This section shows changes proposed for WCAG 2.1 since its publication as a W3C Recommendation. These changes are also recorded as errata.
diff --git a/guidelines/respec-config.js b/guidelines/respec-config.js
index 0515f9ebc6..cf9d7bb1e1 100644
--- a/guidelines/respec-config.js
+++ b/guidelines/respec-config.js
@@ -15,12 +15,12 @@ var respecConfig = {
diffTool: "http://www.aptest.com/standards/htmldiff/htmldiff.pl",
// the specifications short name, as in https://www.w3.org/TR/short-name/
- shortName: "WCAG21",
+ shortName: "WCAG22",
// if you wish the publication date to be other than today, set this
//publishDate: "2014-12-11",
- copyrightStart: "2017",
+ copyrightStart: "2019",
license: "document",
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
@@ -31,7 +31,7 @@ var respecConfig = {
//previousDiffURI: "https://www.w3.org/TR/2014/REC-wai-aria-20140320/",
// if there a publicly available Editors Draft, this is the link
- edDraftURI: "https://w3c.github.io/wcag/21/guidelines/",
+ edDraftURI: "https://w3c.github.io/wcag/22/guidelines/",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2012-02-21",
@@ -47,14 +47,6 @@ var respecConfig = {
companyURI: "http://www.adobe.com/",
w3cid: 39770
},
- {
- name: "Joshue O Connor",
- url: "http://interaccess.ie/",
- mailto: "josh@interaccess.ie",
- company: "Invited Expert, InterAccess",
- companyURI: "http://interaccess.ie/",
- w3cid: 41218
- },
{
name: "Alastair Campbell",
url: "https://www.nomensa.com/",
@@ -102,6 +94,11 @@ var respecConfig = {
name: "Jason White",
company: "University of Melbourne",
w3cid: 74028
+ },
+ {
+ name: "Joshue O Connor",
+ company: "Invited Expert, InterAccess",
+ w3cid: 41218
}
],
diff --git a/guidelines/sc/21/character-key-shortcuts.html b/guidelines/sc/21/character-key-shortcuts.html
index 4d7a9c76a0..618e647062 100644
--- a/guidelines/sc/21/character-key-shortcuts.html
+++ b/guidelines/sc/21/character-key-shortcuts.html
@@ -14,7 +14,7 @@
Character Key Shortcuts
A mechanism is available to turn the shortcut off;
Remap
-
A mechanism is available to remap the shortcut to use one or more non-printable keyboard characters (e.g. Ctrl, Alt, etc);
+
A mechanism is available to remap the shortcut to include one or more non-printable keyboard keys (e.g., Ctrl, Alt);
Active only on focus
The keyboard shortcut for a user interface component is only active when that component has focus.
Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.
-
Examples where a particular display orientation may be essential are a bank check, a piano application, slides for a projector or television, or virtual reality content where binary display orientation is not applicable.
+
Examples where a particular display orientation may be essential are a bank check, a piano application, slides for a projector or television, or virtual reality content where content is not necessarily restricted to landscape or portrait display orientation.
Except for parts of the content which require two-dimensional layout for usage or meaning.
-
320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom. For web content which are designed to scroll horizontally (e.g. with vertical text), the 256 CSS pixels is equivalent to a starting viewport height of 1024px at 400% zoom.
+
320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom. For web content which is designed to scroll horizontally (e.g., with vertical text), 256 CSS pixels is equivalent to a starting viewport height of 1024px at 400% zoom.
-
Examples of content which require two-dimensional layout are images, maps, diagrams,
+
Examples of content which requires two-dimensional layout are images, maps, diagrams,
video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while
manipulating content.
diff --git a/lib/apache-ant-1.10.6-bin.tar.gz b/lib/apache-ant-1.10.6-bin.tar.gz
new file mode 100644
index 0000000000..ae85aaf09f
Binary files /dev/null and b/lib/apache-ant-1.10.6-bin.tar.gz differ
diff --git a/requirements/22/index.html b/requirements/22/index.html
new file mode 100644
index 0000000000..005cb9d28b
--- /dev/null
+++ b/requirements/22/index.html
@@ -0,0 +1,232 @@
+
+
+
+
+
+ Requirements for Web Content Accessibility Guidelines 2.2
+
+
+
+
+
+
+
+
+
+
+
This document outlines the requirements that the Web Content Accessibility Guidelines Working Group (WCAG WG) has
+ set for the development of Web Content Accessibility Guidelines (WCAG) 2.2. These requirements build on the
+ existing requirements for WCAG 2.0, and are designed to work in harmony with the WCAG 2.0 and WCAG 2.1 standards.
+
+
+
+
+
+
Introduction
+
Web Content Accessibility Guidelines 2.0 (WCAG 2.0) [[WCAG20]]
+ explains how to make Web content accessible to people with disabilities. Since the release of WCAG 2.0 in December
+ 2008 and the release of WCAG 2.1 in June 2018, these standards have been widely adopted and implemented. As a
+ result of feedback from implementers, ongoing changes in technologies, and responding to the need for regular
+ updates in accessibility content standards, the Accessibility Guidelines Working Group (AGWG) is pursuing the
+ development of WCAG 2.2.
+
The underlying goal of WCAG 2.2 requirements are the same as for WCAG 2.0 and WCAG 2.1 – to promote accessibility
+ of Web content. WCAG 2.2 must satisfy additional requirements addressed in this document including:
+
+
Web pages which conform to WCAG 2.2 conform to WCAG 2.1 (which conforms to WCAG 2.0).
+
WCAG 2.2 success criteria continue support additional use-cases.
+
WCAG 2.2 success criteria are in harmony and address the needs of users in multiple domains where possible.
+
+
Utilize the WCAG 2.0 conformance model.
+
Utilize the WCAG 2.0 A/AA/AAA model.
+
+
The Requirements for WCAG 2.0 [[wcag2-req]] provides details used
+ during the development of WCAG 2.0, including key goals related to technology independence, clearly defined
+ conformance requirements, and more which are still relevant and important. As with WCAG 2.0, work on each
+ specifications in the same line (WCAG 2.x) will provide techniques and supporting documentation to assist in
+ implementation efforts, and any criteria modified or introduced by a WCAG 2.x release will need to be verifiable
+ by implementers.
+
WCAG 2.x specifications are expected to offer modifications to existing success criteria as well as
+ offer additional guidelines and success criteria but WCAG 2.x requirements may not weaken what is required
+ generally of web content to be considered conformant to either. The result of this is that when a page conforms to
+ WCAG 2.x it will also conform to to the previous versions.
+
+
In any WCAG 2.x specification - an existing success criteria may change in priority from a lower level to a
+ higher level, but not the other way around. Criteria can be changed or removed so long as accessibility issues caught by the original success criteria remain issues in the updated guidelines.
+
For example:
+
+
A Level A Success Criteria cannot move to Level AA.
+
Existing success criteria may be modified or removed in a WCAG 2.x release, but the resulting change must
+ retain functional backwards compatibility with previous versions. That is, accessibility requirements in WCAG 2.0 will
+ still be covered by WCAG 2.x.
+
An existing success criterion could be removed if accessibility support makes it redundant.
+
An existing success criterion could be removed if the accessibility requirement is covered by other (new or
+ old) success criteria.
+
New WCAG 2.x success criteria should not conflict with each other, allowing authors to address additional
+ requirements for more than one user group.
+
+
Group members working on different success criteria should maintain good communication about work in progress
+ with the main Working Group and across Task Forces to minimize conflicts/duplication of work wherever possible.
+
+
+
+
WCAG 2.2 success criteria continue support for additional use-cases from WCAG 2.1
+
WCAG 2.2 will build on WCAG 2.1 and provide additional criteria to address the accessibility of content for
+ use-cases that were a focus of WCAG 2.1. Improvements in support for users of small or touch-screen devices, as
+ well as for low-vision users and users with cognitive, language, and learning impairments.
+
+
+
Utilize the WCAG 2.0 conformance model.
+
The WCAG 2.0 Requirements document provides details about conformance that needs to be met for WCAG 2.x releases.
+ However WCAG 2.x releases need to provide conformance details that indicate the conformance relationship between
+ them, and existing WCAG 2.0 conformance. WCAG 2.2 must specify that conformance claims indicate that a page
+ conforms to WCAG 2.1 as a base. Future WCAG 2.x specifications must conform to its immediate previous ancestor
+ specification as a base.
+
+
+
Utilize the WCAG 2.0 A/AA/AAA model.
+
WCAG 2.2 will utilize the WCAG 2.0 A/AA/AAA structure. Additional or changed success criteria will specify at
+ what Level those criteria are provided. When a page conforms to WCAG 2.2 at a specific level, that page must
+ conform to WCAG 2.0 and WCAG 2.1 at the same level or higher.
+
It is important to note that changes in WCAG 2.2 to the level for any existing WCAG 2.x success criteria need to
+ be made with awareness of the implementability and testability requirements for the new level. For WCAG 2.x
+ releases to ensure backwards compatibility level changes must be clear for the immediate previous ancestor
+ specification as a base.
+
For example, a success criteria may currently be at Level AAA as a result of very limited testability, and moving
+ that success criteria to Level AA in WCAG 2.2 or a WCAG 2.x would require greater testability. In order to
+ successfully make this transition there must be evidence that testability is more robust.
+
+
+
Example
+
Some new success criteria and guidelines in WCAG 2.2 are created that effectively make some changes (strengthen)
+ previous WCAG 2.0 conformance requirements, and a page that conformed to WCAG 2.0 is tested against WCAG 2.2:
+
+
One new WCAG 2.2 success criteria modifies (strengthens) an existing AA success criteria (e.g. 1.4.3 Color
+ Contrast [minimum]) and in effect, moves it to level A.
+
Adds a new guideline and two other new success criteria - 5.1 at level A and 5.2 at level AA.
+
+
A web page that previously conforms to WCAG 2.0 AA is reviewed against the new WCAG 2.2 specification. In the
+ review, it is determined that the page still meets 1.4.3, which is now a level A criteria, and the page also meets
+ 5.1 (level A), but it does not meet the new 5.2 (level AA).
+
As a result, the page could claim to conform to the new WCAG 2.2 success criterion for 1.4.3 Color Contrast
+ [minimum] at level A, and the new 5.1 success criterion (level A), but not the new 5.2 (level AA).
+
NOTE:The author may choose to change their claim or not, as it will be possible to conform to
+ WCAG 2.2 success criteria without making an explicit conformance claim.
+
Note that most of these terms are further discussed in the Requirements for WCAG 2.0 [[wcag2-req]]
+
+
+
+
+
+
+
diff --git a/script/wcag.js b/script/wcag.js
index 5d77931ff1..f1602b0277 100644
--- a/script/wcag.js
+++ b/script/wcag.js
@@ -4,7 +4,7 @@ function titleToPathFrag (title) {
function linkUnderstanding() {
var understandingBaseURI;
- if (respecConfig.specStatus == "ED") understandingBaseURI = "../understanding/";
+ if (respecConfig.specStatus == "ED") understandingBaseURI = "../../understanding/";
else understandingBaseURI = "https://www.w3.org/WAI/WCAG21/Understanding/";
document.querySelectorAll('.sc').forEach(function(node){
var heading = node.firstElementChild.textContent;
diff --git a/techniques/aria/ARIA1.html b/techniques/aria/ARIA1.html
index b88f90b342..0efce9dc7c 100644
--- a/techniques/aria/ARIA1.html
+++ b/techniques/aria/ARIA1.html
@@ -10,7 +10,7 @@
Using aria-describedby property to describe a Close button's action
-
A button that functions as a 'close' button on a dialog is described elsewhere in the document. The aria-describedby property is used to associate the description with the link.
+
A button that functions as a 'close' button on a dialog is described elsewhere in the document. The aria-describedby property is used to associate the description with the button.
Using role=log to identify sequential information updates
-
+
Metadata
ID: W##
Technology: ARIA
Type: Technique
-
+
When to Use
-
+
Description
-
+
The purpose of this technique is to notify Assistive Technologies (AT) when content has been appended to sequential information concerning the application's history or logs. The aria live region role of log has an implicit aria-live value of polite and aria-atomic value of false, which allows a user to be notified via AT (such as a screen reader) when log messages are added. The new content within the aria-live region is automatically read by the AT, without the AT having to focus on the place where the text is displayed. See WAI-ARIA 1.1 log (role) for more details.
- On a page that contains sequentially updating information:
+
On a page that contains sequentially updating information:
Check that the container for the information is given a role of log.
@@ -74,7 +74,7 @@
Expected Results
-
+
Related Techniques
ID
diff --git a/techniques/aria/ARIA24.html b/techniques/aria/ARIA24.html
new file mode 100644
index 0000000000..3a044a8dad
--- /dev/null
+++ b/techniques/aria/ARIA24.html
@@ -0,0 +1,336 @@
+
+
+
+ Semantically identifying a font icon with role="img"
+
+
+
+
+
+
Semantically identifying a font icon with role="img"
+
+
+
Metadata
+
+
aria
+
advisory
+
+
+
+
When to Use
+
This technique is applicable to Markup languages that support ARIA.
+
+
+
+
+
Description
+
The objective of this technique is to show how to semantically identify an element that uses a font file for icons. When a user overrides font-family these icons typically disappear unless there is a means to identify them. The point is to provide a technique to differentiate icon fonts from general font (text) usage.
+
+
Some low vision users need user stylesheets, scripts, or extensions to override the fonts on a page to perceive text content. However, they need to be able to perceive icon fonts that are meaningful, such as a star signifying a favorite, or an email icon in a link.
+
+
The key is for the author to semantically markup icon fonts with role="img". Then the user's font replacement selector can hook into that semantic and exclude role="img". This results in those icon fonts being shown.
+
+
Basic principle of the technique
+
+
1. Author adds a font-face to the CSS
+
The first step is used for adding a font face with icons via the CSS file.
+
+
+/* specify font-family name for icons */
+@font-face { font-family: 'IconFontRoleImg';/ }
+
+/* default class for fonts-face with icons */
+.icon,
+[class^="icon-"],
+[class*=" icon-"] { font-family: 'IconFontRoleImg' !important; }
+
+/* specific class for icon */
+.icon-star-bg:before { content: "\e982"; }
+
+
+
+
2. Author adds the font classes to the HTML
+
The second step adds classes, the role="img" attribute for semantics and an accessible name.
+
+
+<!-- Icon via class names, role="img" and a text alternative -->
+<p>
+ <span class="icon icon-star-bg" role="img" aria-label="Favorite"></span>
+</p>
+
+
+
+
3. User CSS file replaces the font-family except the icon file
+
The third step uses the ":not selector" in combination with the "[attribute] selector" to only replace font faces for regular text.
+
+
+/* Replaces font faces but excludes all elements with attribute role=""img" */
+*:not([role="img"]) { font-family: Verdana, sans-serif !important; }
+
+
+
+
+
+
+
Examples
+
+
+
+
Star Icon Font used as an indicator (not interactive)
+
In this example a star icon is used to indicate a favorite. It is not interactive and does not disappear if the user overrides the font family via CSS.
+
+
+
Author CSS
+
+
+/* default class for fonts-face with icons */
+.icon { font-family: 'IconFontRoleImg' !important; }
+
+/* specific class for icon */
+.icon-star-bg:before { content: "\e982"; }
+
+
Two colored / stacked star Icon Font used as an indicator
+
In this example a two colored star icon is created by stacking two fonts with different colors on top of each other. This way it's possible to mimic only half the star is filled. It is not interactive and does not disappear if the user overrides the font family via CSS.
+
+
Author CSS
+
+
+/* default class for fonts-face with icons */
+.icon { font-family: 'IconFontRoleImg' !important; }
+
+/* specific classes for icons */
+.icon-star-bg:before {content: "\e982"; }
+.icon-star-half:before {content: "\e983"; }
+
+
In this example an email icon is in a link with no visible text. It does not disappear if a user overrides font family. The icon font is identified by assistive technology as a "link image" and the name "Email" (keyboard or mouse).
+
+
Author CSS
+
+
+/* default class for fonts-face with icons */
+.icon { font-family: 'IconFontRoleImg' !important; }
+
+/* specific class for icon */
+.icon-email:before { content: "\e93e"; }
+
+
Multiple Icon Fonts as part of another sematic element WITH visible text
+
+
This example already has a visible text label in the link to be used as an accessible name, the mail and chevron font icons must stay visible when the font family is changed. This can be done by ensuring the icons are contained in their own element and the attribute aria-hidden="true" is used so the font icons will be ignored by assistive technologies.
+
+
Author CSS
+
+
+/* default class for fonts-face with icons */
+.icon { font-family: 'IconFontRoleImg' !important; }
+
+/* specific class for icon */
+- See style declarations in HTML examples -
+
+
+
The element providing the font icon has role="img".
+
+
+
+
Expected Results
+
+
#1 is true.
+
+
+
+
+
diff --git a/techniques/aria/img/work-phone.png b/techniques/aria/img/work-phone.png
new file mode 100644
index 0000000000..323bf50ad0
Binary files /dev/null and b/techniques/aria/img/work-phone.png differ
diff --git a/techniques/client-side-script/SCR32.html b/techniques/client-side-script/SCR32.html
index 9cf983f9a3..dcd8c8f81f 100644
--- a/techniques/client-side-script/SCR32.html
+++ b/techniques/client-side-script/SCR32.html
@@ -8,7 +8,7 @@
This example validates required fields as well as fields where a specific format is required. When an error is identified, the script inserts a list of error messages into the DOM and moves focus to them.
-
+ Screenshot showing the error messages for several fields that were not filled out correctly. Error messages appear as a list of links near the top of the form.
@@ -403,4 +403,4 @@
