diff --git a/.eleventyignore b/.eleventyignore
new file mode 100644
index 0000000000..752acaedf1
--- /dev/null
+++ b/.eleventyignore
@@ -0,0 +1,25 @@
+*.md
+11ty/
+acknowledgements.html
+acknowledgements/
+conformance-challenges/
+guidelines/
+lib/
+requirements/
+script/
+wcag20/
+# working-examples is directly copied; it should not be processed as templates
+working-examples/
+xslt/
+
+# These files under understanding don't end up in output in the old build
+understanding/*/accessibility-support-documenting.html
+understanding/*/identify-changes.html
+understanding/*/interruptions-minimum.html
+understanding/*/seizures.html
+
+# Ignore templates used for creating new documents
+**/*-template.html
+
+# HTML files under img will be passthrough-copied
+**/img/*
diff --git a/.github/scripts/deploy.sh b/.github/scripts/deploy.sh
deleted file mode 100755
index 05e06b0bc3..0000000000
--- a/.github/scripts/deploy.sh
+++ /dev/null
@@ -1,28 +0,0 @@
-#!/bin/bash
-set -exu
-# e: Exit immediately if a command exits with a non-zero status
-# x: Print commands and their arguments as they are executed
-# u: Treat unset variables as an error when substituting
-
-# NOTE: you probably need to add 'w3cbot' to the list of authorized users to push to your repository
-git config --global user.email 87540780+w3cgruntbot@users.noreply.github.com
-git config --global user.name w3cgruntbot
-git config --global user.password $GITHUB_TOKEN
-
-REPO_URL="https://w3cbot:$GITHUB_TOKEN@github.com/$GITHUB_REPOSITORY.git"
-
-cd ${LOCAL_DIR}
-
-git remote set-url origin "${REPO_URL}"
-
-if [[ -z $(git status --porcelain) ]]; then
- echo "No changes to the output on this push; exiting."
- exit 0
-fi
-
-git add -A .
-git commit -m ":robot: Deploy to GitHub Pages: $GITHUB_SHA from branch $GITHUB_REF"
-
-git push $REPO_URL $BRANCH
-
-echo done
\ No newline at end of file
diff --git a/.github/workflows/11ty-publish.yaml b/.github/workflows/11ty-publish.yaml
new file mode 100644
index 0000000000..fd2ec74e6b
--- /dev/null
+++ b/.github/workflows/11ty-publish.yaml
@@ -0,0 +1,45 @@
+name: Push to gh-pages branch
+
+# Reference documentation: https://docs.github.com/en/actions/reference
+
+# See https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestbranchestags
+on:
+ push:
+ branches: [main]
+
+jobs:
+ main:
+ name: deploy (11ty)
+ runs-on: ubuntu-20.04
+ steps:
+ - name: Checkout the repository
+ uses: actions/checkout@v4
+ - name: Checkout gh-pages
+ uses: actions/checkout@v4
+ with:
+ ref: gh-pages
+ path: _site
+ token: ${{ secrets.W3CGRUNTBOT_TOKEN }}
+ - name: Install Node.js and dependencies
+ uses: actions/setup-node@v4
+ with:
+ cache: npm
+ node-version-file: '.nvmrc'
+ - name: Build
+ env:
+ WCAG_MODE: editors
+ run: |
+ npm i
+ npm run build
+ cp guidelines/guidelines.css guidelines/relative-luminance.html _site/guidelines/22
+ curl https://labs.w3.org/spec-generator/?type=respec"&"url=https://raw.githack.com/$GITHUB_REPOSITORY/main/guidelines/index.html -o _site/guidelines/22/index.html -f --retry 3
+ curl https://labs.w3.org/spec-generator/?type=respec"&"url=https://raw.githack.com/$GITHUB_REPOSITORY/main/requirements/22/index.html -o _site/requirements/22/index.html -f --retry 3
+ curl https://labs.w3.org/spec-generator/?type=respec"&"url=https://raw.githack.com/$GITHUB_REPOSITORY/main/conformance-challenges/index.html -o _site/conformance-challenges/index.html -f --retry 3
+ - name: Push
+ working-directory: _site
+ run: |
+ git config user.email 87540780+w3cgruntbot@users.noreply.github.com
+ git config user.name w3cgruntbot
+ git add -A .
+ git commit -m ":robot: Deploy to GitHub Pages: $GITHUB_SHA from branch $GITHUB_REF"
+ git push origin gh-pages
diff --git a/.github/workflows/manual-publish.yml b/.github/workflows/manual-publish.yml
deleted file mode 100644
index f5eadf897c..0000000000
--- a/.github/workflows/manual-publish.yml
+++ /dev/null
@@ -1,44 +0,0 @@
-name: CI
-
-# Reference documentation: https://docs.github.com/en/actions/reference
-
-# See https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestbranchestags
-on:
- push:
- branches: [main]
-
-jobs:
- main:
- name: deploy to
- runs-on: ubuntu-20.04
- env:
- GH_REF: github.com/w3c/wcag.git
- steps:
- - name: Checkout the repository
- uses: actions/checkout@v2
- - name: Setup Java
- # see https://github.com/actions/setup-java#supported-distributions
- # note that this also deploys ant
- uses: actions/setup-java@v2
- with:
- distribution: 'adopt'
- java-version: '11'
- - name: before_install
- run: |
- tar -xzvf lib/apache-ant-1.10.6-bin.tar.gz
- export PATH=`pwd`/apache-ant-1.10.6/bin:$PATH
- - name: script
- run: |
- mkdir output
- git clone --depth=1 --branch=gh-pages https://github.com/w3c/wcag.git output
- curl https://labs.w3.org/spec-generator/?type=respec"&"url=https://raw.githack.com/w3c/wcag/main/guidelines/index.html -o output/guidelines/22/index.html -f --retry 3
- curl https://labs.w3.org/spec-generator/?type=respec"&"url=https://raw.githack.com/w3c/wcag/main/requirements/22/index.html -o output/requirements/22/index.html -f --retry 3
- curl https://labs.w3.org/spec-generator/?type=respec"&"url=https://raw.githack.com/w3c/wcag/main/conformance-challenges/index.html -o output/conformance-challenges/index.html -f --retry 3
- ant deploy
- - name: deploy
- run: .github/scripts/deploy.sh
- env:
- BRANCH: gh-pages
- LOCAL_DIR: output
- GITHUB_TOKEN: ${{ secrets.W3CGRUNTBOT_TOKEN }}
-
diff --git a/.gitignore b/.gitignore
index 26d41dc54a..598250a1d5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -221,6 +221,12 @@ pip-log.txt
build.properties
+#######
+## Node
+#######
+
+node_modules/
+
#############
## Output
#############
@@ -238,3 +244,4 @@ build.properties
/guidelines/wcag.xml
/guidelines/versions.xml
/guidelines/index-flat.html
+/_site/
diff --git a/.nvmrc b/.nvmrc
new file mode 100644
index 0000000000..209e3ef4b6
--- /dev/null
+++ b/.nvmrc
@@ -0,0 +1 @@
+20
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/.prettierignore b/.prettierignore
new file mode 100644
index 0000000000..2c49d868d2
--- /dev/null
+++ b/.prettierignore
@@ -0,0 +1,3 @@
+*.*
+!*.ts
+!*.11tydata.js
diff --git a/.prettierrc b/.prettierrc
new file mode 100644
index 0000000000..12c91d0119
--- /dev/null
+++ b/.prettierrc
@@ -0,0 +1,4 @@
+{
+ "printWidth": 100,
+ "trailingComma": "es5"
+}
diff --git a/11ty/CustomLiquid.ts b/11ty/CustomLiquid.ts
new file mode 100644
index 0000000000..9afe6829a3
--- /dev/null
+++ b/11ty/CustomLiquid.ts
@@ -0,0 +1,582 @@
+import type { Cheerio, Element } from "cheerio";
+import { Liquid, type Template } from "liquidjs";
+import type { RenderOptions } from "liquidjs/dist/liquid-options";
+import compact from "lodash-es/compact";
+import uniq from "lodash-es/uniq";
+
+import { basename } from "path";
+
+import type { GlobalData } from "eleventy.config";
+
+import { flattenDom, load } from "./cheerio";
+import { generateId } from "./common";
+import { getTermsMap } from "./guidelines";
+import { resolveTechniqueIdFromHref, understandingToTechniqueLinkSelector } from "./techniques";
+import { techniqueToUnderstandingLinkSelector } from "./understanding";
+
+const titleSuffix = " | WAI | W3C";
+
+/** Matches index and about pages, traditionally processed differently than individual pages */
+const indexPattern = /(techniques|understanding)\/(index|about)\.html$/;
+const techniquesPattern = /\btechniques\//;
+const understandingPattern = /\bunderstanding\//;
+
+const termsMap = await getTermsMap();
+const termLinkSelector = "a:not([href])";
+
+/** Generates {% include "foo.html" %} directives from 1 or more basenames */
+const generateIncludes = (...basenames: string[]) =>
+ `\n${basenames.map((basename) => `{% include "${basename}.html" %}`).join("\n")}\n`;
+
+/**
+ * Determines whether a given string is actually HTML,
+ * not e.g. a data value Eleventy sent to the templating engine.
+ */
+const isHtmlFileContent = (html: string) => !html.startsWith("(((11ty") && !html.endsWith(".html");
+
+/**
+ * Performs common cleanup of in-page headings, and by extension, table of contents links,
+ * for final output.
+ */
+const normalizeHeading = (label: string) =>
+ label
+ .trim()
+ .replace(/In brief/, "In Brief")
+ .replace(/^(\S+) (of|for) .*$/, "$1")
+ .replace(/^Techniques and Failures .*$/, "Techniques")
+ .replace(/^Specific Benefits .*$/, "Benefits")
+ .replace(/^.* Examples$/, "Examples")
+ .replace(/^(Related )?Resources$/i, "Related Resources");
+
+/**
+ * Performs additional common cleanup for table of contents links for final output.
+ * This is expected to piggyback off of normalizeHeading, which should be called on
+ * headings prior to processing the table of contents from them.
+ */
+const normalizeTocLabel = (label: string) =>
+ label.replace(/ for this Guideline$/, "").replace(/ \(SC\)$/, "");
+
+/**
+ * Replaces a link with a technique URL with a Liquid tag which will
+ * expand to a link with the full technique ID and title.
+ * @param $el a $()-wrapped link element
+ */
+function expandTechniqueLink($el: Cheerio Note Note ${$el.html()} Example${exampleText}
`);
+ }
+ });
+ } else if (isUnderstanding) {
+ // Add numbers to figcaptions
+ $("figcaption").each((i, el) => {
+ const $el = $(el);
+ if (!$el.find("p").length) $el.wrapInner("");
+ $el.prepend(`Figure ${i + 1}`);
+ });
+
+ // Remove spurious copy-pasted content in 2.5.3 that doesn't belong there
+ if ($("section#benefits").length > 1) $("section#benefits").first().remove();
+ // Some pages nest Benefits inside Intent; XSLT always pulls it back out
+ $("section#intent section#benefits")
+ .insertAfter("section#intent")
+ .find("h3:first-child")
+ .each((_, el) => {
+ el.tagName = "h2";
+ });
+
+ // XSLT orders resources then techniques last, opposite of source files
+ $("body")
+ .append("\n", $(`body > section#resources`))
+ .append("\n", $(`body > section#techniques`));
+
+ // Expand top-level heading and add box for guideline/SC pages
+ if ($("section#intent").length) $("h1").replaceWith(generateIncludes("understanding/h1"));
+ $("section#intent").before(generateIncludes("understanding/about"));
+
+ $("section#techniques h2").after(generateIncludes("understanding/intro/techniques"));
+ if ($("section#sufficient .situation").length) {
+ $("section#sufficient h3").after(
+ generateIncludes("understanding/intro/sufficient-situation")
+ );
+ }
+ // success-criteria section should be auto-generated;
+ // remove any handwritten ones (e.g. Input Modalities)
+ const $successCriteria = $("section#success-criteria");
+ if ($successCriteria.length) {
+ console.warn(
+ `${filepath}: success-criteria section will be replaced with ` +
+ "generated version; please remove this from the source file."
+ );
+ $successCriteria.remove();
+ }
+ // success-criteria template only renders content for guideline (not SC) pages
+ $("body").append(generateIncludes("understanding/success-criteria"));
+
+ // Remove unpopulated techniques subsections
+ for (const id of ["sufficient", "advisory", "failure"]) {
+ $(`section#${id}:not(:has(:not(h3)))`).remove();
+ }
+
+ // Normalize subsection names for Guidelines (h2) and/or SC (h3)
+ $("section#sufficient h3").text("Sufficient Techniques");
+ $("section#advisory").find("h2, h3").text("Advisory Techniques");
+ $("section#failure h3").text("Failures");
+
+ // Add intro prose to populated sections
+ $("section#advisory")
+ .find("h2, h3")
+ .after(generateIncludes("understanding/intro/advisory"));
+ $("section#failure h3").after(generateIncludes("understanding/intro/failure"));
+ $("section#resources h2").after(generateIncludes("understanding/intro/resources"));
+
+ // Expand techniques links to always include title
+ $(understandingToTechniqueLinkSelector).each((_, el) => expandTechniqueLink($(el)));
+
+ // Add key terms by default, to be removed in #parse if there are no terms
+ $("body").append(generateIncludes("understanding/key-terms"));
+ }
+
+ // Remove h2-level sections with no content other than heading
+ $("body > section:not(:has(:not(h2)))").remove();
+
+ $("body")
+ .attr("dir", "ltr") // Already included in index/about pages
+ .append(generateIncludes("test-rules", "back-to-top"))
+ .wrapInner(``)
+ .prepend(generateIncludes("sidebar"))
+ .append(generateIncludes("help-improve"))
+ // index/about pages already include this wrapping; others do not, and need it.
+ // This wraps around table of contents & help improve, but not other includes
+ .wrapInner(``);
+ }
+
+ $("body")
+ .prepend(generateIncludes(...prependedIncludes))
+ .append(generateIncludes(...appendedIncludes));
+
+ return super.parse($.html(), filepath);
+ }
+ return super.parse(html);
+ }
+
+ public async render(templates: Template[], scope: GlobalData, options?: RenderOptions) {
+ // html contains markup after Liquid tags/includes have been processed
+ const html = (await super.render(templates, scope, options)).toString();
+ if (!isHtmlFileContent(html) || !scope) return html;
+
+ const $ = load(html);
+
+ if (indexPattern.test(scope.page.inputPath)) {
+ // Remove empty list items due to obsolete technique link removal
+ if (scope.isTechniques) $("ul.toc-wcag-docs li:empty").remove();
+ } else {
+ const $title = $("title");
+
+ if (scope.isTechniques) {
+ const isObsolete =
+ scope.technique.obsoleteSince && scope.technique.obsoleteSince <= scope.version;
+ if (isObsolete) $("body").addClass("obsolete");
+
+ $title.text(
+ (isObsolete ? "[Obsolete] " : "") +
+ `${scope.technique.id}: ${scope.technique.title}${titleSuffix}`
+ );
+
+ const aboutBoxSelector = "section#technique .box-i";
+
+ // Strip applicability paragraphs with metadata IDs (e.g. H99)
+ $("section#applicability").find("p#id, p#technology, p#type").remove();
+ // Check for custom applicability paragraph before removing the section
+ const customApplicability = $("section#applicability p")
+ .html()
+ ?.trim()
+ .replace(/^th(e|is) (technique|failure)s? (is )?/i, "")
+ .replace(/^general( technique|ly applicable)?(\.|$).*$/i, "all technologies")
+ .replace(/^appropriate to use for /i, "")
+ .replace(/^use this technique on /i, "")
+ // Work around redundant sentences (e.g. F105)
+ .replace(/\.\s+This technique relates to Success Criterion [\d\.]+\d[^\.]+\.$/, "");
+ if (customApplicability) {
+ const appliesPattern = /^(?:appli(?:es|cable)|relates) (to|when(?:ever)?)\s*/i;
+ const rephrasedApplicability = customApplicability.replace(appliesPattern, "");
+
+ // Failure pages have no default applicability paragraph, so append one first
+ if (scope.technique.technology === "failures")
+ $("section#technique .box-i").append("");
+
+ const noun = scope.technique.technology === "failures" ? "failure" : "technique";
+ const appliesMatch = appliesPattern.exec(customApplicability);
+ const connector = /^not/.test(customApplicability)
+ ? "is"
+ : `applies ${appliesMatch?.[1] || "to"}`;
+ $("section#technique .box-i p:last-child").html(
+ `This ${noun} ${connector} ` +
+ // Uncapitalize original sentence, except for all-caps abbreviations or titles
+ (/^[A-Z]{2,}/.test(rephrasedApplicability) ||
+ /^([A-Z][a-z]+(\s+|\.?$))+(\/|$)/.test(rephrasedApplicability)
+ ? rephrasedApplicability
+ : rephrasedApplicability[0].toLowerCase() + rephrasedApplicability.slice(1)) +
+ (/(\.|:)$/.test(rephrasedApplicability) ? "" : ".")
+ );
+
+ // Append any relevant subsequent paragraphs or lists from applicability section
+ const $additionalApplicability = $("section#applicability").find(
+ "p:not(:first-of-type), ul, ol"
+ );
+ const additionalApplicabilityText = $additionalApplicability.text();
+ const excludes = [
+ "None listed.", // Template filler
+ "This technique relates to:", // Redundant of auto-generated content
+ ];
+ if (excludes.every((exclude) => !additionalApplicabilityText.includes(exclude)))
+ $additionalApplicability.appendTo(aboutBoxSelector);
+ }
+ $("section#applicability").remove();
+
+ // Remove any effectively-empty techniques/resources sections,
+ // due to template boilerplate or obsolete technique removal
+ $("section#related:not(:has(a))").remove();
+ $("section#resources:not(:has(a, li))").remove();
+
+ // Update understanding links to always use base URL
+ // (mainly to avoid any case-sensitivity issues)
+ $(techniqueToUnderstandingLinkSelector).each((_, el) => {
+ el.attribs.href = el.attribs.href.replace(/^.*\//, scope.understandingUrl);
+ });
+ } else if (scope.isUnderstanding) {
+ if (scope.guideline) {
+ const type = scope.guideline.type === "SC" ? "Success Criterion" : scope.guideline.type;
+ $title.text(
+ `Understanding ${type} ${scope.guideline.num}: ${scope.guideline.name}${titleSuffix}`
+ );
+ } else {
+ $title.text(
+ $title.text().replace(/WCAG 2( |$)/, `WCAG ${scope.versionDecimal}$1`) + titleSuffix
+ );
+ }
+
+ // Remove Techniques section from obsolete SCs (e.g. Parsing in 2.2)
+ if (scope.guideline?.level === "") $("section#techniques").remove();
+ }
+
+ // Process defined terms within #render,
+ // where we have access to global data and the about box's HTML
+ const $termLinks = $(termLinkSelector);
+ const extractTermName = ($el: Cheerio]*>([\s\S]+?)<\/h1>/);
+ if (!h1Match || !h1Match[1]) throw new Error(`No h1 found in techniques/${path}`);
+ const $h1 = load(h1Match[1], null, false);
+
+ const title = $h1.text();
+ techniques[technology].push({
+ ...data, // Include front-matter
+ id: basename(filename, ".html"),
+ technology,
+ title,
+ titleHtml: $h1.html(),
+ truncatedTitle: title.replace(/\s*\n[\s\S]*\n\s*/, " … "),
+ });
+ }
+
+ for (const technology of technologies) {
+ techniques[technology].sort((a, b) => {
+ const aId = +a.id.replace(/\D/g, "");
+ const bId = +b.id.replace(/\D/g, "");
+ if (aId < bId) return -1;
+ if (aId > bId) return 1;
+ return 0;
+ });
+ }
+
+ return techniques;
+}
+
+/**
+ * Returns a flattened object hash, mapping each technique ID directly to its data.
+ */
+export const getFlatTechniques = (
+ techniques: Awaited
Web Content Accessibility Guidelines (WCAG) 2.2 defines how to make Web content more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees, and combinations of disability. These guidelines also make Web content more usable by older individuals with changing abilities due to aging and often improve usability for users in general.
-WCAG 2.2 is developed through the W3C process in cooperation with individuals and organizations around the world, with a goal of providing a shared standard for Web content accessibility that meets the needs of individuals, organizations, and governments internationally. WCAG 2.2 builds on WCAG 2.0 [[WCAG20]] and WCAG 2.1 [[WCAG21]], which in turn built on WCAG 1.0 [[WAI-WEBCONTENT]] and is designed to apply broadly to different Web technologies now and in the future, and to be testable with a combination of automated testing and human evaluation. For an introduction to WCAG, see the Web Content Accessibility Guidelines (WCAG) Overview.
+Web Content Accessibility Guidelines (WCAG) 2.2 defines how to make web content more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees, and combinations of disability. These guidelines also make web content more usable by older individuals with changing abilities due to aging and often improve usability for users in general.
+WCAG 2.2 is developed through the W3C process in cooperation with individuals and organizations around the world, with a goal of providing a shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally. WCAG 2.2 builds on WCAG 2.0 [[WCAG20]] and WCAG 2.1 [[WCAG21]], which in turn built on WCAG 1.0 [[WAI-WEBCONTENT]] and is designed to apply broadly to different web technologies now and in the future, and to be testable with a combination of automated testing and human evaluation. For an introduction to WCAG, see the Web Content Accessibility Guidelines (WCAG) Overview.
Significant challenges were encountered in defining additional criteria to address cognitive, language, and learning disabilities, including a short timeline for development as well as challenges in reaching consensus on testability, implementability, and international considerations of proposals. Work will carry on in this area in future versions of WCAG. We encourage authors to refer to our supplemental guidance on improving inclusion for people with disabilities, including learning and cognitive disabilities, people with low-vision, and more.
-Web accessibility depends not only on accessible content but also on accessible Web browsers and other user agents. Authoring tools also have an important role in Web accessibility. For an overview of how these components of Web development and interaction work together, see:
+Web accessibility depends not only on accessible content but also on accessible web browsers and other user agents. Authoring tools also have an important role in web accessibility. For an overview of how these components of web development and interaction work together, see:
The individuals and organizations that use WCAG vary widely and include Web designers and developers, policy makers, purchasing agents, teachers, and students. In order to meet the varying needs of this audience, several layers of guidance are provided including overall principles, general guidelines, testable success criteria and a rich collection of sufficient techniques, advisory techniques, and documented common failures with examples, resource links and code.
+The individuals and organizations that use WCAG vary widely and include web designers and developers, policy makers, purchasing agents, teachers, and students. In order to meet the varying needs of this audience, several layers of guidance are provided including overall principles, general guidelines, testable success criteria and a rich collection of sufficient techniques, advisory techniques, and documented common failures with examples, resource links and code.
Principles - At the top are four principles that provide the foundation for Web accessibility: perceivable, operable, understandable, and robust. See also Understanding the Four Principles of Accessibility.
+Principles - At the top are four principles that provide the foundation for web accessibility: perceivable, operable, understandable, and robust. See also Understanding the Four Principles of Accessibility.
Guidelines - Under the principles are guidelines. The 13 guidelines provide the basic goals that authors should work toward in order to make content more accessible to users with different disabilities. The guidelines are not testable, but provide the framework and overall objectives to help authors understand the success criteria and better implement the techniques.
@@ -60,14 +60,14 @@All of these layers of guidance (principles, guidelines, success criteria, and sufficient and advisory techniques) work together to provide guidance on how to make content more accessible. Authors are encouraged to view and apply all layers that they are able to, including the advisory techniques, in order to best address the needs of the widest possible range of users.
-Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive, language, and learning areas. Authors are encouraged to consider the full range of techniques, including the advisory techniques, Making Content Usable for People with Cognitive and Learning Disabilities, as well as to seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community. Metadata may assist users in finding content most suitable for their needs.
+Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive, language, and learning areas. Authors are encouraged to consider the full range of techniques, including the advisory techniques, Making Content Usable for People with Cognitive and Learning Disabilities, as well as to seek relevant advice about current best practice to ensure that web content is accessible, as far as possible, to this community. Metadata may assist users in finding content most suitable for their needs.
The WCAG 2.2 document is designed to meet the needs of those who need a stable, referenceable technical standard. Other documents, called supporting documents, are based on the WCAG 2.2 document and address other important purposes, including the ability to be updated to describe how WCAG would be applied with new technologies. Supporting documents include:
How to Meet WCAG 2.2 - A customizable quick reference to WCAG 2.2 that includes all of the guidelines, success criteria, and techniques for authors to use as they are developing and evaluating Web content. This includes content from WCAG 2.0, 2.1 2.2 and can be filtered in many ways to help authors focus on relevant content.
+How to Meet WCAG 2.2 - A customizable quick reference to WCAG 2.2 that includes all of the guidelines, success criteria, and techniques for authors to use as they are developing and evaluating web content. This includes content from WCAG 2.0, 2.1 2.2 and can be filtered in many ways to help authors focus on relevant content.
Understanding WCAG 2.2 - A guide to understanding and implementing WCAG 2.2. There is a short "Understanding" document for each guideline and success criterion in WCAG 2.2 as well as key topics.
@@ -80,7 +80,7 @@What's New in WCAG 2.2 introduces the new success criteria with persona quotes that illustrate the accessibility issues.
See Web Content Accessibility Guidelines (WCAG) Overview for a description of the WCAG 2.2 supporting material, including education resources related to WCAG 2. Additional resources covering topics such as the business case for Web accessibility, planning implementation to improve the accessibility of Web sites, and accessibility policies are listed in WAI Resources.
+See Web Content Accessibility Guidelines (WCAG) Overview for a description of the WCAG 2.2 supporting material, including education resources related to WCAG 2. Additional resources covering topics such as the business case for web accessibility, planning implementation to improve the accessibility of websites, and accessibility policies are listed in WAI Resources.
Make Web pages appear and operate in predictable ways.
+Make web pages appear and operate in predictable ways.
@@ -408,35 +408,35 @@In order for a Web page to conform to WCAG 2.2, all of the following conformance requirements must be satisfied:
+In order for a web page to conform to WCAG 2.2, all of the following conformance requirements must be satisfied:
One of the following levels of conformance is met in full.
Although conformance can only be achieved at the stated levels, authors are encouraged to report (in their claim) any progress toward meeting success criteria from all levels beyond the achieved level of conformance.
-It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content.
+It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA success criteria for some content.
Conformance (and conformance level) is for full Web page(s) only, and cannot be achieved if part of a Web page is excluded.
+Conformance (and conformance level) is for full web page(s) only, and cannot be achieved if part of a web page is excluded.
For the purpose of determining conformance, alternatives to part of a page's content are considered part of the page when the alternatives can be obtained directly from the page, e.g., a long description or an alternative presentation of a video.
-Authors of Web pages that cannot conform due to content outside of the author's control may consider a Statement of Partial Conformance.
-A full page includes each variation of the page that is automatically presented by the page for various screen sizes (e.g. variations in a responsive Web page). Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform.
+Authors of web pages that cannot conform due to content outside of the author's control may consider a Statement of Partial Conformance.
+A full page includes each variation of the page that is automatically presented by the page for various screen sizes (e.g. variations in a responsive web page). Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform.
When a Web page is one of a series of Web pages presenting a process (i.e., a sequence of steps that need to be completed in order to accomplish an activity), all Web pages in the process conform at the specified level or better. (Conformance is not possible at a particular level if any page in the process does not conform at that level or better.)
+When a web page is one of a series of web pages presenting a process (i.e., a sequence of steps that need to be completed in order to accomplish an activity), all web pages in the process conform at the specified level or better. (Conformance is not possible at a particular level if any page in the process does not conform at that level or better.)
If technologies are used in a way that is not accessibility supported, or if they are used in a non-conforming way, then they do not block the ability of users to access the rest of the page. In addition, the Web page as a whole continues to meet the conformance requirements under each of the following conditions:
+If technologies are used in a way that is not accessibility supported, or if they are used in a non-conforming way, then they do not block the ability of users to access the rest of the page. In addition, the web page as a whole continues to meet the conformance requirements under each of the following conditions:
Conformance is defined only for Web pages. However, a conformance claim may be made to cover one page, a series of pages, or multiple related Web pages.
+Conformance is defined only for web pages. However, a conformance claim may be made to cover one page, a series of pages, or multiple related web pages.
A concise description of the Web pages, such as a list of URIs for which the claim is made, including whether subdomains are included in the claim.
-The Web pages may be described by list or by an expression that describes all of the URIs included in the claim.
-Web-based products that do not have a URI prior to installation on the customer's Web site may have a statement that the product would conform when installed.
+A concise description of the web pages, such as a list of URIs for which the claim is made, including whether subdomains are included in the claim.
+The web pages may be described by list or by an expression that describes all of the URIs included in the claim.
+Web-based products that do not have a URI prior to installation on the customer's website may have a statement that the product would conform when installed.
If a conformance logo is used, it would constitute a claim and must be accompanied by the required components of a conformance claim listed above.
@@ -539,8 +539,8 @@Success Criteria within this specification which the Working Group has identified possible implications for privacy, either by providing protections for end users or which are important for web site providers to take in to consideration when implementing features designed to protect user privacy, are listed below. This list reflects the current understanding of the Working Group but other Success Criteria may have privacy implications that the Working Group is not aware of at the time of publishing.
-Success Criteria within this specification that may relate to privacy are:
+Success criteria within this specification which the Working Group has identified possible implications for privacy, either by providing protections for end users or which are important for website providers to take in to consideration when implementing features designed to protect user privacy, are listed below. This list reflects the current understanding of the Working Group but other Success criteria may have privacy implications that the Working Group is not aware of at the time of publishing.
+Success criteria within this specification that may relate to privacy are:
Success Criteria within this specification which the Working Group has identified possible implications for security, either by providing protections for end users or which are important for web site providers to take in to consideration when implementing features designed to protect user security, are listed below. This list reflects the current understanding of the Working Group but other Success Criteria may have security implications that the Working Group is not aware of at the time of publishing.
-Success Criteria within this specification that may relate to security are:
+Success criteria within this specification which the Working Group has identified possible implications for security, either by providing protections for end users or which are important for website providers to take in to consideration when implementing features designed to protect user security, are listed below. This list reflects the current understanding of the Working Group but other Success criteria may have security implications that the Working Group is not aware of at the time of publishing.
+Success criteria within this specification that may relate to security are:
This section shows substantive changes made in WCAG 2.2 since WCAG 2.1. Errata fixes to WCAG 2.1 have also been incorporated into WCAG 2.2.
+This section shows substantive changes incorporated into WCAG 2.2 since WCAG 2.1, as well as changes made to 2.2 since its original publication on 05 October 2023. Errata fixes to WCAG 2.1 have also been incorporated into WCAG 2.2.
The full commit history to WCAG 2.2 is available.
Focus Visible (Enhanced), later renamed to Focus Appearance (Enhanced), later removed.
Pointer Target Spacingto
Target Size (Minimum)
Dragging(later renamed Dragging Movements).
Findable Help(later renamed to Consistent Help),
Fixed Reference Points(Page Break Navigation),
Hidden Controls(later renamed Visible Controls),
Pointer Target Spacing(later renamed Target Size (Minimum)), Redundant Entry.
Focus Visible (Enhanced)to
Focus Appearance (Enhanced).
Draggingto Dragging Movements.
Hidden Controlsto Visible Controls.
Findable Help(later renamed to Consistent Help),
Pointer Target Spacing(later renamed Target Size (Minimum)), and Redundant Entry.
Focus Appearance (Minimum)(later renamed to Focus Appearance).
Accessible Authentication (No Exception)(later renamed Accessible Authentication (Enhanced)).
enclosesdefinition
success criteria/criterion,
web,
website, and
web page
Before May 2021 the value of 0.04045 in the definition was different (0.03928). It was taken from an older version of the specification and has been updated. It has no practical effect on the calculations in the context of these guidelines.
Almost all systems used today to view Web content assume sRGB encoding. Unless it +
Almost all systems used today to view web content assume sRGB encoding. Unless it is known that another color space will be used to process and display the content, authors should evaluate using sRGB colorspace. If using other color spaces, see Understanding Success Criterion 1.4.3.
A
-If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio +
If any audio on a web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.
Since any content that does not meet this success criterion can interfere with a user's - ability to use the whole page, all content on the Web page (whether or not it is used + ability to use the whole page, all content on the web page (whether or not it is used to meet other success criteria) must meet this success criterion. See Conformance Requirement 5: Non-Interference.
diff --git a/guidelines/sc/20/bypass-blocks.html b/guidelines/sc/20/bypass-blocks.html index 5e33982b78..0f4ce7ca78 100644 --- a/guidelines/sc/20/bypass-blocks.html +++ b/guidelines/sc/20/bypass-blocks.html @@ -4,7 +4,7 @@A
-A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. +
A mechanism is available to bypass blocks of content that are repeated on multiple web pages.
diff --git a/guidelines/sc/20/consistent-identification.html b/guidelines/sc/20/consistent-identification.html index 789b8d23f6..6b04f77b20 100644 --- a/guidelines/sc/20/consistent-identification.html +++ b/guidelines/sc/20/consistent-identification.html @@ -4,7 +4,7 @@AA
-Components that have the same functionality within a set of Web pages are identified consistently. +
Components that have the same functionality within a set of web pages are identified consistently.
diff --git a/guidelines/sc/20/consistent-navigation.html b/guidelines/sc/20/consistent-navigation.html index a1df5d4e8a..041cfd7ad9 100644 --- a/guidelines/sc/20/consistent-navigation.html +++ b/guidelines/sc/20/consistent-navigation.html @@ -4,7 +4,7 @@AA
-Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. +
Navigational mechanisms that are repeated on multiple web pages within a set of web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.
diff --git a/guidelines/sc/20/error-prevention-all.html b/guidelines/sc/20/error-prevention-all.html index 8fb05bb90e..2b45e63503 100644 --- a/guidelines/sc/20/error-prevention-all.html +++ b/guidelines/sc/20/error-prevention-all.html @@ -4,7 +4,7 @@AAA
-For Web pages that require the user to submit information, at least one of the following is true: +
For web pages that require the user to submit information, at least one of the following is true:
AA
-For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of +
For web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true:
diff --git a/guidelines/sc/20/focus-order.html b/guidelines/sc/20/focus-order.html index 5c36ef43f5..67c724e207 100644 --- a/guidelines/sc/20/focus-order.html +++ b/guidelines/sc/20/focus-order.html @@ -4,7 +4,7 @@A
-If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive +
If a web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.
diff --git a/guidelines/sc/20/language-of-page.html b/guidelines/sc/20/language-of-page.html index c921129756..bae8a9ee88 100644 --- a/guidelines/sc/20/language-of-page.html +++ b/guidelines/sc/20/language-of-page.html @@ -4,7 +4,7 @@A
-The default human language of each Web page can be programmatically determined. +
The default human language of each web page can be programmatically determined.
diff --git a/guidelines/sc/20/location.html b/guidelines/sc/20/location.html index c7cb164b4f..cb72028db4 100644 --- a/guidelines/sc/20/location.html +++ b/guidelines/sc/20/location.html @@ -4,7 +4,7 @@AAA
-Information about the user's location within a set of Web pages is available. +
Information about the user's location within a set of web pages is available.
diff --git a/guidelines/sc/20/multiple-ways.html b/guidelines/sc/20/multiple-ways.html index 0b66078a99..f320500072 100644 --- a/guidelines/sc/20/multiple-ways.html +++ b/guidelines/sc/20/multiple-ways.html @@ -4,7 +4,7 @@AA
-More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process. +
More than one way is available to locate a web page within a set of web pages except where the web page is the result of, or a step in, a process.
diff --git a/guidelines/sc/20/name-role-value.html b/guidelines/sc/20/name-role-value.html index b3ce49a363..d28ac0b22a 100644 --- a/guidelines/sc/20/name-role-value.html +++ b/guidelines/sc/20/name-role-value.html @@ -8,7 +8,7 @@This success criterion is primarily for Web authors who develop or script their own +
This success criterion is primarily for web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.
diff --git a/guidelines/sc/20/no-keyboard-trap.html b/guidelines/sc/20/no-keyboard-trap.html index 89d917165d..c8865dd0db 100644 --- a/guidelines/sc/20/no-keyboard-trap.html +++ b/guidelines/sc/20/no-keyboard-trap.html @@ -10,7 +10,7 @@Since any content that does not meet this success criterion can interfere with a user's - ability to use the whole page, all content on the Web page (whether it is used to + ability to use the whole page, all content on the web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.
diff --git a/guidelines/sc/20/pause-stop-hide.html b/guidelines/sc/20/pause-stop-hide.html index ab71a6bf3b..e8eaf3f32a 100644 --- a/guidelines/sc/20/pause-stop-hide.html +++ b/guidelines/sc/20/pause-stop-hide.html @@ -39,7 +39,7 @@Since any content that does not meet this success criterion can interfere with a user's - ability to use the whole page, all content on the Web page (whether it is used to + ability to use the whole page, all content on the web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.
diff --git a/guidelines/sc/20/three-flashes-or-below-threshold.html b/guidelines/sc/20/three-flashes-or-below-threshold.html index 13b874c11e..cb031f7072 100644 --- a/guidelines/sc/20/three-flashes-or-below-threshold.html +++ b/guidelines/sc/20/three-flashes-or-below-threshold.html @@ -9,7 +9,7 @@Since any content that does not meet this success criterion can interfere with a user's - ability to use the whole page, all content on the Web page (whether it is used to + ability to use the whole page, all content on the web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.
diff --git a/guidelines/sc/21/pointer-cancellation.html b/guidelines/sc/21/pointer-cancellation.html index 1da1d25679..c04412851a 100644 --- a/guidelines/sc/21/pointer-cancellation.html +++ b/guidelines/sc/21/pointer-cancellation.html @@ -23,6 +23,6 @@Functions that emulate a keyboard or numeric keypad key press are considered essential.
-This requirement applies to web content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).
+This requirement applies to web content that interprets pointer actions (i.e., this does not apply to actions that are required to operate the user agent or assistive technology).
diff --git a/guidelines/sc/21/pointer-gestures.html b/guidelines/sc/21/pointer-gestures.html index 037ea8378e..69749992de 100644 --- a/guidelines/sc/21/pointer-gestures.html +++ b/guidelines/sc/21/pointer-gestures.html @@ -6,6 +6,6 @@All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.
-This requirement applies to web content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).
+This requirement applies to web content that interprets pointer actions (i.e., this does not apply to actions that are required to operate the user agent or assistive technology).
diff --git a/guidelines/sc/22/accessible-authentication-minimum.html b/guidelines/sc/22/accessible-authentication-minimum.html index 150b65fef0..29a46b406d 100644 --- a/guidelines/sc/22/accessible-authentication-minimum.html +++ b/guidelines/sc/22/accessible-authentication-minimum.html @@ -14,15 +14,15 @@"Object recognition" and "Personal content" may be represented by images, video, or audio.
A
New
-If a Web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple Web pages within a set of Web pages, they occur in the same order relative to other page content, unless a change is initiated by the user:
+If a web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple web pages within a set of web pages, they occur in the same order relative to other page content, unless a change is initiated by the user:
Help mechanisms may be provided directly on the page, or may be provided via a direct link to a different page containing the information.
-For this Success Criterion, "the same order relative to other page content" can be thought of as how the content is ordered when the page is serialized. The visual position of a help mechanism is likely to be consistent across pages for the same page variation (e.g., CSS break-point). The user can initiate a change, such as changing the page's zoom or orientation, which may trigger a different page variation. This criterion is concerned with relative order across pages displayed in the same page variation (e.g., same zoom level and orientation).
+For this success criterion, "the same order relative to other page content" can be thought of as how the content is ordered when the page is serialized. The visual position of a help mechanism is likely to be consistent across pages for the same page variation (e.g., CSS break-point). The user can initiate a change, such as changing the page's zoom or orientation, which may trigger a different page variation. This criterion is concerned with relative order across pages displayed in the same page variation (e.g., same zoom level and orientation).
diff --git a/guidelines/sc/22/dragging-movements.html b/guidelines/sc/22/dragging-movements.html index d4b8817c68..0543f9e901 100644 --- a/guidelines/sc/22/dragging-movements.html +++ b/guidelines/sc/22/dragging-movements.html @@ -6,6 +6,6 @@New
All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.
-This requirement applies to web content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).
+This requirement applies to web content that interprets pointer actions (i.e., this does not apply to actions that are required to operate the user agent or assistive technology).
diff --git a/guidelines/sc/22/focus-appearance.html b/guidelines/sc/22/focus-appearance.html index fce58ddde2..2fc2d22ab7 100644 --- a/guidelines/sc/22/focus-appearance.html +++ b/guidelines/sc/22/focus-appearance.html @@ -20,6 +20,6 @@Examples of sub-components that may receive a focus indicator are menu items in an opened drop-down menu, or focusable cells in a grid.
-Contrast calculations can be based on colors defined within the technology (such as HTML, CSS and SVG). Pixels modified by user agent resolution enhancements and anti-aliasing can be ignored.
+Contrast calculations can be based on colors defined within the technology (such as HTML, CSS, and SVG). Pixels modified by user agent resolution enhancements and anti-aliasing can be ignored.
diff --git a/guidelines/sc/22/focus-not-obscured-minimum.html b/guidelines/sc/22/focus-not-obscured-minimum.html index 4d0ef3bce2..0ac886b9eb 100644 --- a/guidelines/sc/22/focus-not-obscured-minimum.html +++ b/guidelines/sc/22/focus-not-obscured-minimum.html @@ -7,7 +7,7 @@When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.
-Where content in a configurable interface can be repositioned by the user, then only the initial positions of user-movable content are considered for testing and conformance of this Success Criterion.
+Where content in a configurable interface can be repositioned by the user, then only the initial positions of user-movable content are considered for testing and conformance of this success criterion.
Content opened by the user may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered visually hidden due to author-created content.
diff --git a/guidelines/terms/20/accessibility-supported.html b/guidelines/terms/20/accessibility-supported.html index e863db98c9..3d53e4c99a 100644 --- a/guidelines/terms/20/accessibility-supported.html +++ b/guidelines/terms/20/accessibility-supported.html @@ -3,8 +3,8 @@supported by users' assistive technologies as well as the accessibility features in browsers and other user agents
-To qualify as an accessibility-supported use of a Web content technology (or feature - of a technology), both 1 and 2 must be satisfied for a Web content technology (or +
To qualify as an accessibility-supported use of a web content technology (or feature + of a technology), both 1 and 2 must be satisfied for a web content technology (or feature):
@@ -12,7 +12,7 @@The way that the Web content technology is used must be supported by users' assistive technology (AT). This means that the way that the technology is used has been tested for interoperability +
The way that the web content technology is used must be supported by users' assistive technology (AT). This means that the way that the technology is used has been tested for interoperability with users' assistive technology in the human language(s) of the content,
@@ -22,7 +22,7 @@The Web content technology must have accessibility-supported user agents that are
+ The web content technology must have accessibility-supported user agents that are
available to users. This means that at least one of the following four statements is true:
The Accessibility Guidelines Working Group and the W3C do not specify which or how much support by assistive
- technologies there must be for a particular use of a Web technology in order for it
+ technologies there must be for a particular use of a web technology in order for it
to be classified as accessibility supported. (See Level of Assistive Technology Support Needed for "Accessibility Support".)
When a Web Technology is used in a way that is "accessibility supported," it does not imply that the entire +
When a web technology is used in a way that is "accessibility supported," it does not imply that the entire technology or all uses of the technology are supported. Most technologies, including HTML, lack support for at least one feature or use. Pages conform to WCAG only if the uses of the technology that are accessibility supported can be relied upon to meet WCAG requirements.
-When citing Web content technologies that have multiple versions, the version(s) supported +
When citing web content technologies that have multiple versions, the version(s) supported should be specified.
One way for authors to locate uses of a technology that are accessibility supported would be to consult compilations of uses that are documented to be accessibility supported. (See Understanding Accessibility-Supported Web Technology Uses.) Authors, companies, technology vendors, or others may document accessibility-supported - ways of using Web content technologies. However, all ways of using technologies in + ways of using web content technologies. However, all ways of using technologies in the documentation would need to meet the definition of accessibility-supported Web content technologies above.
diff --git a/guidelines/terms/20/ambiguous-to-users-in-general.html b/guidelines/terms/20/ambiguous-to-users-in-general.html index 5260803b07..71e67d8b93 100644 --- a/guidelines/terms/20/ambiguous-to-users-in-general.html +++ b/guidelines/terms/20/ambiguous-to-users-in-general.html @@ -1,7 +1,7 @@the purpose cannot be determined from the link and all information of the Web page +
the purpose cannot be determined from the link and all information of the web page presented to the user simultaneously with the link (i.e., readers without disabilities would not know what a link would do until they activated it)
diff --git a/guidelines/terms/20/assistive-technology.html b/guidelines/terms/20/assistive-technology.html index 4a918854c8..0a9d4c306b 100644 --- a/guidelines/terms/20/assistive-technology.html +++ b/guidelines/terms/20/assistive-technology.html @@ -23,7 +23,7 @@ target narrowly defined populations of users with specific disabilities. The assistance provided by an assistive technology is more specific and appropriate to the needs of its target users. The mainstream user agent may provide important functionality - to assistive technologies like retrieving Web content from program objects or parsing + to assistive technologies like retrieving web content from program objects or parsing markup into identifiable bundles. diff --git a/guidelines/terms/20/changes-of-context.html b/guidelines/terms/20/changes-of-context.html index b57e76b901..f9f20e9e3f 100644 --- a/guidelines/terms/20/changes-of-context.html +++ b/guidelines/terms/20/changes-of-context.html @@ -7,7 +7,7 @@Changes in context include changes of:
-A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, or a tab control do not necessarily change the 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 @@ -a flash or rapidly changing image sequence is below the threshold (i.e., content passes) if any of the following are true:
-where:
@@ -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 @@
text or other component with a text alternative that is presented to a user to identify a component within Web content
+text or other component with a text alternative that is presented to a user to identify a component within web content
A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same. diff --git a/guidelines/terms/20/name.html b/guidelines/terms/20/name.html index 9530872de2..c51273a1fe 100644 --- a/guidelines/terms/20/name.html +++ b/guidelines/terms/20/name.html @@ -1,7 +1,7 @@
text by which software can identify a component within Web content to the user
+text by which software can identify a component within web content to the user
The name may be hidden and only exposed by assistive technology, whereas a label is presented to all users. In many (but not all) cases, the label and the name are the same. diff --git a/guidelines/terms/20/process.html b/guidelines/terms/20/process.html index 9cafc80647..db40088cd4 100644 --- a/guidelines/terms/20/process.html +++ b/guidelines/terms/20/process.html @@ -3,7 +3,7 @@
series of user actions where each action is required in order to complete an activity
-This approach can be used to create sites that don't rely on script, if and only if the navigation target provides the same functionality as the script. This example is identical to the example 1, except that its href
is now set to a real page, dostuff.html. The sostuff.html page must provide the same functionality as the script. The "return false;
" at the end of the doStuff()
event handling function tells the browser not to navigate to the URI. Without it, the browser would navigate to dostuff.html after the script ran.
This approach can be used to create sites that don't rely on script, if and only if the navigation target provides the same functionality as the script. This example is identical to the example 1, except that its href
is now set to a real page, dostuff.html. The dostuff.html page must provide the same functionality as the script. The "return false;
" at the end of the doStuff()
event handling function tells the browser not to navigate to the URI. Without it, the browser would navigate to dostuff.html after the script ran.
<script>
function doStuff() {
diff --git a/techniques/client-side-script/SCR37.html b/techniques/client-side-script/SCR37.html
new file mode 100644
index 0000000000..e99c08cc66
--- /dev/null
+++ b/techniques/client-side-script/SCR37.html
@@ -0,0 +1,134 @@
+---
+obsoleteMessage: |
+ See H102: Creating modal dialogs with the HTML dialog element for a standards-based approach instead.
+obsoleteSince: 20
+---
+Creating Custom Dialogs in a Device Independent Way Creating Custom Dialogs in a Device Independent Way
When to Use
+ HTML and XHTML used with script.
+ Description
+ Site designers often want to create dialogs that do not use the pop-up windows supplied by the browser. This is typically accomplished by enclosing the dialog contents in a div
and placing the div
above the page content using z-order and absolute positioning in CSS.
+ To be accessible, these dialogs must follow a few simple rules.
+
+ - Trigger the script that launches the dialog from the onclick event of a link or button.
+ - Place the dialog
div
into the Document Object Model (DOM) immediately after the element that triggered it. The triggering element will maintain focus, and inserting the dialog content after that element will make the content inside the dialog next in the screen-reader reading order and next in the tab order. The dialog can still be absolutely positioned to be elsewhere on the page visually. This can be done either by creating the dialog in the HTML and hiding it with CSS, as in the example below, or by inserting it immediately after the triggering element with script.
+ - Ensure that the HTML inside the dialog div meets the same accessibility standard as other content.
+
+ It is also nice, but not always necessary, to make the launching link toggle the dialog open and closed, and to close the dialog when the keyboard focus leaves it.
+ Examples
+
+ An options button that opens a dialog
+
+ The HTML for this example includes a triggering Element, in this case a button, and a div that acts as the frame for the dialog.
+ The triggering element is a button and the script is triggered from the onclick event. This sends the appropriate events to the operating system so that assistive technology is aware of the change in the DOM.
+ In this example, the Submit and Reset buttons inside the dialog simply hide the div
.
+
+ ...
+<button onclick="TogglePopup(event,true)"
+ name="pop0001">Options</button>
+
+<div class="popover" id="pop0001">
+ <h3>Edit Sort Information</h3>
+ <form action="default.htm" onsubmit="this.parentNode.style.display='none'; return false;" onreset="this.parentNode.style.display='none'; return false;">
+ <fieldset>
+ <legend>Sort Order</legend>
+ <input type="radio" name="order" id="order_alpha" /><label for="order_alpha">Alphabetical</label>
+ <input type="radio" name="order" id="order_default" checked="true" /><label for="order_default">Default</label>
+ </fieldset>
+<div class="buttons">
+ <input type="submit" value="OK" />
+ <input type="reset" value="Cancel" />
+</div>
+</form>
+
+</div>
+...
+
+
+ The div
, heading and form
elements are styled with CSS to look like a dialog.
+
+ ...
+a { color:blue; }
+a.clickPopup img { border:none; width:0; }
+
+div.popover { position:absolute; display:none; border:1px outset; background-color:beige; font-size:80%; background-color:#eeeeee; color:black; }
+div.popover h3 { margin:0; padding:0.1em 0.5em; background-color:navy; color:white; }
+#pop0001 { width:20em; }
+#pop0001 form { margin:0; padding:0.5em; }
+#pop0001 fieldset { margin-bottom:0.3em; padding-bottom:0.5em; }
+#pop0001 input, #pop0001 label { vertical-align:middle; }
+#pop0001 div.buttons { text-align:right; }
+#pop0001 div.buttons input { width:6em; }
+...
+
+
+ The script toggles the display of the popup div
, showing it and hiding it.
+
+ ...
+function TogglePopup(evt,show) {
+ HarmonizeEvent(evt);
+ var src = evt.target;
+ if ("click" == evt.type) {
+ evt.returnValue = false;
+ }
+ var popID = src.getAttribute("name");
+ if (popID) {
+ var popup = document.getElementById(popID);
+ if (popup) {
+ if (true == show) {
+ popup.style.display = "block";
+ }
+ else if (false == show) {
+ popup.style.display = "none";
+ }
+ else {
+ popup.style.display = "block" == popup.style.display ? "none" : "block";
+ }
+ if ("block" == popup.style.display) {
+ //window.alert(document.documentElement.scrollHeight);
+ popup.style.top = ((document.documentElement.offsetHeight - popup.offsetHeight) / 2 ) + 'px';
+ popup.style.left = ((document.documentElement.offsetWidth - popup.offsetWidth) / 2) + 'px';
+ }
+ }
+ }
+}
+
+function SubmitForm(elem) {
+ elem.parentNode.style.display='none';
+ return false;
+}
+
+function ResetForm(elem) {
+ elem.parentNode.style.display='none';
+ return false;
+}
+...
+
+
+
+ Tests
+ Procedure
+
+ - Find all areas of the page that trigger dialogs that are not pop-up windows.
+ - Check that the dialogs can be opened by tabbing to the area and hitting enter.
+ - Check that, once opened, the dialog is next in the tab order.
+ - Check that the dialogs are triggered from the click event of a button or a link.
+ - Using a tool that allows you to inspect the DOM generated by script, check that the dialog is next in the DOM.
+
+
+ Expected Results
+
+ - Checks #2, #3, #4 and #5 are true.
+
+
+ Resources
+
+
+
+
diff --git a/techniques/client-side-script/SCR39.html b/techniques/client-side-script/SCR39.html
index 4bce0e2862..56f88e344e 100644
--- a/techniques/client-side-script/SCR39.html
+++ b/techniques/client-side-script/SCR39.html
@@ -29,7 +29,6 @@ Description
When hovering over or focusing on a link, a content preview for the link appears just above or below that link. diff --git a/techniques/css/C18.html b/techniques/css/C18.html index 4fd17d0875..6cb35c732f 100644 --- a/techniques/css/C18.html +++ b/techniques/css/C18.html @@ -53,10 +53,10 @@
margin-top
', 'margin-right
', 'margin-bottom
', 'margin-left
', and 'margin
' in the CSS2 specification
+ Margin properties: 'margin-top
', 'margin-right
', 'margin-bottom
', 'margin-left
', and 'margin
' in the CSS Box Model Module Level 3 specification
padding-top
', 'padding-right
', 'padding-bottom
', 'padding-left
', and 'padding
' in the CSS2 specification
+ Padding properties: 'padding-top
', 'padding-right
', 'padding-bottom
', 'padding-left
', and 'padding
' in the CSS Box Model Module Level 3 specification
There may also be situations where the visually presented order is necessary to the overall understanding of the page, and if the source order is presented differently, it may be much more difficult to understand.
When the source order matches the visual order, everyone will read the content and interact with it in the same (correct) order.
The tabindex
attribute in HTML has two functions. One is to make an element focusable and the other is to assign the element a position in the focus order. A tabindex
of 0 makes an element focusable, but adds it to the focus order in the order of source elements. The focus order will follow positive values of tabindex in ascending order. Setting tabindex
values that result in an order different from the order of elements in the Document Object Model (DOM) can mean the order is incorrect for users of assistive technologies. This is largely because the tabindex property is specified in the HTML or XHTML and not the CSS. This may change in future specifications. It may also differ from the visual presentation order.
The tabindex
attribute in HTML has two functions. One is to make an element focusable and the other is to assign the element a position in the focus order. A tabindex
of 0 makes an element focusable, but adds it to the focus order in the order of source elements. The focus order will follow positive values of tabindex in ascending order. Setting tabindex
values that result in an order different from the order of elements in the Document Object Model (DOM) can mean the order is incorrect for users of assistive technologies. This is largely because the tabindex property is specified in the HTML and not the CSS. This may change in future specifications. It may also differ from the visual presentation order.
The objective of this technique is to specify the width and/or height of containers, that contain text or that will accept text input, in em
units. This will allow user agents that support text resizing to resize the text containers in line with changes in text size settings.
The objective of this technique is to specify the width and/or height of containers, that contain text or that will accept text input, in em
units. This will allow user agents that support text resizing to resize the text containers in line with changes in text size settings.
The width and/or height of text containers that have been specified using other units risk text cropping because it falls outside the container boundaries when the text size has been increased.
-The containers generally control the placement of text within the Web page and can include layout elements, structural elements and form controls.
+The containers generally control the placement of text within the Web page and can include layout elements, structural elements and form controls.
+ +This technique uses em
units, but using rem
units instead would have the same effect.
em
units for sizes for layout container co
In this example, a div
element, with id
value of "nav_menu"
, is used to position the navigation menu along the left-hand side of the main content area of the Web page. The navigation menu consists of a list of text links, with id
value of "nav_list"
. The text size for the navigation links and the width of the container are specified in em
units.
#nav_menu { width: 20em; height: 100em }
+#nav_menu { width: 20em; height: 100em; }
#nav_list { font-size: 100%; }
+
CSS which causes motion that is triggered by user interactions.
For each user interface component that can receive keyboard focus:
This describes the failure condition that results when CSS, rather than
structural markup, is used to modify the visual layout of the content, and
the modified layout changes the meaning of the content. Using the
- positioning properties of CSS2, content may be displayed at any position on
+ positioning properties of CSS, content may be displayed at any position on
the user's viewport. The order in which items appear on a screen may be
different than the order they are found in the source document. Assistive
technologies rely on the source code or other programmatically determined
@@ -125,7 +125,7 @@
Expected Results
-
Provide information below to help editors associate the technique properly. Contents of the meta section are not output by the processor.
The second step in this failure technique involves examining code. Where dynamic content meets the definition of a status message, its container can be examined for an appropriate WAI-ARIA role or property which allows it to be programmatically determinable as a status message. Currently there are only a small number of techniques available to indicate status messages to assistive technologies. They are:
output
elementProvide information below to help editors associate the technique properly. Contents of the meta section are not output by the processor.
Applies to 2.5.1 Pointer Gestures
Failure Technique