diff --git a/guidelines/index.html b/guidelines/index.html index d2717ac5a3..3e8c68329f 100644 --- a/guidelines/index.html +++ b/guidelines/index.html @@ -15,7 +15,7 @@

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 any kind of device (including desktops, laptops, kiosks, 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 alternative 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 diff --git a/guidelines/terms/20/assistive-technology.html b/guidelines/terms/20/assistive-technology.html index 0a9d4c306b..03618ce544 100644 --- a/guidelines/terms/20/assistive-technology.html +++ b/guidelines/terms/20/assistive-technology.html @@ -50,7 +50,7 @@

  • speech recognition software, which may be used by people who have some physical disabilities;
  • alternative keyboards, which are used by people with certain physical disabilities - to simulate the keyboard (including alternate keyboards that use head pointers, single + to simulate the keyboard (including alternative keyboards that use head pointers, single switches, sip/puff and other special input devices.);
  • diff --git a/guidelines/terms/20/conforming-alternate-version.html b/guidelines/terms/20/conforming-alternate-version.html index dd597a83fe..54c447a727 100644 --- a/guidelines/terms/20/conforming-alternate-version.html +++ b/guidelines/terms/20/conforming-alternate-version.html @@ -38,7 +38,7 @@ page unless the user had just come from the conforming version.

    -

    The alternate version does not need to be matched page for page with the original +

    The alternative version does not need to be matched page for page with the original (e.g., the conforming alternate version may consist of multiple pages).

    @@ -46,17 +46,17 @@ required for each language offered.

    -

    Alternate versions may be provided to accommodate different technology environments +

    Alternative versions may be provided to accommodate different technology environments or user groups. Each version should be as conformant as possible. One version would need to be fully conformant in order to meet conformance requirement 1.

    -

    The conforming alternative version does not need to reside within the scope of conformance, +

    The conforming alternate version does not need to reside within the scope of conformance, or even on the same website, as long as it is as freely available as the non-conforming version.

    -

    Alternate versions should not be confused with supplementary content, which support the original page and enhance comprehension. +

    Alternative versions should not be confused with supplementary content, which support the original page and enhance comprehension.

    Setting user preferences within the content to produce a conforming version is an diff --git a/guidelines/terms/20/media-alternative-for-text.html b/guidelines/terms/20/media-alternative-for-text.html index e1adab92ab..8b7f0f63d5 100644 --- a/guidelines/terms/20/media-alternative-for-text.html +++ b/guidelines/terms/20/media-alternative-for-text.html @@ -5,7 +5,7 @@ or via text alternatives)

    -

    A media alternative for text is provided for those who benefit from alternate representations +

    A media alternative for text is provided for those who benefit from alternative representations of text. Media alternatives for text may be audio-only, video-only (including sign-language video), or audio-video.

    diff --git a/techniques/client-side-script/SCR38.html b/techniques/client-side-script/SCR38.html index 2400dfcaa5..026fdd382c 100644 --- a/techniques/client-side-script/SCR38.html +++ b/techniques/client-side-script/SCR38.html @@ -18,10 +18,10 @@

    Description

    This objective of this technique is to offer a conforming alternate version for a web page designed with progressive enhancement. The technique demonstrates how to use a scripting technique to accomplish this by:

    1. Storing the initial pre-enhanced version of the web page so that it can act as a "conforming alternate version" for any later enhanced versions of the content; and
    2. -
    3. Inserting a mechanism into all enhanced versions of the web page which allows a user to revert the content back to the stored pre-enhanced Alternate Version.
    4. +
    5. Inserting a mechanism into all enhanced versions of the web page which allows a user to revert the content back to the stored pre-enhanced Alternative Version.

    Web pages designed with progressive enhancement detect features in the web-enabled accessing device (size, capability and software) to allow those supported web technologies to be applied in layers on top of an HTML foundation. The basic content and functionality of such a web page are available through the HTML foundation to anyone using a more simple web-enabled accessing device, whilst enhanced versions of the page are created to suit the different features in more advanced accessing devices.

    -

    The current guidance for web pages delivered in alternate versions reads: "Note 4: Alternate versions may be provided to accommodate different technology environments or user groups. Each version should be as conformant as possible. One version would need to be fully conformant in order to meet conformance requirement 1." With regard to web pages designed with progressive enhancement this leaves the problem of which version to select as the one fully conformant version - all whilst trying to ensure that no set of users is disadvantaged by that choice.

    +

    The current guidance for web pages delivered in alternative versions reads: "Note 4: Alternative versions may be provided to accommodate different technology environments or user groups. Each version should be as conformant as possible. One version would need to be fully conformant in order to meet conformance requirement 1." With regard to web pages designed with progressive enhancement this leaves the problem of which version to select as the one fully conformant version - all whilst trying to ensure that no set of users is disadvantaged by that choice.

    One solution to this challenge is to select the pre-enhanced version of the web page (e.g. the DOM state created solely from the HTML in the source code in the absence of support for scripts, styles or non-HTML plugins) as the "fully conformant version", due to its broad reach, with regard to support, across all the possible web-enabled devices accessing the content.

    This technique removes all scripts, styles, and plugins, but it is important to state that this is not required for conformance with WCAG 2.x. An author could use a similar technique, but retain a reduced set of styles and scripts in the "pre-enhanced" version.

    While this technique offers a way to base conformance claims on a single version, authors should continue to work to ensure that each enhanced version of the web page is as conformant as possible.

    @@ -122,7 +122,7 @@

    Tests

    Procedure

    1. Check enhanced versions of the web page contain a link to the "Conforming Alternate Version".
    2. -
    3. Check that the alternate version is a conforming alternate version of the original page and that it conforms to WCAG 2.0 at the claimed conformance level.
    4. +
    5. Check that the alternative version is a conforming alternate version of the original page and that it conforms to WCAG 2.0 at the claimed conformance level.
    diff --git a/techniques/css/C29.html b/techniques/css/C29.html index f4514a5892..a68ef284ad 100644 --- a/techniques/css/C29.html +++ b/techniques/css/C29.html @@ -16,7 +16,7 @@

    When to Use

    Description

    -

    When some aspect of the default presentation of a web page does not meet a Success Criterion, it is possible to meet that requirement using the "Alternate Version" clause in the conformance requirements (Conformance Requirement 1). For some requirements, invoking a style switcher via a link or control on the page that can adjust the presentation so that all aspects of the page conform at the level claimed allows authors to avoid having to provide multiple versions of the same information.

    +

    When some aspect of the default presentation of a web page does not meet a Success Criterion, it is possible to meet that requirement using the "Alternative Version" clause in the conformance requirements (Conformance Requirement 1). For some requirements, invoking a style switcher via a link or control on the page that can adjust the presentation so that all aspects of the page conform at the level claimed allows authors to avoid having to provide multiple versions of the same information.

    The objective of this technique is to demonstrate how CSS can be used in combination with scripting to provide conforming alternate versions of a web page. In this technique, an author provides alternative views of the content by providing controls that adjust the CSS that is used to control the visual presentation of content. Controls provided within the web page allow users to select or modify the presentation in a way that meets the success criterion at the level claimed. This makes it possible for different visual presentations to be selected by users in situations such as the following:

    For this technique to be used successfully, three things must be true.

      -
    1. The link or control on the original page must itself meet the success criterion to be met via the alternate presentation. For example, if a style switcher is used to provide increased font sizes and the control is presented using a small font, users may not be able to activate the control and view the alternate presentation.
    2. +
    3. The link or control on the original page must itself meet the success criterion to be met via the alternative presentation. For example, if a style switcher is used to provide increased font sizes and the control is presented using a small font, users may not be able to activate the control and view the alternative presentation.
    4. The new page must contain all the same information and functionality as the original page.
    5. -
    6. The new page must conform to all of the success criteria for the desired level of conformance. For example, an alternate stylesheet can not be used to meet one requirement if it causes a different requirement to no longer conform.
    7. +
    8. The new page must conform to all of the success criteria for the desired level of conformance. For example, an alternative stylesheet can not be used to meet one requirement if it causes a different requirement to no longer conform.

    When using a style switcher, it is important to consider the following challenges and limitations:

    -

    Content that has a failure does not meet WCAG {{ versionDecimal }} success criteria, unless an alternate version is provided without the failure.

    +

    Content that has a failure does not meet WCAG {{ versionDecimal }} success criteria, unless an alternative version is provided without the failure.

    If anyone identifies a situation where a documented failure is not correct, please report the situation as a WCAG 2 comment so that it can be corrected or deleted as appropriate.

    @@ -126,7 +126,7 @@

    Testing Techniques

    Thus while the techniques are useful for evaluating content, evaluations must go beyond just checking the sufficient technique tests in order to evaluate how content conforms to WCAG 2 success criteria.

    -

    Failures are particularly useful for evaluations because they do indicate non-conformance (unless an alternate version is provided without the failure).

    +

    Failures are particularly useful for evaluations because they do indicate non-conformance (unless an alternative version is provided without the failure).

    User Agent and Assistive Technology Support Notes

    @@ -141,7 +141,7 @@

    Using the Techniques

    Techniques for WCAG {{ versionDecimal }} is not intended to be used as a stand-alone document. Instead, it is expected that content authors will usually use How to Meet WCAG {{ versionDecimal }}: A customizable quick reference to read the WCAG 2 success criteria, and follow links from there to specific topics in Understanding WCAG 2 and to specific techniques.

    Alternatives must meet success criteria

    -

    Some techniques describe how to provide alternate ways for users to get content. For example, mentions a transcript as an alternative for an audio file. Some alternatives must also conform to WCAG 2. For example, the transcript itself must meet all relevant success criteria.

    +

    Some techniques describe how to provide alternative ways for users to get content. For example, mentions a transcript as an alternative for an audio file. Some alternatives must also conform to WCAG 2. For example, the transcript itself must meet all relevant success criteria.

    Example Code

    diff --git a/wcag20/Techniques/ua-notes/silverlight.html b/wcag20/Techniques/ua-notes/silverlight.html index f14a5f1b41..f2c35a67fd 100644 --- a/wcag20/Techniques/ua-notes/silverlight.html +++ b/wcag20/Techniques/ua-notes/silverlight.html @@ -1,5 +1,5 @@ -User Agent Support Notes for for Silverlight Techniques

    User Agent Support Notes for Silverlight Techniques

    This page documents user agent support notes for Silverlight Techniques.

    SL1: Accessing Alternate Audio Tracks in Silverlight Media

    See User Agents Supported for general information on user agent support.

    SL2: Changing The Visual Focus Indicator in Silverlight

    SL3: Controlling Silverlight MediaElement Audio Volume

    SL4: Declaring Discrete Silverlight Objects to Specify Language Parts + in Silverlight techniques.

    SL1: Accessing Alternative Audio Tracks in Silverlight Media

    See User Agents Supported for general information on user agent support.

    SL2: Changing The Visual Focus Indicator in Silverlight

    SL3: Controlling Silverlight MediaElement Audio Volume

    SL4: Declaring Discrete Silverlight Objects to Specify Language Parts in the HTML DOM

    SL5: Defining a Focusable Image Class for Silverlight

    SL6: Defining a UI Automation Peer for a Custom Silverlight Control

    SL7: Designing a Focused Visual State for Custom Silverlight Controls

    SL8: Displaying HelpText in Silverlight User Interfaces

    SL9: Handling Key Events to Enable Keyboard Functionality in Silverlight

    SL10: Implementing a Submit-Form Pattern in Silverlight

    SL11: Pausing or Stopping A Decorative Silverlight Animation

    SL12: Pausing, Stopping, or Playing Media in Silverlight MediaElements

    SL13: Providing A Style Switcher To Switch To High Contrast

    SL14: Providing Custom Control Key Handling for Keyboard Functionality in Silverlight

    SL15: Providing Keyboard Shortcuts that Work Across the Entire Silverlight Application

    SL16: Providing Script-Embedded Text Captions for MediaElement Content

    SL17: Providing Static Alternative Content for Silverlight Media Playing diff --git a/wcag20/sources/wcag2ict.html b/wcag20/sources/wcag2ict.html index 7d0ad94d2b..677c6375ce 100644 --- a/wcag20/sources/wcag2ict.html +++ b/wcag20/sources/wcag2ict.html @@ -239,7 +239,7 @@

    W3C Andi Snow-Weaver, IBM Corporation
    Gregg Vanderheiden, Invited Expert, Trace Research and Development Center
    -

    This document is available in an expandable / collapsible alternate version in which the “Intent” sections copied from Understanding WCAG 2.0 are hidden and individually expandable, for easier reading.

    +

    This document is available in an expandable / collapsible alternative version in which the “Intent” sections copied from Understanding WCAG 2.0 are hidden and individually expandable, for easier reading.


    Abstract

    @@ -251,7 +251,7 @@

    Status of This Document

    This document is a Working Group Notean Editors' Draft being developed by the WCAG2ICT Task Force (“Task Force”) operating under the terms of its Work Statement, and under the coordination and review of the Web Content Accessibility Guidelines Working Group (WCAG WG), which is part of the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C). The WCAG2ICT Task Force's work is consistent with the WCAG WG Charter that includes the following under its scope: “Coordinating with other entities adopting and using WCAG 2.0”.

    -

    This Working Group Note includes complete guidance for all Levels A and AA Success Criteria, guidance on all glossary terms plus new Key Terms, comments on conformance, and additional background information on some topics. This version includes changes made in response to comments received on the three earlier Working Drafts of this document. It also contains references to an alternate presentation in which the “Intent” sections copied from Understanding WCAG 2.0 are hidden and individually expandable, for easier reading.

    +

    This Working Group Note includes complete guidance for all Levels A and AA Success Criteria, guidance on all glossary terms plus new Key Terms, comments on conformance, and additional background information on some topics. This version includes changes made in response to comments received on the three earlier Working Drafts of this document. It also contains references to an alternative presentation in which the “Intent” sections copied from Understanding WCAG 2.0 are hidden and individually expandable, for easier reading.

    As a Working Group Note this content is stable, and the Working Group does not plan to make further changes. Should the need arise, however, the document could be updated. Comments received on this document will help the Working Group to decide if updates are needed, or will be taken into account should a republication be planned. Please send any comments on the “Additional Guidance” sections of this document to the public mailing list public-wcag2ict-comments@w3.org. Please include the following in your comments: the title of the document, location within the document, the concern, the suggested change, and any additional rationale for your comment.

    This document includes many excerpts from “Understanding WCAG 2.0,” each of which is prefaced with the words “Intent from…” and which are also visually indicated with a yellow background. Understanding WCAG 2.0 and other WCAG 2.0 supporting documents will continue to focus on web technologies. For comments on Understanding WCAG, please follow the comment instructions in that document.

    @@ -467,7 +467,7 @@

    Success Criterion 1.1.1: Non-text Content (Level A)

    Guideline 1.2: Time-based Media

    Success Criterion 1.2.1: Audio-only and Video-only (Prerecorded) (Level A)

    This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.1 (also provided below).

    -

    Note 1: The alternative can be provided directly in the non-web document or software – or provided in an alternate version that meets the success criteria.

    +

    Note 1: The alternative can be provided directly in the non-web document or software – or provided in an alternative version that meets the success criteria.

    Note 2: See also the discussion on Closed Functionality in the Introduction.

    Success Criterion 1.2.2: Captions (Prerecorded) (Level A)

    @@ -477,7 +477,7 @@

    Success Criterion 1.2.2: Captions (Prerecorded) (Level A)

    Success Criterion 1.2.3: Audio Description or Media Alternative (Prerecorded) (Level A)

    This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.3 (also provided below).

    Note 1: The WCAG 2.0 definition of “audio description” says that “audio description” is “also called ‘video description’ and ‘descriptive narration’”.

    -

    Note 2: Secondary or alternate audio tracks are commonly used for this purpose.

    +

    Note 2: Secondary or alternative audio tracks are commonly used for this purpose.

    Note 3: See also the discussion on Closed Functionality in the Introduction.

    Success Criterion 1.2.4: Captions (Live) (Level AA)

    @@ -487,7 +487,7 @@

    Success Criterion 1.2.4: Captions (Live) (Level AA)

    Success Criterion 1.2.5: Audio Description (Prerecorded) (Level AA)

    This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.5 (also provided below).

    Note1: The WCAG 2.0 definition of “audio description” says that audio description is “also called ‘video description’ and ‘descriptive narration’”.

    -

    Note2: Secondary or alternate audio tracks are commonly used for this purpose.

    +

    Note2: Secondary or alternative audio tracks are commonly used for this purpose.

    Success Criterion 1.2.6: Sign Language (Prerecorded) (Level AAA)

    @@ -967,7 +967,7 @@

    assistive technology (as used in this document)

    speech recognition software, which may be used by people who have some physical disabilities;

  • -

    alternative keyboards, which are used by people with certain physical disabilities to simulate the keyboard (including alternate keyboards that use head pointers, single switches, sip/puff and other special input devices.);

    +

    alternative keyboards, which are used by people with certain physical disabilities to simulate the keyboard (including alternative keyboards that use head pointers, single switches, sip/puff and other special input devices.);

  • alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.

    @@ -1260,7 +1260,7 @@

    Web page

    Note: For those success criteria that use the term “web page”, WCAG2ICT provides specific replacement term(s) for “Web page”.

  • Appendix A. Success Criteria Problematic for Closed Functionality

    -

    The following success criteria will be problematic for developers of closed functionality. They either discuss making information available in text (which can be read by assistive technologies) or making it “programmatically determinable” (rendered by a user agent and readable by assistive technologies) or discuss doing something else to make content compatible with assistive technologies. Alternate accessibility provisions that would be needed to address the purpose of these success criteria for the closed functionality aspects of products:

    +

    The following success criteria will be problematic for developers of closed functionality. They either discuss making information available in text (which can be read by assistive technologies) or making it “programmatically determinable” (rendered by a user agent and readable by assistive technologies) or discuss doing something else to make content compatible with assistive technologies. Alternative accessibility provisions that would be needed to address the purpose of these success criteria for the closed functionality aspects of products:

    How text applications have been made accessible via assistive technology

    Strategies for making text applications accessible through assistive technology involve two key tasks: (1) obtaining all of the text displayed in the interface, and (2) performing an analysis on that text to discern structural elements and screen updates.

    -

    For example, a text application screen reader might directly access the matrix of character cells in the interface and provide a screen review mechanism for the user to review that matrix of characters (by sending the output to synthetic speech and / or a braille display). Alternately, a text application screen reader might directly consume the output rendered (perhaps by acting as its own terminal application or by analyzing the “TTY” output). The text application screen reader would also analyze the spacing and layout of the text in the matrix to provide features such as reading columns of text in a multi-column layout, discerning headers through analysis of line spacing, indentation and capitalization, and discerning input fields or user interface components, etc. by scanning for the use of inverse video or for text appearing in brackets or text from the character graphics codepage (ASCII codes greater than ‘0x7F’). Some of this analysis might also be done through the use of +

    For example, a text application screen reader might directly access the matrix of character cells in the interface and provide a screen review mechanism for the user to review that matrix of characters (by sending the output to synthetic speech and / or a braille display). Alternatively, a text application screen reader might directly consume the output rendered (perhaps by acting as its own terminal application or by analyzing the “TTY” output). The text application screen reader would also analyze the spacing and layout of the text in the matrix to provide features such as reading columns of text in a multi-column layout, discerning headers through analysis of line spacing, indentation and capitalization, and discerning input fields or user interface components, etc. by scanning for the use of inverse video or for text appearing in brackets or text from the character graphics codepage (ASCII codes greater than ‘0x7F’). Some of this analysis might also be done through the use of filter tools that transform the output of a program (e.g. through reformatting “TTY” output rendered to a file or as direct input to a filter too).

    Similarly, a text application screen magnifier would gain access to the matrix of character cells in order to magnify them or re-display them in a larger font. It would scan for screen refreshes / updates and apply heuristics to what had changed in order to decide what sub-matrix of character cells should appear in a magnified view. It would also scan for inverse video and a moving text cursor to track text being input by the user (and might combine the text matrix scanning with scanning of the keyboard input to match user input to what is appearing on the screen).