From 0df965aaa20021482653591b4691791ea2f7287d Mon Sep 17 00:00:00 2001 From: "Kenneth G. Franqueiro" Date: Fri, 15 Nov 2024 11:05:07 -0500 Subject: [PATCH 01/18] Generate guidelines during Netlify PR preview builds (#4141) This effectively replaces what the pr-preview bot currently does (and what #2220 sought to do within the repo). The problem with the pr-preview bot is its previews don't fully work (e.g. as seen in #4123). ## Changes - Remove `.pr-preview.json` to stop pr-preview bot from running - Add logic to `eleventy.config.ts` to copy `guidelines` folder assets and run through spec-generator (the same thing we use for GH Pages builds; also the same thing used by the pr-preview bot, IIUC) when running a standard build through netlify - Conditionally add guidelines list item to top-level `index.html` (which is only used for local dev and PR builds) - Tangentially, rename our github-pages push workflow to be more distinguishable in the Actions tab --- .github/workflows/11ty-publish.yaml | 2 +- .pr-preview.json | 4 ---- eleventy.config.ts | 31 +++++++++++++++++++++++++++-- index.html | 15 ++++++++++++++ package.json | 1 + 5 files changed, 46 insertions(+), 7 deletions(-) delete mode 100644 .pr-preview.json diff --git a/.github/workflows/11ty-publish.yaml b/.github/workflows/11ty-publish.yaml index adbb274be0..fd2ec74e6b 100644 --- a/.github/workflows/11ty-publish.yaml +++ b/.github/workflows/11ty-publish.yaml @@ -1,4 +1,4 @@ -name: CI +name: Push to gh-pages branch # Reference documentation: https://docs.github.com/en/actions/reference diff --git a/.pr-preview.json b/.pr-preview.json deleted file mode 100644 index bf7627ccb3..0000000000 --- a/.pr-preview.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "src_file": "guidelines/index.html", - "type": "respec" -} diff --git a/eleventy.config.ts b/eleventy.config.ts index fc9fe5ff69..abec817370 100644 --- a/eleventy.config.ts +++ b/eleventy.config.ts @@ -1,7 +1,10 @@ +import axios from "axios"; import compact from "lodash-es/compact"; +import { mkdirp } from "mkdirp"; import { rimraf } from "rimraf"; -import { copyFile } from "fs/promises"; +import { copyFile, writeFile } from "fs/promises"; +import { join } from "path"; import { CustomLiquid } from "11ty/CustomLiquid"; import { @@ -184,7 +187,31 @@ export default function (eleventyConfig: any) { eleventyConfig.on("eleventy.after", async ({ dir }: EleventyEvent) => { // addPassthroughCopy can only map each file once, // but base.css needs to be copied to a 2nd destination - await copyFile(`${dir.input}/css/base.css`, `${dir.output}/understanding/base.css`); + await copyFile( + join(dir.input, "css", "base.css"), + join(dir.output, "understanding", "base.css") + ); + + // Output guidelines/index.html and dependencies for PR runs (not for GH Pages or W3C site) + const sha = process.env.COMMIT_REF; // Read environment variable exposed by Netlify + if (sha && !process.env.WCAG_MODE) { + await mkdirp(join(dir.output, "guidelines")); + await copyFile( + join(dir.input, "guidelines", "guidelines.css"), + join(dir.output, "guidelines", "guidelines.css") + ); + await copyFile( + join(dir.input, "guidelines", "relative-luminance.html"), + join(dir.output, "guidelines", "relative-luminance.html") + ); + + const url = `https://raw.githack.com/${GH_ORG}/${GH_REPO}/${sha}/guidelines/index.html?isPreview=true`; + const { data: processedGuidelines } = await axios.get( + `https://labs.w3.org/spec-generator/?type=respec&url=${encodeURIComponent(url)}`, + { responseType: "text" } + ); + await writeFile(`${dir.output}/guidelines/index.html`, processedGuidelines); + } }); eleventyConfig.setLibrary( diff --git a/index.html b/index.html index 9fcfa92eb7..56183d90c5 100644 --- a/index.html +++ b/index.html @@ -1,3 +1,9 @@ +---js +// Same condition used for copying guidelines assets in eleventy.config.ts +const includeGuidelines = process.env.COMMIT_REF && !process.env.WCAG_MODE; +const repoUrl = process.env.REPOSITORY_URL; +const prNumber = process.env.REVIEW_ID; +--- @@ -6,7 +12,16 @@

Web Content Accessibility Guidelines {{ versionDecimal }}

+ {% if repoUrl and prNumber -%} +

+ Note: This is a preview for + PR #{{ prNumber }}. +

+ {%- endif %} diff --git a/package.json b/package.json index b481b35df8..156a3283e7 100644 --- a/package.json +++ b/package.json @@ -15,6 +15,7 @@ "license": "W3C", "dependencies": { "@11ty/eleventy": "^3.0.0", + "axios": "^1.7.7", "cheerio": "^1.0.0", "glob": "^10.3.16", "gray-matter": "^4.0.3", From a2c3cb32e044f06ff5d4b554c908d20582c2b44b Mon Sep 17 00:00:00 2001 From: Mike Gower Date: Tue, 19 Nov 2024 08:06:02 -0800 Subject: [PATCH 02/18] Cfc style updates (#4080) Style changes to normative documents made to ensure consistency as part of the republishing of WCAG 2.2 - Ensures all normative occurrences of "web page" are two words and lower case. - Ensures all normative occurrences of "website" are a single word, not capitalized. - Ensures all normative occurrences of "success criterion/criteria" that do not specify SCs by name, are lower case - Ensures all normative occurrences of "web content" and other uses of "web" are lower case *** Preview | Diff --------- Co-authored-by: Alastair Campbell --- guidelines/index.html | 64 +++++++------- guidelines/input-purposes.html | 2 +- guidelines/relative-luminance.html | 2 +- guidelines/sc/20/audio-control.html | 4 +- guidelines/sc/20/bypass-blocks.html | 2 +- .../sc/20/consistent-identification.html | 2 +- guidelines/sc/20/consistent-navigation.html | 2 +- guidelines/sc/20/error-prevention-all.html | 2 +- ...error-prevention-legal-financial-data.html | 2 +- guidelines/sc/20/focus-order.html | 2 +- guidelines/sc/20/language-of-page.html | 2 +- guidelines/sc/20/location.html | 2 +- guidelines/sc/20/multiple-ways.html | 2 +- guidelines/sc/20/name-role-value.html | 2 +- guidelines/sc/20/no-keyboard-trap.html | 2 +- guidelines/sc/20/pause-stop-hide.html | 2 +- .../20/three-flashes-or-below-threshold.html | 2 +- .../22/accessible-authentication-minimum.html | 2 +- guidelines/sc/22/consistent-help.html | 4 +- .../sc/22/focus-not-obscured-minimum.html | 2 +- .../terms/20/accessibility-supported.html | 16 ++-- .../20/ambiguous-to-users-in-general.html | 2 +- guidelines/terms/20/assistive-technology.html | 2 +- guidelines/terms/20/changes-of-context.html | 2 +- .../20/conforming-alternate-version.html | 2 +- guidelines/terms/20/content.html | 2 +- ...eneral-flash-and-red-flash-thresholds.html | 2 +- guidelines/terms/20/input-error.html | 2 +- guidelines/terms/20/label.html | 2 +- guidelines/terms/20/name.html | 2 +- guidelines/terms/20/process.html | 2 +- guidelines/terms/20/relative-luminance.html | 2 +- guidelines/terms/20/same-functionality.html | 4 +- guidelines/terms/20/set-of-web-pages.html | 6 +- guidelines/terms/20/structure.html | 4 +- guidelines/terms/20/supplemental-content.html | 2 +- guidelines/terms/20/technology.html | 10 +-- guidelines/terms/20/user-agent.html | 4 +- guidelines/terms/20/web-page.html | 12 +-- guidelines/terms/21/set-of-web-pages.html | 6 +- .../terms/22/cognitive-function-test.html | 2 +- guidelines/wcag.json | 84 +++++++++---------- 42 files changed, 139 insertions(+), 139 deletions(-) diff --git a/guidelines/index.html b/guidelines/index.html index 8402db4640..bab5f28f23 100644 --- a/guidelines/index.html +++ b/guidelines/index.html @@ -13,14 +13,14 @@
-

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 @@

Introduction

Background on WCAG 2

-

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:

WCAG 2 Layers of Guidance

-

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 @@

    WCAG 2 Layers of Guidance

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.

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:

  1. -

    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.

  2. 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 @@

    WCAG 2.2 Supporting Documents

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

Requirements for WCAG 2.2

@@ -336,7 +336,7 @@

Readable

Predictable

-

Make Web pages appear and operate in predictable ways.

+

Make web pages appear and operate in predictable ways.

@@ -408,35 +408,35 @@

Interpreting Normative Requirements

Conformance Requirements

-

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:

Conformance Level

One of the following levels of conformance is met in full.

    -
  • For Level A conformance (the minimum level of conformance), the Web page - satisfies all the Level A Success Criteria, or a conforming alternate version is provided.
    • -
  • For Level AA conformance, the Web page satisfies all the Level A and Level AA Success Criteria, or a Level AA conforming alternate version is provided.
    • -
  • For Level AAA conformance, the Web page satisfies all the Level A, Level AA and Level AAA Success Criteria, or a Level AAA conforming alternate version is provided.
    • +
  • For Level A conformance (the minimum level of conformance), the web page + satisfies all the Level A success criteria, or a conforming alternate version is provided.
    • +
  • For Level AA conformance, the web page satisfies all the Level A and Level AA success criteria, or a Level AA conforming alternate version is provided.
    • +
  • For Level AAA conformance, the web page satisfies all the Level A, Level AA and Level AAA success criteria, or a Level AAA conforming alternate version is provided.

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.

Full pages

-

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.

Complete processes

-

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

@@ -451,7 +451,7 @@

Only Accessibility-Supported Ways of Using Technologies

Non-Interference

-

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:

  1. when any technology that is not relied upon is turned on in a user agent,
  2. when any technology that is not relied upon is turned off in a user agent, and
    3. @@ -473,7 +473,7 @@

    Non-Interference

    Conformance Claims (Optional)

    -

    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.

    Required Components of a Conformance Claim

    @@ -483,12 +483,12 @@

    Required Components of a Conformance Claim

  3. Guidelines title, version and URI "Web Content Accessibility Guidelines 2.2 at https://www.w3.org/TR/WCAG22/"
  4. Conformance level satisfied: (Level A, AA or AAA)
  5. -

    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.

  6. A list of the - Web content technologies + web content technologies relied upon.

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 @@

Statement of Partial Conformance - Language

Privacy Considerations

-

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:

  • 2.2.6 Timeouts (AAA)
  • 3.3.7 Redundant Entry (A)
    • @@ -550,8 +550,8 @@

    Privacy Considerations

    Security Considerations

    -

    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:

    • 1.1.1 Non-text Content (A)
    • 1.3.5 Identify Input Purpose (AA)
      • diff --git a/guidelines/input-purposes.html b/guidelines/input-purposes.html index b83e94c842..639299361d 100644 --- a/guidelines/input-purposes.html +++ b/guidelines/input-purposes.html @@ -48,7 +48,7 @@

      Input Purposes for User Interface Components

    • bday-month - Month component of birthday
    • bday-year - Year component of birthday
    • sex - Gender identity (e.g., Female, Fa’afafine)
      • -
    • url - Home page or other Web page corresponding to the company, person, address, or contact information in the other fields associated with this field
      • +
    • url - Home page or other web page corresponding to the company, person, address, or contact information in the other fields associated with this field
    • photo - Photograph, icon, or other image corresponding to the company, person, address, or contact information in the other fields associated with this field
    • tel - Full telephone number, including country code
    • tel-country-code - Country code component of the telephone number
      • diff --git a/guidelines/relative-luminance.html b/guidelines/relative-luminance.html index ed65eb01df..e7b8cbc55d 100644 --- a/guidelines/relative-luminance.html +++ b/guidelines/relative-luminance.html @@ -340,7 +340,7 @@

      MathML version of the relative luminance definition

      Note

      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.

      -
      Note

      Almost all systems used today to view Web content assume sRGB encoding. Unless it +

      Note

      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.

      diff --git a/guidelines/sc/20/audio-control.html b/guidelines/sc/20/audio-control.html index aaccda2077..d9888df920 100644 --- a/guidelines/sc/20/audio-control.html +++ b/guidelines/sc/20/audio-control.html @@ -4,12 +4,12 @@

      Audio Control

      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 @@

      Bypass Blocks

      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 @@

    Consistent Identification

    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 @@

Consistent Navigation

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 @@

Error Prevention (All)

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:

diff --git a/guidelines/sc/20/error-prevention-legal-financial-data.html b/guidelines/sc/20/error-prevention-legal-financial-data.html index 0059cff558..ab41f3cc56 100644 --- a/guidelines/sc/20/error-prevention-legal-financial-data.html +++ b/guidelines/sc/20/error-prevention-legal-financial-data.html @@ -4,7 +4,7 @@

Error Prevention (Legal, Financial, Data)

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 @@

Focus Order

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 @@

Language of Page

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 @@

Location

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 @@

Multiple Ways

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 @@

Name, Role, Value

the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

-

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 @@

No Keyboard Trap

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 @@

Pause, Stop, Hide

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 @@

Three Flashes or Below Threshold

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 @@

Accessible Authentication (Minimum)

Object Recognition
The cognitive function test is to recognize objects.
Personal Content
-
The cognitive function test is to identify non-text content the user provided to the Web site.
+
The cognitive function test is to identify non-text content the user provided to the website.

"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 @@

Consistent Help

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:

  • Human contact details;
    • @@ -15,7 +15,7 @@

    Consistent Help

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 @@

Focus Not Obscured (Minimum)

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:

    @@ -79,7 +79,7 @@

    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".)

    @@ -87,21 +87,21 @@ as they are not relied upon and the page as a whole meets the conformance requirements, including Conformance Requirement 4 and Conformance Requirement 5.

    -

    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 @@
    ambiguous to users in general
    -

    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 @@
  • focus;
    • -
  • content that changes the meaning of the Web page +
  • content that changes the meaning of the web page
    • diff --git a/guidelines/terms/20/conforming-alternate-version.html b/guidelines/terms/20/conforming-alternate-version.html index 77faa0f4f3..dd597a83fe 100644 --- a/guidelines/terms/20/conforming-alternate-version.html +++ b/guidelines/terms/20/conforming-alternate-version.html @@ -52,7 +52,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 @@ -
    content (Web content) +
    content (web content)
    diff --git a/guidelines/terms/20/general-flash-and-red-flash-thresholds.html b/guidelines/terms/20/general-flash-and-red-flash-thresholds.html index 19048801f6..2f4b75cd9d 100644 --- a/guidelines/terms/20/general-flash-and-red-flash-thresholds.html +++ b/guidelines/terms/20/general-flash-and-red-flash-thresholds.html @@ -35,7 +35,7 @@ viewing distance) on a side does not violate 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. +

    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 @@

      -
    1. Information that is required by the Web page but omitted by the user +
    2. Information that is required by the web page but omitted by the user
    3. Information that is provided by the user but that falls outside the required data diff --git a/guidelines/terms/20/label.html b/guidelines/terms/20/label.html index b8624b4ae2..67b3eb0970 100644 --- a/guidelines/terms/20/label.html +++ b/guidelines/terms/20/label.html @@ -1,7 +1,7 @@
      label
      -

      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 @@

      name
      -

      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

      -
    diff --git a/_includes/techniques/changelog/22.html b/_includes/techniques/changelog/22.html new file mode 100644 index 0000000000..3323b54657 --- /dev/null +++ b/_includes/techniques/changelog/22.html @@ -0,0 +1,35 @@ +
      +
    1. : Removed F87 Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using :before and :after pseudo-elements and the 'content' property in CSS
      2. +
    2. : Removed Flash techniques.
      3. +
    3. : Added {{ "F105" | linkTechniques }}
      4. +
    4. : Added {{ "F106" | linkTechniques }}
      5. +
    5. : Added {{ "F104" | linkTechniques }}
      6. +
    6. : Added {{ "F103" | linkTechniques }}
      7. +
    7. : Added {{ "F102" | linkTechniques }}
      8. +
    8. : Added {{ "G216" | linkTechniques }}
      9. +
    9. : Added {{ "G215" | linkTechniques }}
      10. +
    10. : Added {{ "F100" | linkTechniques }}
      11. +
    11. : Added {{ "G214" | linkTechniques }}
      12. +
    12. : Added {{ "C40" | linkTechniques }}
      13. +
    13. : Added {{ "F99" | linkTechniques }}
      14. +
    14. : Added {{ "SCR39" | linkTechniques }}
      15. +
    15. : Added {{ "G212" | linkTechniques }}
      16. +
    16. : Added {{ "F98" | linkTechniques }}
      17. +
    17. : Added {{ "G213" | linkTechniques }}
      18. +
    18. : Added {{ "ARIA24" | linkTechniques }}
      19. +
    19. : Added {{ "F97" | linkTechniques }}
      20. +
    20. : Removed {{ "F52" | linkTechniques }} from SC 3.2.1 (still attached to SC 3.2.5)
      21. +
    21. : Added {{ "G209" | linkTechniques }}
      22. +
    22. : Added {{ "C39" | linkTechniques }}
      23. +
    23. : Added {{ "G207" | linkTechniques }}
      24. +
    24. : Added {{ "C38" | linkTechniques }}
      25. +
    25. : Added {{ "F95" | linkTechniques }}
      26. +
    26. : Added {{ "C34" | linkTechniques }}
      27. +
    27. : Added {{ "C36" | linkTechniques }}
      28. +
    28. : Added {{ "C37" | linkTechniques }}
      29. +
    29. : Added {{ "G207" | linkTechniques }}
      30. +
    30. : Added {{ "F95" | linkTechniques }}
      31. +
    31. : Added {{ "F96" | linkTechniques }}
      32. +
    32. : Added {{ "C38" | linkTechniques }}
      33. +
    33. : Added {{ "G207" | linkTechniques }}
      34. +
    diff --git a/_includes/wai-site-footer.html b/_includes/wai-site-footer.html index fe7fabd0f1..9082c568b7 100644 --- a/_includes/wai-site-footer.html +++ b/_includes/wai-site-footer.html @@ -3,7 +3,8 @@

    Date: Updated {{ page.date | date_to_long_string }}.

    Developed by Accessibility Guidelines Working Group (AG WG) Participants - (Co-Chairs: Alastair Campbell, Charles Adams, Rachael Bradley Montgomery. W3C Staff Contact: Kevin White). + (Co-Chairs: Alastair Campbell, Charles Adams, Rachael Bradley Montgomery. W3C Staff Contact: + {% if version >= 22 -%} Kevin White {%- else -%} Michael Cooper {%- endif %}).

    The content was developed as part of the WAI-Core projects funded by U.S. Federal funds. diff --git a/acknowledgements/ag-contributors.html b/acknowledgements/ag-contributors.html index 4d1a2542cd..f3f57fcce5 100644 --- a/acknowledgements/ag-contributors.html +++ b/acknowledgements/ag-contributors.html @@ -1,4 +1,4 @@

    -

    Other previously active WCAG WG participants and other contributors to WCAG 2.0, WCAG 2.1, or supporting resources

    +

    Other previously active WCAG WG participants and other contributors to WCAG 2.0, WCAG 2.1, or supporting resources

    Paul Adam, Jenae Andershonis, Wilhelm Joys Andersen, Andrew Arch, Avi Arditti, Aries Arditi, Tom Babinszki, Mark Barratt, Mike Barta, Sandy Bartell, Kynn Bartlett, Chris Beer, Charles Belov, Marco Bertoni, Harvey Bingham, Chris Blouch, Paul Bohman, Frederick Boland, Denis Boudreau, Patrice Bourlon, Andy Brown, Dick Brown, Doyle Burnett, Raven Calais, Ben Caldwell, Tomas Caspers, Roberto Castaldo, Sofia Celic-Li, Sambhavi Chandrashekar, Mike Cherim, Jonathan Chetwynd, Wendy Chisholm, Alan Chuter, David M Clark, Joe Clark, Darcy Clarke, James Coltham, Earl Cousins, James Craig, Tom Croucher, Pierce Crowell, Nir Dagan, Daniel Dardailler, Geoff Deering, Sébastien Delorme, Pete DeVasto, Iyad Abu Doush, Sylvie Duchateau, Cherie Eckholm, Roberto Ellero, Don Evans, Gavin Evans, Neal Ewers, Steve Faulkner, Bengt Farre, Lainey Feingold, Wilco Fiers, Michel Fitos, Alan J. Flavell, Nikolaos Floratos, Kentarou Fukuda, Miguel Garcia, P.J. Gardner, Alistair Garrison, Greg Gay, Becky Gibson, Al Gilman, Kerstin Goldsmith, Michael Grade, Karl Groves, Loretta Guarino Reid, Jon Gunderson, Emmanuelle Gutiérrez y Restrepo, Brian Hardy, Eric Hansen, Benjamin Hawkes-Lewis, Sean Hayes, Shawn Henry, Hans Hillen, Donovan Hipke, Bjoern Hoehrmann, Allen Hoffman, Chris Hofstader, Yvette Hoitink, Martijn Houtepen, Carlos Iglesias, Richard Ishida, Jonas Jacek, Ian Jacobs, Phill Jenkins, Barry Johnson, Duff Johnson, Jyotsna Kaki, Shilpi Kapoor, Leonard R. Kasday, Kazuhito Kidachi, Ken Kipness, Johannes Koch, Marja-Riitta Koivunen, Maureen Kraft, Preety Kumar, Kristjan Kure, Andrew LaHart, Gez Lemon, Chuck Letourneau, Aurélien Levy, Harry Loots, Scott Luebking, Tim Lacy, Jim Ley, Alex Li, William Loughborough, N Maffeo, Mark Magennis, Erich Manser, Kapsi Maria, Luca Mascaro, Matt May, Sheena McCullagh, Liam McGee, Jens Oliver Meiert, Niqui Merret, Jonathan Metz, Alessandro Miele, Steven Miller, Mathew J Mirabella, Matt May, Marti McCuller, Sorcha Moore, Charles F. Munat, Robert Neff, Charles Nevile, Liddy Nevile, Dylan Nicholson, Bruno von Niman, Tim Noonan, Sebastiano Nutarelli, Graham Oliver, Sean B. Palmer, Charu Pandhi, evarshi Pant, Nigel Peck, Anne Pemberton, David Poehlman, Ian Pouncey, Charles Pritchard, Kerstin Probiesch, W Reagan, Adam Victor Reed, Chris Reeve, Chris Ridpath, Lee Roberts, Mark Rogers, Raph de Rooij, Gregory J. Rosmaita, Matthew Ross, Sharron Rush, Joel Sanda, Janina Sajka, Roberto Scano, Gordon Schantz, Tim van Schie, Wolf Schmidt, Stefan Schnabel, Cynthia Shelly, Glenda Sims, John Slatin, Becky Smith, Jared Smith, Andi Snow-Weaver, Neil Soiffer, Mike Squillace, Michael Stenitzer, Diane Stottlemyer, Christophe Strobbe, Sarah J Swierenga, Jim Thatcher, Terry Thompson, Justin Thorp, David Todd, Mary Utt, Jean Vanderdonckt, Carlos A Velasco, Eric Velleman, Gijs Veyfeyken, Dena Wainwright, Paul Walsch, Daman Wandke, Richard Warren, Elle Waters, Takayuki Watanabe, Gian Wild, David Wooley, Wu Wei, Kenny Zhang, Leona Zumbo.

    -
    \ No newline at end of file + diff --git a/acknowledgements/ag-wg-active.html b/acknowledgements/ag-wg-active.html index 19cc2fd7ea..5fe6963c27 100644 --- a/acknowledgements/ag-wg-active.html +++ b/acknowledgements/ag-wg-active.html @@ -1,5 +1,5 @@
    -

    Participants of the AG WG active in the development of this document:

    +

    Participants of the AG WG active in the development of this document:

    Techniques

    -

    Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.

    Sufficient

    diff --git a/understanding/index.html b/understanding/index.html index 163d088a0f..7e0b1fe689 100644 --- a/understanding/index.html +++ b/understanding/index.html @@ -4,7 +4,7 @@ - Understanding WCAG 2.2 | WAI | W3C + Understanding WCAG {{ versionDecimal }} | WAI | W3C @@ -29,7 +29,7 @@
    -

    All WCAG 2.2 Understanding Docs

    +

    All WCAG {{ versionDecimal }} Understanding Docs

    • If any of these are not true, users with disabilities will not be able to use the Web.

    -

    Under each of the principles are guidelines and success criteria that help to address these principles for people with disabilities. There are many general usability guidelines that make content more usable by all people, including those with disabilities. However, in WCAG 2, we only include those guidelines that address problems particular to people with disabilities. This includes issues that block access or interfere with access to the Web more severely for people with disabilities.

    +

    Under each of the principles are guidelines and success criteria that help to address these principles for people with disabilities. There are many general usability guidelines that make content more usable by all people, including those with disabilities. However, in WCAG {{ versionDecimal }}, we only include those guidelines that address problems particular to people with disabilities. This includes issues that block access or interfere with access to the Web more severely for people with disabilities.

    Layers of Guidance

    The Guidelines

    -

    Under each principle there is a list of guidelines that address the principle. There are a total of 13 guidelines. A convenient list of just the guidelines can be found in the WCAG 2 table of contents. One of the key objectives of the guidelines is to ensure that content is directly accessible to as many people as possible, and capable of being re-presented in different forms to match different peoples' sensory, physical and cognitive abilities.

    +

    Under each principle there is a list of guidelines that address the principle. There are a total of 13 guidelines. A convenient list of just the guidelines can be found in the WCAG {{ versionDecimal }} table of contents. One of the key objectives of the guidelines is to ensure that content is directly accessible to as many people as possible, and capable of being re-presented in different forms to match different peoples' sensory, physical and cognitive abilities.

    Success Criteria

    Under each guideline, there are success criteria that describe specifically what must be achieved in order to conform to this standard. They are similar to the "checkpoints" in WCAG 1.0. Each success criterion is written as a statement that will be either true or false when specific Web content is tested against it. The success criteria are written to be technology neutral.

    -

    All WCAG 2 success criteria are written as testable criteria for objectively determining if content satisfies the success criteria. While some of the testing can be automated using software evaluation programs, others require human testers for part or all of the test.

    +

    All WCAG {{ versionDecimal }} success criteria are written as testable criteria for objectively determining if content satisfies the success criteria. While some of the testing can be automated using software evaluation programs, others require human testers for part or all of the test.

    Although content may satisfy the success criteria, the content may not always be usable by people with a wide variety of disabilities. Professional reviews utilizing recognized qualitative heuristics are important in achieving accessibility for some audiences. In addition, usability testing is recommended. Usability testing aims to determine how well people can use the content for its intended purpose.

    The content should be tested by those who understand how people with different types of disabilities use the Web. It is recommended that users with disabilities be included in test groups when performing human testing.

    Each success criterion for a guideline has a link to the section of the How to Meet document that provides:

    diff --git a/understanding/refer-to-wcag.html b/understanding/refer-to-wcag.html index 22b4450799..31f561342d 100644 --- a/understanding/refer-to-wcag.html +++ b/understanding/refer-to-wcag.html @@ -1,61 +1,61 @@ - How to refer to WCAG 2 from other documents + How to refer to WCAG {{ versionDecimal }} from other documents -

    How to refer to WCAG 2 from other documents

    -

    The following examples show how to reference WCAG 2 in various situations. For additional guidance, see Referencing and Linking to WAI Guidelines and Technical Documents.

    -

    Please note that the following language for referencing WCAG 2 can be inserted into your own documents.

    +

    How to refer to WCAG {{ versionDecimal }} from other documents

    +

    The following examples show how to reference WCAG {{ versionDecimal }} in various situations. For additional guidance, see Referencing and Linking to WAI Guidelines and Technical Documents.

    +

    Please note that the following language for referencing WCAG {{ versionDecimal }} can be inserted into your own documents.

    Information references

    -

    When referencing WCAG 2 in an informational fashion, the following format can be used.

    -

    Web Content Accessibility Guidelines 2.2, W3C World Wide Web Consortium Recommendation XX Month Year (https://www.w3.org/TR/YYYY/REC-WCAG22-YYYYMMDD/, Latest version at https://www.w3.org/TR/WCAG22/)

    +

    When referencing WCAG {{ versionDecimal }} in an informational fashion, the following format can be used.

    +

    Web Content Accessibility Guidelines {{ versionDecimal }}, W3C World Wide Web Consortium Recommendation XX Month Year (https://www.w3.org/TR/YYYY/REC-WCAG{{ version }}-YYYYMMDD/, Latest version at https://www.w3.org/TR/WCAG{{ version }}/)

    -

    When referring to WCAG 2 from another standard with a "should" statement

    -

    When referencing WCAG 2 from within a should statement in a standard (or advisory statement in a regulation), then the full WCAG 2 should be referenced. This would mean that all three levels of WCAG 2 should be considered but that none are required. The format for referencing WCAG 2 from a "should" statement therefore, is:

    -

    Web Content Accessibility Guidelines 2.2, W3C World Wide Web Consortium Recommendation XX Month Year. (https://www.w3.org/TR/YYYY/REC-WCAG22-YYYYMMDD/)

    +

    When referring to WCAG {{ versionDecimal }} from another standard with a "should" statement

    +

    When referencing WCAG {{ versionDecimal }} from within a should statement in a standard (or advisory statement in a regulation), then the full WCAG {{ versionDecimal }} should be referenced. This would mean that all three levels of WCAG {{ versionDecimal }} should be considered but that none are required. The format for referencing WCAG {{ versionDecimal }} from a "should" statement therefore, is:

    +

    Web Content Accessibility Guidelines {{ versionDecimal }}, W3C World Wide Web Consortium Recommendation XX Month Year. (https://www.w3.org/TR/YYYY/REC-WCAG{{ version }}-YYYYMMDD/)

    -

    When referring to WCAG 2 from another standard with a "shall or must" statement

    -

    When citing WCAG 2 as part of a requirement (e.g., a shall or must statement in a standard or regulation), the reference must include the specific parts of WCAG 2 that are intended to be required. When referencing WCAG 2 in this manner, the following rules apply:

    +

    When referring to WCAG {{ versionDecimal }} from another standard with a "shall or must" statement

    +

    When citing WCAG {{ versionDecimal }} as part of a requirement (e.g., a shall or must statement in a standard or regulation), the reference must include the specific parts of WCAG {{ versionDecimal }} that are intended to be required. When referencing WCAG {{ versionDecimal }} in this manner, the following rules apply:

    1. -

      Conformance at any level of WCAG 2 requires that all of the Level A success criteria be met. References to WCAG 2 conformance cannot be for any subset of Level A.

      +

      Conformance at any level of WCAG {{ versionDecimal }} requires that all of the Level A success criteria be met. References to WCAG {{ versionDecimal }} conformance cannot be for any subset of Level A.

    2. Beyond Level A, a "shall or must" reference may include any subset of provisions in Levels AA and AAA. For example, "all of Level A and [some specific list of success criteria in Level AA and Level AAA]" be met.

    3. -

      If Level AA conformance to WCAG 2 is specified, then all Level A and all Level AA success criteria must be met.

      +

      If Level AA conformance to WCAG {{ versionDecimal }} is specified, then all Level A and all Level AA success criteria must be met.

    4. -

      If Level AAA conformance to WCAG 2 is specified, then all Level A, all Level AA, and all Level AAA success criteria must be met.

      +

      If Level AAA conformance to WCAG {{ versionDecimal }} is specified, then all Level A, all Level AA, and all Level AAA success criteria must be met.

      Note 1: It is not recommended that Level AAA conformance ever be required for entire sites as a general policy because it is not possible to satisfy all Level AAA success criteria for some content.

      -

      Note 2: The sets of success criteria defined in WCAG 2 are interdependent and individual success criteria rely on each other's definitions in ways which may not be immediately obvious to the reader. Any set of success criteria must include all of the Level A provisions.

      +

      Note 2: The sets of success criteria defined in WCAG {{ versionDecimal }} are interdependent and individual success criteria rely on each other's definitions in ways which may not be immediately obvious to the reader. Any set of success criteria must include all of the Level A provisions.

    Examples

    To cite only the Level A Success Criteria (Single-A conformance):

    -

    Web Content Accessibility Guidelines 2.2, W3C World Wide Web Consortium Recommendation XX Month Year, Level A Success Criteria. (https://www.w3.org/TR/YYYY/REC-WCAG22-YYYYMMDD/)

    +

    Web Content Accessibility Guidelines {{ versionDecimal }}, W3C World Wide Web Consortium Recommendation XX Month Year, Level A Success Criteria. (https://www.w3.org/TR/YYYY/REC-WCAG{{ version }}-YYYYMMDD/)

    To cite the Levels A and AA Success Criteria (Double-A conformance):

    -

    Web Content Accessibility Guidelines 2.2, W3C World Wide Web Consortium Recommendation XX Month Year, Level A & Level AA Success Criteria. (https://www.w3.org/TR/YYYY/REC-WCAG22-YYYYMMDD/)

    +

    Web Content Accessibility Guidelines {{ versionDecimal }}, W3C World Wide Web Consortium Recommendation XX Month Year, Level A & Level AA Success Criteria. (https://www.w3.org/TR/YYYY/REC-WCAG{{ version }}-YYYYMMDD/)

    To cite Level A Success Criteria and selected Success Criteria from Level AA and Level AAA:

    -

    Web Content Accessibility Guidelines 2.2, W3C World Wide Web Consortium Recommendation XX Month Year, Level A Success Criteria plus Success Criteria 1.x.x, 2.y.y, … 3.z.z. (https://www.w3.org/TR/YYYY/REC-WCAG22-YYYYMMDD/)

    -

    Example of use of a WCAG 2 reference in a "shall or must" statement.

    -

    All Web content on publicly available Web sites shall conform to Web Content Accessibility Guidelines 2.2, W3C World Wide Web Consortium Recommendation XX Month Year, Level A Success Criteria plus Success Criteria 1.2.3, 2.4.5-6, 3.1.2 (https://www.w3.org/TR/YYYY/REC-WCAG22-YYYYMMDD/)

    +

    Web Content Accessibility Guidelines {{ versionDecimal }}, W3C World Wide Web Consortium Recommendation XX Month Year, Level A Success Criteria plus Success Criteria 1.x.x, 2.y.y, … 3.z.z. (https://www.w3.org/TR/YYYY/REC-WCAG{{ version }}-YYYYMMDD/)

    +

    Example of use of a WCAG {{ versionDecimal }} reference in a "shall or must" statement.

    +

    All Web content on publicly available Web sites shall conform to Web Content Accessibility Guidelines {{ versionDecimal }}, W3C World Wide Web Consortium Recommendation XX Month Year, Level A Success Criteria plus Success Criteria 1.2.3, 2.4.5-6, 3.1.2 (https://www.w3.org/TR/YYYY/REC-WCAG{{ version }}-YYYYMMDD/)

    -

    Referring to content from WCAG 2 support documents

    -

    Techniques, which are listed in Understanding WCAG 2 and described in other supporting documents, are not part of the normative WCAG 2 Recommendation and should not be cited using the citation for the WCAG 2 Recommendation itself. References to techniques in support documents should be cited separately.

    -

    Techniques can be cited based on the individual Technique document or on the master WCAG 2 Techniques document. For example, the technique "Using alt attributes on img elements" could be cited as

    +

    Referring to content from WCAG {{ versionDecimal }} support documents

    +

    Techniques, which are listed in Understanding WCAG {{ versionDecimal }} and described in other supporting documents, are not part of the normative WCAG {{ versionDecimal }} Recommendation and should not be cited using the citation for the WCAG {{ versionDecimal }} Recommendation itself. References to techniques in support documents should be cited separately.

    +

    Techniques can be cited based on the individual Technique document or on the master WCAG {{ versionDecimal }} Techniques document. For example, the technique "Using alt attributes on img elements" could be cited as

    "Using alt attributes on img elements," W3C World Wide Web Consortium Note. (URI: {URI of technique})

    or

    -

    W3C World Wide Web Consortium (20xx): WCAG2.2 HTML Techniques (URI: {URI of HTML Techniques})

    -

    Techniques are not designed to be referenced as "required" from any standard or regulation.Standards and regulations should not make any specific technique mandatory, though they may choose to recommend techniques.

    +

    W3C World Wide Web Consortium (20xx): WCAG{{ versionDecimal }} HTML Techniques (URI: {URI of HTML Techniques})

    +

    Techniques are not designed to be referenced as "required" from any standard or regulation. Standards and regulations should not make any specific technique mandatory, though they may choose to recommend techniques.

    diff --git a/understanding/understanding-techniques.html b/understanding/understanding-techniques.html index be18332fc6..c4b3322563 100644 --- a/understanding/understanding-techniques.html +++ b/understanding/understanding-techniques.html @@ -1,13 +1,13 @@ - Understanding Techniques for WCAG 2 Success Criteria + Understanding Techniques for WCAG {{ versionDecimal }} Success Criteria -

    Understanding Techniques for WCAG 2 Success Criteria

    -

    WCAG 2 guidelines and success criteria are designed to be broadly applicable to current and future web technologies, including dynamic applications, mobile, digital television, etc. They are stable and do not change.

    -

    Specific guidance for authors and evaluators on meeting the WCAG 2 success criteria is provided in techniques, which include code examples, resources, and tests. W3C's Techniques for WCAG 2 document is updated periodically, about twice per year, to cover more current best practices and changes in technologies and tools.

    -

    The three types of guidance in Techniques for WCAG 2 are explained below:

    +

    Understanding Techniques for WCAG {{ versionDecimal }} Success Criteria

    +

    WCAG {{ versionDecimal }} guidelines and success criteria are designed to be broadly applicable to current and future web technologies, including dynamic applications, mobile, digital television, etc. They are stable and do not change.

    +

    Specific guidance for authors and evaluators on meeting the WCAG {{ versionDecimal }} success criteria is provided in techniques, which include code examples, resources, and tests. W3C's Techniques for WCAG {{ versionDecimal }} document is updated periodically, about twice per year, to cover more current best practices and changes in technologies and tools.

    +

    The three types of guidance in Techniques for WCAG {{ versionDecimal }} are explained below:

    • Sufficient techniques
    • Advisory techniques
      • @@ -24,14 +24,14 @@

      Understanding Techniques for WCAG 2 Success Criteria

      Understanding Conformance provides related information, including on understanding accessibility support.

      Techniques are Informative

      -

      Techniques are informative — that means they are not required. The basis for determining conformance to WCAG 2 are the success criteria from the WCAG 2 standard — not the techniques.

      -

      Note 1: W3C cautions against requiring W3C's sufficient techniques. The only thing that should be required is meeting the WCAG 2 success criteria. To learn more, see:

      +

      Techniques are informative — that means they are not required. The basis for determining conformance to WCAG {{ versionDecimal }} are the success criteria from the WCAG {{ versionDecimal }} standard — not the techniques.

      +

      Note 1: W3C cautions against requiring W3C's sufficient techniques. The only thing that should be required is meeting the WCAG {{ versionDecimal }} success criteria. To learn more, see:

      -

      Note 2: Techniques for WCAG 2 uses the words "must" and "should" only to clarify guidance within the techniques, not to convey requirements for WCAG 2.

      +

      Note 2: Techniques for WCAG {{ versionDecimal }} uses the words "must" and "should" only to clarify guidance within the techniques, not to convey requirements for WCAG {{ versionDecimal }}.

      Sufficient Techniques

      @@ -44,7 +44,7 @@

      Sufficient Techniques

      From an evaluator's perspective: If web content implements the sufficient techniques for a given criterion correctly and it is accessibility-supported for the content's users, it conforms to that success criterion. (The converse is not true; if content does not implement these sufficient techniques, it does not necessarily fail the success criteria, as explained in Testing Techniques below.)

    -

    There may be other ways to meet success criteria besides the sufficient techniques in W3C's Techniques for WCAG 2 document, as explained in Other Techniques below. (See also Techniques are Informative above.)

    +

    There may be other ways to meet success criteria besides the sufficient techniques in W3C's Techniques for WCAG {{ versionDecimal }} document, as explained in Other Techniques below. (See also Techniques are Informative above.)

    Numbered Lists, "AND"

    The W3C-documented sufficient techniques are provided in a numbered list where each list item provides a technique or combination of techniques that can be used to meet the success criterion. Where there are multiple techniques on a numbered list item connected by "AND" then all of the techniques must be used to be sufficient. For example, Sufficient Techniques for 1.3.1 has: "G115: Using semantic elements to mark up structure AND H49: Using semantic markup to mark emphasized or special text (HTML)".

    @@ -72,35 +72,35 @@

    Failures

    Authors to know what to avoid,

  • -

    Evaluators to use for checking if content does not meet WCAG 2 success criteria.

    +

    Evaluators to use for checking if content does not meet WCAG {{ versionDecimal }} success criteria.

    • -

    Content that has a failure does not meet WCAG 2 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 alternate 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.

    General and Technology-specific Techniques

    General techniques describe basic practices that apply to all technologies. Technology-specific techniques apply to a specific technology.

    Some success criteria do not have technology-specific techniques and are covered only with general techniques. Therefore, both the general techniques and the relevant technology-specific techniques should be considered.

    -

    Publication of techniques for a specific technology does not imply that the technology can be used in all situations to create content that meets WCAG 2 success criteria and conformance requirements. Developers need to be aware of the limitations of specific technologies and provide content in a way that is accessible to people with disabilities.

    +

    Publication of techniques for a specific technology does not imply that the technology can be used in all situations to create content that meets WCAG {{ versionDecimal }} success criteria and conformance requirements. Developers need to be aware of the limitations of specific technologies and provide content in a way that is accessible to people with disabilities.

    Other Techniques

    -

    In addition to the techniques in W3C's Techniques for WCAG 2 document, there are other ways to meet WCAG 2 success criteria. W3C's techniques are not comprehensive and may not cover newer technologies and situations.

    -

    Web content does not have to use W3C's published techniques in order to conform to WCAG 2. (See also Techniques are Informative above.)

    -

    Content authors can develop different techniques. For example, an author could develop a technique for HTML5, WAI-ARIA, or other new technology. Other organizations may develop sets of techniques to meet WCAG 2 success criteria.

    +

    In addition to the techniques in W3C's Techniques for WCAG {{ versionDecimal }} document, there are other ways to meet WCAG {{ versionDecimal }} success criteria. W3C's techniques are not comprehensive and may not cover newer technologies and situations.

    +

    Web content does not have to use W3C's published techniques in order to conform to WCAG {{ versionDecimal }}. (See also Techniques are Informative above.)

    +

    Content authors can develop different techniques. For example, an author could develop a technique for HTML5, WAI-ARIA, or other new technology. Other organizations may develop sets of techniques to meet WCAG {{ versionDecimal }} success criteria.

    Any techniques can be sufficient if:

    Submitting Techniques

    -

    The WCAG Working Group encourages people to submit new techniques so that they can be considered for inclusion in updates of the Techniques for WCAG 2 document. Please submit techniques for consideration to the WCAG repository on GitHub.

    +

    The WCAG Working Group encourages people to submit new techniques so that they can be considered for inclusion in updates of the Techniques for WCAG {{ versionDecimal }} document. Please submit techniques for consideration to the WCAG repository on GitHub.

    @@ -138,10 +138,10 @@

    Support Notes Change Over Time

    Using the Techniques

    -

    Techniques for WCAG 2 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 2.2: 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.

    +

    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, G73: Providing a long description in another location... 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 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.

    Example Code