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.
+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.
+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 + 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).
@@ -29,12 +29,12 @@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.
+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.
-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:
+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:
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.
+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.
Principles - At the top are four principles that provide the foundation for Web accessibility: perceivable, operable, understandable, and robust. See also Understanding the Four Principles of Accessibility.
+Principles - At the top are four principles that provide the foundation for web accessibility: perceivable, operable, understandable, and robust. See also Understanding the Four Principles of Accessibility.
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.
@@ -60,14 +60,14 @@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, Making Content Usable for People with Cognitive and Learning Disabilities, 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.
+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, Making Content Usable for People with Cognitive and Learning Disabilities, 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.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.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, 2.1 2.2 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, 2.1 2.2 and can be filtered in many ways to help authors focus on relevant content.
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.
@@ -80,7 +80,7 @@What's New in WCAG 2.2 introduces the new success criteria with persona quotes that illustrate the accessibility issues.
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.
+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 websites, and accessibility policies are listed in WAI Resources.
Make Web pages appear and operate in predictable ways.
+Make web pages appear and operate in predictable ways.
@@ -408,35 +408,35 @@In order for a Web page to conform to WCAG 2.2, 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:
One of the following levels of conformance is met in full.
Although conformance can only be achieved at the stated levels, authors are encouraged to report (in their claim) any progress toward meeting success criteria from all levels beyond the achieved level of conformance.
-It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content.
+It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA success criteria for some content.
Conformance (and conformance level) is for full Web page(s) only, and cannot be achieved if part of a Web page is excluded.
+Conformance (and conformance level) is for full web page(s) only, and cannot be achieved if part of a web page is excluded.
For the purpose of determining conformance, alternatives to part of a page's content are considered part of the page when the alternatives can be obtained directly from the page, e.g., a long description or an alternative presentation of a video.
-Authors of Web pages that cannot conform due to content outside of the author's control may consider a Statement of Partial Conformance.
-A full page includes each variation of the page that is automatically presented by the page for various screen sizes (e.g. variations in a responsive Web page). Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform.
+Authors of web pages that cannot conform due to content outside of the author's control may consider a Statement of Partial Conformance.
+A full page includes each variation of the page that is automatically presented by the page for various screen sizes (e.g. variations in a responsive web page). Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform.
When a Web page is one of a series of Web pages presenting a process (i.e., a sequence of steps that need to be completed in order to accomplish an activity), all Web pages in the process conform at the specified level or better. (Conformance is not possible at a particular level if any page in the process does not conform at that level or better.)
+When a web page is one of a series of web pages presenting a process (i.e., a sequence of steps that need to be completed in order to accomplish an activity), all web pages in the process conform at the specified level or better. (Conformance is not possible at a particular level if any page in the process does not conform at that level or better.)
If technologies are used in a way that is not accessibility supported, or if they are used in a non-conforming way, then they do not block the ability of users to access the rest of the page. In addition, the Web page as a whole continues to meet the conformance requirements under each of the following conditions:
+If technologies are used in a way that is not accessibility supported, or if they are used in a non-conforming way, then they do not block the ability of users to access the rest of the page. In addition, the web page as a whole continues to meet the conformance requirements under each of the following conditions:
Conformance is defined only for Web pages. However, a conformance claim may be made to cover one page, a series of pages, or multiple related Web pages.
+Conformance is defined only for web pages. However, a conformance claim may be made to cover one page, a series of pages, or multiple related web pages.
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.
-The Web pages may be described by list or by an expression that describes all of the URIs included in the claim.
-Web-based products that do not have a URI prior to installation on the customer's Web site may have a statement that the product would conform when installed.
+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.
+The web pages may be described by list or by an expression that describes all of the URIs included in the claim.
+Web-based products that do not have a URI prior to installation on the customer's website may have a statement that the product would conform when installed.
If a conformance logo is used, it would constitute a claim and must be accompanied by the required components of a conformance claim listed above.
@@ -539,8 +539,8 @@Success Criteria within this specification which the Working Group has identified possible implications for privacy, either by providing protections for end users or which are important for web site providers to take in to consideration when implementing features designed to protect user privacy, are listed below. This list reflects the current understanding of the Working Group but other Success Criteria may have privacy implications that the Working Group is not aware of at the time of publishing.
-Success Criteria within this specification that may relate to privacy are:
+Success criteria within this specification which the Working Group has identified possible implications for privacy, either by providing protections for end users or which are important for website providers to take in to consideration when implementing features designed to protect user privacy, are listed below. This list reflects the current understanding of the Working Group but other Success criteria may have privacy implications that the Working Group is not aware of at the time of publishing.
+Success criteria within this specification that may relate to privacy are:
Success Criteria within this specification which the Working Group has identified possible implications for security, either by providing protections for end users or which are important for web site providers to take in to consideration when implementing features designed to protect user security, are listed below. This list reflects the current understanding of the Working Group but other Success Criteria may have security implications that the Working Group is not aware of at the time of publishing.
-Success Criteria within this specification that may relate to security are:
+Success criteria within this specification which the Working Group has identified possible implications for security, either by providing protections for end users or which are important for website providers to take in to consideration when implementing features designed to protect user security, are listed below. This list reflects the current understanding of the Working Group but other Success criteria may have security implications that the Working Group is not aware of at the time of publishing.
+Success criteria within this specification that may relate to security are:
Before May 2021 the value of 0.04045 in the definition was different (0.03928). It was taken from an older version of the specification and has been updated. It has no practical effect on the calculations in the context of these guidelines.
Almost all systems used today to view Web content assume sRGB encoding. Unless it +
Almost all systems used today to view web content assume sRGB encoding. Unless it is known that another color space will be used to process and display the content, authors should evaluate using sRGB colorspace. If using other color spaces, see Understanding Success Criterion 1.4.3.
A
-If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio +
If any audio on a web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.
Since any content that does not meet this success criterion can interfere with a user's - ability to use the whole page, all content on the Web page (whether or not it is used + ability to use the whole page, all content on the web page (whether or not it is used to meet other success criteria) must meet this success criterion. See Conformance Requirement 5: Non-Interference.
diff --git a/guidelines/sc/20/bypass-blocks.html b/guidelines/sc/20/bypass-blocks.html index 5e33982b78..0f4ce7ca78 100644 --- a/guidelines/sc/20/bypass-blocks.html +++ b/guidelines/sc/20/bypass-blocks.html @@ -4,7 +4,7 @@A
-A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. +
A mechanism is available to bypass blocks of content that are repeated on multiple web pages.
diff --git a/guidelines/sc/20/consistent-identification.html b/guidelines/sc/20/consistent-identification.html index 789b8d23f6..6b04f77b20 100644 --- a/guidelines/sc/20/consistent-identification.html +++ b/guidelines/sc/20/consistent-identification.html @@ -4,7 +4,7 @@AA
-Components that have the same functionality within a set of Web pages are identified consistently. +
Components that have the same functionality within a set of web pages are identified consistently.
diff --git a/guidelines/sc/20/consistent-navigation.html b/guidelines/sc/20/consistent-navigation.html index a1df5d4e8a..041cfd7ad9 100644 --- a/guidelines/sc/20/consistent-navigation.html +++ b/guidelines/sc/20/consistent-navigation.html @@ -4,7 +4,7 @@AA
-Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. +
Navigational mechanisms that are repeated on multiple web pages within a set of web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.
diff --git a/guidelines/sc/20/error-prevention-all.html b/guidelines/sc/20/error-prevention-all.html index 8fb05bb90e..2b45e63503 100644 --- a/guidelines/sc/20/error-prevention-all.html +++ b/guidelines/sc/20/error-prevention-all.html @@ -4,7 +4,7 @@AAA
-For Web pages that require the user to submit information, at least one of the following is true: +
For web pages that require the user to submit information, at least one of the following is true:
AA
-For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of +
For web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true:
diff --git a/guidelines/sc/20/focus-order.html b/guidelines/sc/20/focus-order.html index 5c36ef43f5..67c724e207 100644 --- a/guidelines/sc/20/focus-order.html +++ b/guidelines/sc/20/focus-order.html @@ -4,7 +4,7 @@A
-If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive +
If a web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.
diff --git a/guidelines/sc/20/language-of-page.html b/guidelines/sc/20/language-of-page.html index c921129756..bae8a9ee88 100644 --- a/guidelines/sc/20/language-of-page.html +++ b/guidelines/sc/20/language-of-page.html @@ -4,7 +4,7 @@A
-The default human language of each Web page can be programmatically determined. +
The default human language of each web page can be programmatically determined.
diff --git a/guidelines/sc/20/location.html b/guidelines/sc/20/location.html index c7cb164b4f..cb72028db4 100644 --- a/guidelines/sc/20/location.html +++ b/guidelines/sc/20/location.html @@ -4,7 +4,7 @@AAA
-Information about the user's location within a set of Web pages is available. +
Information about the user's location within a set of web pages is available.
diff --git a/guidelines/sc/20/multiple-ways.html b/guidelines/sc/20/multiple-ways.html index 0b66078a99..f320500072 100644 --- a/guidelines/sc/20/multiple-ways.html +++ b/guidelines/sc/20/multiple-ways.html @@ -4,7 +4,7 @@AA
-More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process. +
More than one way is available to locate a web page within a set of web pages except where the web page is the result of, or a step in, a process.
diff --git a/guidelines/sc/20/name-role-value.html b/guidelines/sc/20/name-role-value.html index b3ce49a363..d28ac0b22a 100644 --- a/guidelines/sc/20/name-role-value.html +++ b/guidelines/sc/20/name-role-value.html @@ -8,7 +8,7 @@This success criterion is primarily for Web authors who develop or script their own +
This success criterion is primarily for web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.
diff --git a/guidelines/sc/20/no-keyboard-trap.html b/guidelines/sc/20/no-keyboard-trap.html index 89d917165d..c8865dd0db 100644 --- a/guidelines/sc/20/no-keyboard-trap.html +++ b/guidelines/sc/20/no-keyboard-trap.html @@ -10,7 +10,7 @@Since any content that does not meet this success criterion can interfere with a user's - ability to use the whole page, all content on the Web page (whether it is used to + ability to use the whole page, all content on the web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.
diff --git a/guidelines/sc/20/pause-stop-hide.html b/guidelines/sc/20/pause-stop-hide.html index ab71a6bf3b..e8eaf3f32a 100644 --- a/guidelines/sc/20/pause-stop-hide.html +++ b/guidelines/sc/20/pause-stop-hide.html @@ -39,7 +39,7 @@Since any content that does not meet this success criterion can interfere with a user's - ability to use the whole page, all content on the Web page (whether it is used to + ability to use the whole page, all content on the web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.
diff --git a/guidelines/sc/20/three-flashes-or-below-threshold.html b/guidelines/sc/20/three-flashes-or-below-threshold.html index 13b874c11e..cb031f7072 100644 --- a/guidelines/sc/20/three-flashes-or-below-threshold.html +++ b/guidelines/sc/20/three-flashes-or-below-threshold.html @@ -9,7 +9,7 @@Since any content that does not meet this success criterion can interfere with a user's - ability to use the whole page, all content on the Web page (whether it is used to + ability to use the whole page, all content on the web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.
diff --git a/guidelines/sc/22/accessible-authentication-minimum.html b/guidelines/sc/22/accessible-authentication-minimum.html index 150b65fef0..bcb7231466 100644 --- a/guidelines/sc/22/accessible-authentication-minimum.html +++ b/guidelines/sc/22/accessible-authentication-minimum.html @@ -14,7 +14,7 @@"Object recognition" and "Personal content" may be represented by images, video, or audio.
diff --git a/guidelines/sc/22/consistent-help.html b/guidelines/sc/22/consistent-help.html index 62c9292b09..bdb9b91a02 100644 --- a/guidelines/sc/22/consistent-help.html +++ b/guidelines/sc/22/consistent-help.html @@ -5,7 +5,7 @@A
New
-If a Web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple Web pages within a set of Web pages, they occur in the same order relative to other page content, unless a change is initiated by the user:
+If a web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple web pages within a set of web pages, they occur in the same order relative to other page content, unless a change is initiated by the user:
Help mechanisms may be provided directly on the page, or may be provided via a direct link to a different page containing the information.
-For this Success Criterion, "the same order relative to other page content" can be thought of as how the content is ordered when the page is serialized. The visual position of a help mechanism is likely to be consistent across pages for the same page variation (e.g., CSS break-point). The user can initiate a change, such as changing the page's zoom or orientation, which may trigger a different page variation. This criterion is concerned with relative order across pages displayed in the same page variation (e.g., same zoom level and orientation).
+For this success criterion, "the same order relative to other page content" can be thought of as how the content is ordered when the page is serialized. The visual position of a help mechanism is likely to be consistent across pages for the same page variation (e.g., CSS break-point). The user can initiate a change, such as changing the page's zoom or orientation, which may trigger a different page variation. This criterion is concerned with relative order across pages displayed in the same page variation (e.g., same zoom level and orientation).
diff --git a/guidelines/sc/22/focus-not-obscured-minimum.html b/guidelines/sc/22/focus-not-obscured-minimum.html index 4d0ef3bce2..0ac886b9eb 100644 --- a/guidelines/sc/22/focus-not-obscured-minimum.html +++ b/guidelines/sc/22/focus-not-obscured-minimum.html @@ -7,7 +7,7 @@When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.
-Where content in a configurable interface can be repositioned by the user, then only the initial positions of user-movable content are considered for testing and conformance of this Success Criterion.
+Where content in a configurable interface can be repositioned by the user, then only the initial positions of user-movable content are considered for testing and conformance of this success criterion.
Content opened by the user may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered visually hidden due to author-created content.
diff --git a/guidelines/terms/20/accessibility-supported.html b/guidelines/terms/20/accessibility-supported.html index e863db98c9..3d53e4c99a 100644 --- a/guidelines/terms/20/accessibility-supported.html +++ b/guidelines/terms/20/accessibility-supported.html @@ -3,8 +3,8 @@supported by users' assistive technologies as well as the accessibility features in browsers and other user agents
-To qualify as an accessibility-supported use of a Web content technology (or feature - of a technology), both 1 and 2 must be satisfied for a Web content technology (or +
To qualify as an accessibility-supported use of a web content technology (or feature + of a technology), both 1 and 2 must be satisfied for a web content technology (or feature):
@@ -12,7 +12,7 @@The way that the Web content technology is used must be supported by users' assistive technology (AT). This means that the way that the technology is used has been tested for interoperability +
The way that the web content technology is used must be supported by users' assistive technology (AT). This means that the way that the technology is used has been tested for interoperability with users' assistive technology in the human language(s) of the content,
@@ -22,7 +22,7 @@The Web content technology must have accessibility-supported user agents that are
+ The web content technology must have accessibility-supported user agents that are
available to users. This means that at least one of the following four statements is true:
The Accessibility Guidelines Working Group and the W3C do not specify which or how much support by assistive
- technologies there must be for a particular use of a Web technology in order for it
+ technologies there must be for a particular use of a web technology in order for it
to be classified as accessibility supported. (See Level of Assistive Technology Support Needed for "Accessibility Support".)
When a Web Technology is used in a way that is "accessibility supported," it does not imply that the entire +
When a web technology is used in a way that is "accessibility supported," it does not imply that the entire technology or all uses of the technology are supported. Most technologies, including HTML, lack support for at least one feature or use. Pages conform to WCAG only if the uses of the technology that are accessibility supported can be relied upon to meet WCAG requirements.
-When citing Web content technologies that have multiple versions, the version(s) supported +
When citing web content technologies that have multiple versions, the version(s) supported should be specified.
One way for authors to locate uses of a technology that are accessibility supported would be to consult compilations of uses that are documented to be accessibility supported. (See Understanding Accessibility-Supported Web Technology Uses.) Authors, companies, technology vendors, or others may document accessibility-supported - ways of using Web content technologies. However, all ways of using technologies in + ways of using web content technologies. However, all ways of using technologies in the documentation would need to meet the definition of accessibility-supported Web content technologies above.
diff --git a/guidelines/terms/20/ambiguous-to-users-in-general.html b/guidelines/terms/20/ambiguous-to-users-in-general.html index 5260803b07..71e67d8b93 100644 --- a/guidelines/terms/20/ambiguous-to-users-in-general.html +++ b/guidelines/terms/20/ambiguous-to-users-in-general.html @@ -1,7 +1,7 @@the purpose cannot be determined from the link and all information of the Web page +
the purpose cannot be determined from the link and all information of the web page presented to the user simultaneously with the link (i.e., readers without disabilities would not know what a link would do until they activated it)
diff --git a/guidelines/terms/20/assistive-technology.html b/guidelines/terms/20/assistive-technology.html index 4a918854c8..0a9d4c306b 100644 --- a/guidelines/terms/20/assistive-technology.html +++ b/guidelines/terms/20/assistive-technology.html @@ -23,7 +23,7 @@ target narrowly defined populations of users with specific disabilities. The assistance provided by an assistive technology is more specific and appropriate to the needs of its target users. The mainstream user agent may provide important functionality - to assistive technologies like retrieving Web content from program objects or parsing + to assistive technologies like retrieving web content from program objects or parsing markup into identifiable bundles. diff --git a/guidelines/terms/20/changes-of-context.html b/guidelines/terms/20/changes-of-context.html index b57e76b901..68a261e170 100644 --- a/guidelines/terms/20/changes-of-context.html +++ b/guidelines/terms/20/changes-of-context.html @@ -17,7 +17,7 @@The conforming alternative version does not need to reside within the scope of conformance, - or even on the same Web site, as long as it is as freely available as the non-conforming + or even on the same website, as long as it is as freely available as the non-conforming version.
diff --git a/guidelines/terms/20/content.html b/guidelines/terms/20/content.html index cce2c2c612..eb3681640c 100644 --- a/guidelines/terms/20/content.html +++ b/guidelines/terms/20/content.html @@ -1,4 +1,4 @@ -For general software or Web content, using a 341 x 256 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 x 768 pixels will provide a good estimate of a 10 degree visual field for standard screen sizes and viewing distances (e.g., 15-17 inch screen at 22-26 inches). This resolution of 75 - 85 ppi is known to be lower, and thus more conservative than the nominal CSS pixel resolution of 96 ppi in CSS specifications. Higher resolutions displays showing the same rendering of the content yield smaller and safer images so it is lower resolutions that are used to define the thresholds. +
For general software or web content, using a 341 x 256 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 x 768 pixels will provide a good estimate of a 10 degree visual field for standard screen sizes and viewing distances (e.g., 15-17 inch screen at 22-26 inches). This resolution of 75 - 85 ppi is known to be lower, and thus more conservative than the nominal CSS pixel resolution of 96 ppi in CSS specifications. Higher resolutions displays showing the same rendering of the content yield smaller and safer images so it is lower resolutions that are used to define the thresholds.
A transition is the change in relative luminance (or relative luminance/color for diff --git a/guidelines/terms/20/input-error.html b/guidelines/terms/20/input-error.html index 1febee2c75..7d93a33ab2 100644 --- a/guidelines/terms/20/input-error.html +++ b/guidelines/terms/20/input-error.html @@ -8,7 +8,7 @@
text or other component with a text alternative that is presented to a user to identify a component within Web content
+text or other component with a text alternative that is presented to a user to identify a component within web content
A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same. diff --git a/guidelines/terms/20/name.html b/guidelines/terms/20/name.html index 9530872de2..c51273a1fe 100644 --- a/guidelines/terms/20/name.html +++ b/guidelines/terms/20/name.html @@ -1,7 +1,7 @@
text by which software can identify a component within Web content to the user
+text by which software can identify a component within web content to the user
The name may be hidden and only exposed by assistive technology, whereas a label is presented to all users. In many (but not all) cases, the label and the name are the same. diff --git a/guidelines/terms/20/process.html b/guidelines/terms/20/process.html index 9cafc80647..db40088cd4 100644 --- a/guidelines/terms/20/process.html +++ b/guidelines/terms/20/process.html @@ -3,7 +3,7 @@
series of user actions where each action is required in order to complete an activity
-