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/11ty/CustomLiquid.ts b/11ty/CustomLiquid.ts index 9afe6829a3..1a302627c6 100644 --- a/11ty/CustomLiquid.ts +++ b/11ty/CustomLiquid.ts @@ -1,4 +1,3 @@ -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"; @@ -8,9 +7,10 @@ import { basename } from "path"; import type { GlobalData } from "eleventy.config"; -import { flattenDom, load } from "./cheerio"; +import { biblioPattern, getBiblio } from "./biblio"; +import { flattenDom, load, type CheerioAnyNode } from "./cheerio"; import { generateId } from "./common"; -import { getTermsMap } from "./guidelines"; +import { getAcknowledgementsForVersion, getTermsMap } from "./guidelines"; import { resolveTechniqueIdFromHref, understandingToTechniqueLinkSelector } from "./techniques"; import { techniqueToUnderstandingLinkSelector } from "./understanding"; @@ -21,6 +21,7 @@ const indexPattern = /(techniques|understanding)\/(index|about)\.html$/; const techniquesPattern = /\btechniques\//; const understandingPattern = /\bunderstanding\//; +const biblio = await getBiblio(); const termsMap = await getTermsMap(); const termLinkSelector = "a:not([href])"; @@ -61,7 +62,7 @@ const normalizeTocLabel = (label: string) => * expand to a link with the full technique ID and title. * @param $el a $()-wrapped link element */ -function expandTechniqueLink($el: Cheerio) { +function expandTechniqueLink($el: CheerioAnyNode) { const href = $el.attr("href"); if (!href) throw new Error("expandTechniqueLink: non-link element encountered"); const id = resolveTechniqueIdFromHref(href); @@ -89,7 +90,7 @@ export class CustomLiquid extends Liquid { const isIndex = indexPattern.test(filepath); const isTechniques = techniquesPattern.test(filepath); const isUnderstanding = understandingPattern.test(filepath); - + if (!isTechniques && !isUnderstanding) return super.parse(html); const $ = flattenDom(html, filepath); @@ -306,6 +307,14 @@ export class CustomLiquid extends Liquid { 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(); + + // Replace acknowledgements with pinned content for older versions + if (process.env.WCAG_VERSION && $("section#acknowledgements").length) { + const pinnedAcknowledgements = await getAcknowledgementsForVersion(scope.version); + for (const [id, content] of Object.entries(pinnedAcknowledgements)) { + $(`#${id} h3 +`).html(content); + } + } } else { const $title = $("title"); @@ -399,7 +408,7 @@ export class CustomLiquid extends Liquid { // 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) => { + const extractTermName = ($el: CheerioAnyNode) => { const name = $el .text() .toLowerCase() @@ -424,7 +433,7 @@ export class CustomLiquid extends Liquid { }); } else if (scope.isUnderstanding) { const $termsList = $("section#key-terms dl"); - const extractTermNames = ($links: Cheerio) => + const extractTermNames = ($links: CheerioAnyNode) => compact(uniq($links.toArray().map((el) => extractTermName($(el))))); if ($termLinks.length) { @@ -494,7 +503,8 @@ export class CustomLiquid extends Liquid { // (This is also needed for techniques/about) $("div.note").each((_, el) => { const $el = $(el); - $el.replaceWith(`
+ const classes = el.attribs.class; + $el.replaceWith(`

Note

${$el.html()}
`); @@ -502,12 +512,13 @@ export class CustomLiquid extends Liquid { // Handle p variant after div (the reverse would double-process) $("p.note").each((_, el) => { const $el = $(el); - $el.replaceWith(`
+ const classes = el.attribs.class; + $el.replaceWith(`

Note

${$el.html()}

`); }); - + // Add header to example sections in Key Terms (aside) and Conformance (div) $("aside.example, div.example").each((_, el) => { const $el = $(el); @@ -520,13 +531,19 @@ export class CustomLiquid extends Liquid { // Handle new-in-version content $("[class^='wcag']").each((_, el) => { // Just like the XSLT process, this naively assumes that version numbers are the same length - const classVersion = +el.attribs.class.replace(/^wcag/, ""); - const buildVersion = +scope.version; + const classMatch = el.attribs.class.match(/\bwcag(\d\d)\b/); + if (!classMatch) throw new Error(`Invalid wcagXY class found: ${el.attribs.class}`); + const classVersion = +classMatch[1]; if (isNaN(classVersion)) throw new Error(`Invalid wcagXY class found: ${el.attribs.class}`); + const buildVersion = +scope.version; + if (classVersion > buildVersion) { $(el).remove(); } else if (classVersion === buildVersion) { - $(el).prepend(`New in WCAG ${scope.versionDecimal}: `); + if (/\bnote\b/.test(el.attribs.class)) + $(el).find(".marker").append(` (new in WCAG ${scope.versionDecimal})`); + else + $(el).prepend(`New in WCAG ${scope.versionDecimal}: `); } // Output as-is if content pertains to a version older than what's being built }); @@ -540,6 +557,21 @@ export class CustomLiquid extends Liquid { }); } + // Link biblio references + if (scope.isUnderstanding) { + $("p").each((_, el) => { + const $el = $(el); + const html = $el.html(); + if (html && biblioPattern.test(html)) { + $el.html( + html.replace(biblioPattern, (substring, code) => + biblio[code]?.href ? `[${code}]` : substring + ) + ); + } + }); + } + // Allow autogenerating missing top-level section IDs in understanding docs, // but don't pick up incorrectly-nested sections in some techniques pages (e.g. H91) const sectionSelector = scope.isUnderstanding ? "section" : "section[id]:not(.obsolete)"; diff --git a/11ty/README.md b/11ty/README.md index 168db395e5..a1b7d063b2 100644 --- a/11ty/README.md +++ b/11ty/README.md @@ -49,12 +49,17 @@ but may be useful if you're not seeing what you expect in the output files. ### `WCAG_VERSION` -**Usage context:** currently this should not be changed, pending future improvements to `21` support +**Usage context:** for building older versions of techniques and understanding docs Indicates WCAG version being built, in `XY` format (i.e. no `.`). -Influences base URLs for links to guidelines, techniques, and understanding pages. - -**Default:** `22` +Influences which pages get included, guideline/SC content, +and a few details within pages (e.g. titles/URLs, "New in ..." content). +Also influences base URLs for links to guidelines, techniques, and understanding pages. +Explicitly setting this causes the build to reference guidelines and acknowledgements +published under `w3.org/TR/WCAG{version}`, rather than using the local checkout +(which is effectively the 2.2 Editors' Draft). + +Possible values: `22`, `21` ### `WCAG_MODE` diff --git a/11ty/biblio.ts b/11ty/biblio.ts new file mode 100644 index 0000000000..24a809fdb8 --- /dev/null +++ b/11ty/biblio.ts @@ -0,0 +1,35 @@ +import axios from "axios"; +import { readFile } from "fs/promises"; +import { glob } from "glob"; +import uniq from "lodash-es/uniq"; + +export const biblioPattern = /\[\[\??([\w-]+)\]\]/g; + +/** Compiles URLs from local biblio + specref for linking in Understanding documents. */ +export async function getBiblio() { + const localBiblio = eval( + (await readFile("biblio.js", "utf8")) + .replace(/^respecConfig\.localBiblio\s*=\s*/, "(") + .replace("};", "})") + ); + + const refs: string[] = []; + for (const path of await glob(["guidelines/**/*.html", "understanding/*/*.html"])) { + const content = await readFile(path, "utf8"); + let match; + while ((match = biblioPattern.exec(content))) if (!localBiblio[match[1]]) refs.push(match[1]); + } + const uniqueRefs = uniq(refs); + + const response = await axios.get(`https://api.specref.org/bibrefs?refs=${uniqueRefs.join(",")}`); + const fullBiblio = { + ...response.data, + ...localBiblio, + }; + + const resolvedRefs = Object.keys(fullBiblio); + const unresolvedRefs = uniqueRefs.filter((ref) => !resolvedRefs.includes(ref)); + if (unresolvedRefs.length) console.warn(`Unresolved biblio refs: ${unresolvedRefs.join(", ")}`); + + return fullBiblio; +} diff --git a/11ty/cheerio.ts b/11ty/cheerio.ts index f1292be14b..72f3c65008 100644 --- a/11ty/cheerio.ts +++ b/11ty/cheerio.ts @@ -5,6 +5,9 @@ import { dirname, resolve } from "path"; export { load } from "cheerio"; +/** Superset of the type returned by any Cheerio $() call. */ +export type CheerioAnyNode = ReturnType>; + /** Convenience function that combines readFile and load. */ export const loadFromFile = async ( inputPath: string, diff --git a/11ty/guidelines.ts b/11ty/guidelines.ts index 08c4ec1c3e..cbdc084bcb 100644 --- a/11ty/guidelines.ts +++ b/11ty/guidelines.ts @@ -1,10 +1,11 @@ -import type { Cheerio, Element } from "cheerio"; +import axios from "axios"; +import type { CheerioAPI } from "cheerio"; import { glob } from "glob"; import { readFile } from "fs/promises"; import { basename } from "path"; -import { flattenDomFromFile, load } from "./cheerio"; +import { flattenDomFromFile, load, type CheerioAnyNode } from "./cheerio"; import { generateId } from "./common"; export type WcagVersion = "20" | "21" | "22"; @@ -34,40 +35,21 @@ export const actRules = ( )["act-rules"]; /** - * Returns an object with keys for each existing WCAG 2 version, - * each mapping to an array of basenames of HTML files under understanding/ - * (Functionally equivalent to "guidelines-versions" target in build.xml) + * Flattened object hash, mapping each WCAG 2 SC slug to the earliest WCAG version it applies to. + * (Functionally equivalent to "guidelines-versions" target in build.xml; structurally inverted) */ -export async function getGuidelinesVersions() { +const scVersions = await (async function () { const paths = await glob("*/*.html", { cwd: "understanding" }); - const versions: Record = { "20": [], "21": [], "22": [] }; + const map: Record = {}; for (const path of paths) { - const [version, filename] = path.split("/"); - assertIsWcagVersion(version); - versions[version].push(basename(filename, ".html")); + const [fileVersion, filename] = path.split("/"); + assertIsWcagVersion(fileVersion); + map[basename(filename, ".html")] = fileVersion; } - for (const version of Object.keys(versions)) { - assertIsWcagVersion(version); - versions[version].sort(); - } - return versions; -} - -/** - * Like getGuidelinesVersions, but mapping each basename to the version it appears in - */ -export async function getInvertedGuidelinesVersions() { - const versions = await getGuidelinesVersions(); - const invertedVersions: Record = {}; - for (const [version, basenames] of Object.entries(versions)) { - for (const basename of basenames) { - invertedVersions[basename] = version; - } - } - return invertedVersions; -} + return map; +})(); export interface DocNode { id: string; @@ -79,7 +61,7 @@ export interface DocNode { export interface Principle extends DocNode { content: string; num: `${number}`; // typed as string for consistency with guidelines/SC - version: "WCAG20"; + version: "20"; guidelines: Guideline[]; type: "Principle"; } @@ -87,7 +69,7 @@ export interface Principle extends DocNode { export interface Guideline extends DocNode { content: string; num: `${Principle["num"]}.${number}`; - version: `WCAG${"20" | "21"}`; + version: "20" | "21"; successCriteria: SuccessCriterion[]; type: "Guideline"; } @@ -97,7 +79,7 @@ export interface SuccessCriterion extends DocNode { num: `${Guideline["num"]}.${number}`; /** Level may be empty for obsolete criteria */ level: "A" | "AA" | "AAA" | ""; - version: `WCAG${WcagVersion}`; + version: WcagVersion; type: "SC"; } @@ -105,42 +87,55 @@ export function isSuccessCriterion(criterion: any): criterion is SuccessCriterio return !!(criterion?.type === "SC" && "level" in criterion); } +/** Version-dependent overrides of SC shortcodes for older versions */ +export const scSlugOverrides: Record string> = { + "target-size-enhanced": (version) => (version < "22" ? "target-size" : "target-size-enhanced"), +}; + +/** Selectors ignored when capturing content of each Principle / Guideline / SC */ +const contentIgnores = [ + "h1, h2, h3, h4, h5, h6", + "section", + ".change", + ".conformance-level", + // Selectors below are specific to pre-published guidelines (for previous versions) + ".header-wrapper", + ".doclinks", +]; + /** - * Returns HTML content used for Understanding guideline/SC boxes. + * Returns HTML content used for Understanding guideline/SC boxes and term definitions. * @param $el Cheerio element of the full section from flattened guidelines/index.html */ -const getContentHtml = ($el: Cheerio) => { +const getContentHtml = ($el: CheerioAnyNode) => { // Load HTML into a new instance, remove elements we don't want, then return the remainder const $ = load($el.html()!, null, false); - $("h1, h2, h3, h4, h5, h6, section, .change, .conformance-level").remove(); - return $.html(); + $(contentIgnores.join(", ")).remove(); + return $.html().trim(); }; -/** - * Resolves information from guidelines/index.html; - * comparable to the principles section of wcag.xml from the guidelines-xml Ant task. - */ -export async function getPrinciples() { - const versions = await getInvertedGuidelinesVersions(); - const $ = await flattenDomFromFile("guidelines/index.html"); - +/** Performs processing common across WCAG versions */ +function processPrinciples($: CheerioAPI) { const principles: Principle[] = []; $(".principle").each((i, el) => { const guidelines: Guideline[] = []; - $(".guideline", el).each((j, guidelineEl) => { + $("> .guideline", el).each((j, guidelineEl) => { const successCriteria: SuccessCriterion[] = []; - $(".sc", guidelineEl).each((k, scEl) => { - const resolvedVersion = versions[scEl.attribs.id]; - assertIsWcagVersion(resolvedVersion); - + // Source uses sc class, published uses guideline class (again) + $("> .guideline, > .sc", guidelineEl).each((k, scEl) => { + const scId = scEl.attribs.id; successCriteria.push({ content: getContentHtml($(scEl)), - id: scEl.attribs.id, + id: scId, name: $("h4", scEl).text().trim(), num: `${i + 1}.${j + 1}.${k + 1}`, - level: $("p.conformance-level", scEl).text().trim() as SuccessCriterion["level"], + // conformance-level contains only letters in source, full (Level ...) in publish + level: $("p.conformance-level", scEl) + .text() + .trim() + .replace(/^\(Level (.*)\)$/, "$1") as SuccessCriterion["level"], type: "SC", - version: `WCAG${resolvedVersion}`, + version: scVersions[scId], }); }); @@ -150,7 +145,7 @@ export async function getPrinciples() { name: $("h3", guidelineEl).text().trim(), num: `${i + 1}.${j + 1}`, type: "Guideline", - version: guidelineEl.attribs.id === "input-modalities" ? "WCAG21" : "WCAG20", + version: guidelineEl.attribs.id === "input-modalities" ? "21" : "20", successCriteria, }); }); @@ -161,7 +156,7 @@ export async function getPrinciples() { name: $("h2", el).text().trim(), num: `${i + 1}`, type: "Principle", - version: "WCAG20", + version: "20", guidelines, }); }); @@ -169,6 +164,13 @@ export async function getPrinciples() { return principles; } +/** + * Resolves information from guidelines/index.html; + * comparable to the principles section of wcag.xml from the guidelines-xml Ant task. + */ +export const getPrinciples = async () => + processPrinciples(await flattenDomFromFile("guidelines/index.html")); + /** * Returns a flattened object hash, mapping shortcodes to each principle/guideline/SC. */ @@ -225,3 +227,62 @@ export async function getTermsMap() { return terms; } + +// Version-specific APIs + +const remoteGuidelines$: Partial> = {}; + +/** Loads guidelines from TR space for specific version, caching for future calls. */ +const loadRemoteGuidelines = async (version: WcagVersion) => { + if (!remoteGuidelines$[version]) { + const $ = load( + (await axios.get(`https://www.w3.org/TR/WCAG${version}/`, { responseType: "text" })).data + ); + + // Re-collapse definition links and notes, to be processed by this build system + $(".guideline a.internalDFN").removeAttr("class data-link-type id href title"); + $(".guideline [role='note'] .marker").remove(); + $(".guideline [role='note']").find("> div, > p").addClass("note").unwrap(); + + // Bibliography references are not processed in Understanding SC boxes + $(".guideline cite:has(a.bibref:only-child)").each((_, el) => { + const $el = $(el); + const $parent = $el.parent(); + $el.remove(); + // Remove surrounding square brackets (which aren't in a dedicated element) + $parent.html($parent.html()!.replace(/ \[\]/g, "")); + }); + + // Remove extra markup from headings so they can be parsed for names + $("bdi").remove(); + + // Remove abbr elements which exist only in TR, not in informative docs + $("#acknowledgements li abbr").each((_, abbrEl) => { + $(abbrEl).replaceWith($(abbrEl).text()); + }); + + remoteGuidelines$[version] = $; + } + return remoteGuidelines$[version]!; +}; + +/** + * Retrieves heading and content information for acknowledgement subsections, + * for preserving the section in About pages for earlier versions. + */ +export const getAcknowledgementsForVersion = async (version: WcagVersion) => { + const $ = await loadRemoteGuidelines(version); + const subsections: Record = {}; + + $("section#acknowledgements section").each((_, el) => { + subsections[el.attribs.id] = $(".header-wrapper + *", el).html()!; + }); + + return subsections; +}; + +/** + * Retrieves and processes a pinned WCAG version using published guidelines. + */ +export const getPrinciplesForVersion = async (version: WcagVersion) => + processPrinciples(await loadRemoteGuidelines(version)); diff --git a/11ty/techniques.ts b/11ty/techniques.ts index 94820e7784..fcfd5dd1f6 100644 --- a/11ty/techniques.ts +++ b/11ty/techniques.ts @@ -199,7 +199,7 @@ export interface Technique extends TechniqueFrontMatter { * Used to generate index table of contents. * (Functionally equivalent to "techniques-list" target in build.xml) */ -export async function getTechniquesByTechnology() { +export async function getTechniquesByTechnology(guidelines: FlatGuidelinesMap) { const paths = await glob("*/*.html", { cwd: "techniques" }); const techniques = technologies.reduce( (map, technology) => ({ @@ -208,6 +208,9 @@ export async function getTechniquesByTechnology() { }), {} as Record ); + const scNumbers = Object.values(guidelines) + .filter((entry): entry is SuccessCriterion => entry.type === "SC") + .map(({ num }) => num); // Check directory data files (we don't have direct access to 11ty's data cascade here) const technologyData: Partial> = {}; @@ -237,13 +240,37 @@ export async function getTechniquesByTechnology() { if (!h1Match || !h1Match[1]) throw new Error(`No h1 found in techniques/${path}`); const $h1 = load(h1Match[1], null, false); - const title = $h1.text(); + let title = $h1.text(); + let titleHtml = $h1.html(); + if (process.env.WCAG_VERSION) { + // Check for invalid SC references for the WCAG version being built + const multiScPattern = /(?:\d\.\d+\.\d+(,?) )+and \d\.\d+\.\d+/; + if (multiScPattern.test(title)) { + const scPattern = /\d\.\d+\.\d+/g; + const criteria: typeof scNumbers = []; + let match; + while ((match = scPattern.exec(title))) + criteria.push(match[0] as `${number}.${number}.${number}`); + const filteredCriteria = criteria.filter((sc) => scNumbers.includes(sc)); + if (filteredCriteria.length) { + const finalSeparator = + filteredCriteria.length > 2 && multiScPattern.exec(title)?.[1] ? "," : ""; + const replacement = `${filteredCriteria.slice(0, -1).join(", ")}${finalSeparator} and ${ + filteredCriteria[filteredCriteria.length - 1] + }`; + title = title.replace(multiScPattern, replacement); + titleHtml = titleHtml.replace(multiScPattern, replacement); + } + // If all SCs were filtered out, do nothing - should be pruned when associations are checked + } + } + techniques[technology].push({ ...data, // Include front-matter id: basename(filename, ".html"), technology, title, - titleHtml: $h1.html(), + titleHtml, truncatedTitle: title.replace(/\s*\n[\s\S]*\n\s*/, " … "), }); } diff --git a/11ty/understanding.ts b/11ty/understanding.ts index c9b414b63f..1379b1915c 100644 --- a/11ty/understanding.ts +++ b/11ty/understanding.ts @@ -24,11 +24,11 @@ export async function getUnderstandingDocs(version: WcagVersion): Promise
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..f19fd6edf6 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..806455d470 100644 --- a/guidelines/sc/20/error-prevention-all.html +++ b/guidelines/sc/20/error-prevention-all.html @@ -4,13 +4,13 @@

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:

Reversible
Submissions are reversible.
-
Checked
Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
-
Confirmed
A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
+
Checked
Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
+
Confirmed
A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
diff --git a/guidelines/sc/20/error-prevention-legal-financial-data.html b/guidelines/sc/20/error-prevention-legal-financial-data.html index 0059cff558..9cc096a0a4 100644 --- a/guidelines/sc/20/error-prevention-legal-financial-data.html +++ b/guidelines/sc/20/error-prevention-legal-financial-data.html @@ -4,14 +4,14 @@

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:

Reversible
Submissions are reversible.
-
Checked
Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
-
Confirmed
A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
+
Checked
Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
+
Confirmed
A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
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/focus-visible.html b/guidelines/sc/20/focus-visible.html index ca4d3a7f90..3421e5154c 100644 --- a/guidelines/sc/20/focus-visible.html +++ b/guidelines/sc/20/focus-visible.html @@ -4,8 +4,7 @@

Focus Visible

AA

-

Any keyboard operable user interface has a mode of operation where the keyboard focus - indicator is visible. +

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

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/language-of-parts.html b/guidelines/sc/20/language-of-parts.html index 52425fc1cf..839c12ab26 100644 --- a/guidelines/sc/20/language-of-parts.html +++ b/guidelines/sc/20/language-of-parts.html @@ -6,7 +6,7 @@

Language of Parts

The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding - text. + text.

diff --git a/guidelines/sc/20/link-purpose-link-only.html b/guidelines/sc/20/link-purpose-link-only.html index e14105120f..5780c41e74 100644 --- a/guidelines/sc/20/link-purpose-link-only.html +++ b/guidelines/sc/20/link-purpose-link-only.html @@ -4,7 +4,7 @@

Link Purpose (Link Only)

AAA

-

A mechanism is available to allow the purpose of each link to be identified from link text alone, +

A mechanism is available to allow the purpose of each link to be identified from link text alone, except where the purpose of the link would be ambiguous to users in general.

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..4993e907e8 100644 --- a/guidelines/sc/20/name-role-value.html +++ b/guidelines/sc/20/name-role-value.html @@ -5,10 +5,10 @@

Name, Role, Value

A

For all user interface components (including but not limited to: form elements, links and components generated by scripts), - 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. + 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..b3268e313f 100644 --- a/guidelines/sc/20/pause-stop-hide.html +++ b/guidelines/sc/20/pause-stop-hide.html @@ -15,7 +15,7 @@

Pause, Stop, Hide

For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, - there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity + there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and

@@ -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/reading-level.html b/guidelines/sc/20/reading-level.html index e3db6ab59e..f3a227a92e 100644 --- a/guidelines/sc/20/reading-level.html +++ b/guidelines/sc/20/reading-level.html @@ -4,7 +4,7 @@

Reading Level

AAA

-

When text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower +

When text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower secondary education level, is available.

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/20/timing-adjustable.html b/guidelines/sc/20/timing-adjustable.html index d058e6111f..cb371fa19b 100644 --- a/guidelines/sc/20/timing-adjustable.html +++ b/guidelines/sc/20/timing-adjustable.html @@ -41,7 +41,7 @@

Timing Adjustable

-

The time limit is a required part of a real-time event (for example, an auction), +

The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or

diff --git a/guidelines/sc/20/visual-presentation.html b/guidelines/sc/20/visual-presentation.html index 6ecf932f34..8ed371b5c5 100644 --- a/guidelines/sc/20/visual-presentation.html +++ b/guidelines/sc/20/visual-presentation.html @@ -11,7 +11,7 @@

Visual Presentation

  • Width is no more than 80 characters or glyphs (40 if CJK).
  • Text is not justified (aligned to both the left and the right margins).
  • Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.
    • -
  • Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.
    • +
  • Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.

    • Content is not required to use these values. The requirement is that a mechanism is available for users to change these presentation aspects. The mechanism can be provided by the browser or other user agent. Content is not required to provide the mechanism.

    diff --git a/guidelines/sc/21/content-on-hover-or-focus.html b/guidelines/sc/21/content-on-hover-or-focus.html index 3ad861e109..0eb2c10e77 100644 --- a/guidelines/sc/21/content-on-hover-or-focus.html +++ b/guidelines/sc/21/content-on-hover-or-focus.html @@ -19,7 +19,7 @@

    Content on Hover or Focus

    -

    Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.

    +

    Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.

    Examples of additional content controlled by the user agent include browser tooltips created through use of the HTML title attribute [[HTML]].

    Custom tooltips, sub-menus, and other nonmodal popups that display on hover and focus are examples of additional content covered by this criterion.

    diff --git a/guidelines/sc/21/non-text-contrast.html b/guidelines/sc/21/non-text-contrast.html index 777c521d4e..1b4d3602a3 100644 --- a/guidelines/sc/21/non-text-contrast.html +++ b/guidelines/sc/21/non-text-contrast.html @@ -10,7 +10,7 @@

    Non-text Contrast

    User Interface Components
    -
    Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;
    +
    Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;
    Graphical Objects
    diff --git a/guidelines/sc/21/reflow.html b/guidelines/sc/21/reflow.html index 8fbc922719..5606d0e00a 100644 --- a/guidelines/sc/21/reflow.html +++ b/guidelines/sc/21/reflow.html @@ -11,7 +11,7 @@

    Reflow

    Except for parts of the content which require two-dimensional layout for usage or meaning.

    -

    320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom. For web content which is designed to scroll horizontally (e.g., with vertical text), 256 CSS pixels is equivalent to a starting viewport height of 1024 CSS pixels at 400% zoom.

    +

    320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom. For web content which is designed to scroll horizontally (e.g., with vertical text), 256 CSS pixels is equivalent to a starting viewport height of 1024 CSS pixels at 400% zoom.

    Examples of content which requires two-dimensional layout are images required for understanding (such as maps and diagrams), video, games, presentations, data tables (not individual cells), and interfaces where it is necessary to keep toolbars in view while manipulating content. It is acceptable to provide two-dimensional scrolling for such parts of the content.

    diff --git a/guidelines/sc/21/target-size-enhanced.html b/guidelines/sc/21/target-size-enhanced.html index c83046b2a7..30c5b5886c 100644 --- a/guidelines/sc/21/target-size-enhanced.html +++ b/guidelines/sc/21/target-size-enhanced.html @@ -9,11 +9,11 @@

    Target Size (Enhanced)

    Equivalent
    The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;
    Inline
    -
    The target is in a sentence or block of text;
    +
    The target is in a sentence or block of text;
    User Agent Control
    -
    The size of the target is determined by the user agent and is not modified by the author;
    +
    The size of the target is determined by the user agent and is not modified by the author;
    Essential
    -
    A particular presentation of the target is essential to the information being conveyed.
    +
    A particular presentation of the target is essential to the information being conveyed.
    diff --git a/guidelines/sc/21/text-spacing.html b/guidelines/sc/21/text-spacing.html index 7774996f19..eaf37f1b5d 100644 --- a/guidelines/sc/21/text-spacing.html +++ b/guidelines/sc/21/text-spacing.html @@ -13,7 +13,7 @@

    Text Spacing

  • Word spacing to at least 0.16 times the font size.
    • -

    Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

    +

    Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

    Content is not required to use these text spacing values. The requirement is to ensure that when a user overrides the authored text spacing, content or functionality is not lost.

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

    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.

    Examples of mechanisms that satisfy this criterion include: -
      +
      • support for password entry by password managers to reduce memory need, and
      • copy and paste to reduce the cognitive burden of re-typing.
        • -
    +
    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/sc/22/target-size-minimum.html b/guidelines/sc/22/target-size-minimum.html index 81675f3ebe..a1b64321e4 100644 --- a/guidelines/sc/22/target-size-minimum.html +++ b/guidelines/sc/22/target-size-minimum.html @@ -3,17 +3,22 @@

    Target Size (Minimum)

    AA

    -

    New

    +

    New

    -

    The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:

    -
      -
    • Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target;
      • -
    • Equivalent: The function can be achieved through a different control on the same page that meets this criterion;
      • -
    • Inline: The target is in a sentence or its size is otherwise constrained by the line-height of non-target text;
      • -
    • User agent control: The size of the target is determined by the user agent and is not modified by the author;
      • -
    • Essential: A particular presentation of the target is essential or is legally required for the information being conveyed.
      • -
    +

    The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except when:

    +
    +
    Spacing
    +
    Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target;
    +
    Equivalent
    +
    The function can be achieved through a different control on the same page that meets this criterion;
    +
    Inline
    +
    The target is in a sentence or its size is otherwise constrained by the line-height of non-target text;
    +
    User Agent Control
    +
    The size of the target is determined by the user agent and is not modified by the author;
    +
    Essential
    +
    A particular presentation of the target is essential or is legally required for the information being conveyed.
    +

    Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders, color pickers displaying a gradient of colors, or editable areas where you position the cursor.

    For inline targets the line-height should be interpreted as perpendicular to the flow of text. For example, in a language displayed vertically, the line-height would be horizontal.

    - + 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/blocks-of-text.html b/guidelines/terms/20/blocks-of-text.html index 1b85e3dc14..46286158ad 100644 --- a/guidelines/terms/20/blocks-of-text.html +++ b/guidelines/terms/20/blocks-of-text.html @@ -1,6 +1,6 @@ -
    blocks of text
    +
    blocks of text
    -

    more than one sentence of text

    +

    more than one sentence of text

    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 @@ -
    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..be6ed61a9e 100644 --- a/guidelines/terms/20/general-flash-and-red-flash-thresholds.html +++ b/guidelines/terms/20/general-flash-and-red-flash-thresholds.html @@ -4,7 +4,7 @@

    a flash or rapidly changing image sequence is below the threshold (i.e., content passes) if any of the following are true:

    -
      +
      • there are no more than three general flashes and / or no more than three red flashes within any one-second period; or
        • @@ -14,7 +14,7 @@ degree visual field on the screen) at typical viewing distance -
    +

    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/human-language.html b/guidelines/terms/20/human-language.html index 17cc924943..78b05c0576 100644 --- a/guidelines/terms/20/human-language.html +++ b/guidelines/terms/20/human-language.html @@ -1,4 +1,4 @@ -

    human language
    +
    human language

    language that is spoken, written or signed (through visual or tactile means) to communicate diff --git a/guidelines/terms/20/image-of-text.html b/guidelines/terms/20/image-of-text.html index ddf784c34a..375662a4c1 100644 --- a/guidelines/terms/20/image-of-text.html +++ b/guidelines/terms/20/image-of-text.html @@ -1,11 +1,11 @@

    image of text
    -

    text that has been rendered in a non-text form (e.g., an image) in order to achieve +

    text that has been rendered in a non-text form (e.g., an image) in order to achieve a particular visual effect

    -

    This does not include text that is part of a picture that contains significant other visual content. +

    This does not include text that is part of a picture that contains significant other visual content.

    diff --git a/guidelines/terms/20/input-error.html b/guidelines/terms/20/input-error.html index 1febee2c75..31e3b63118 100644 --- a/guidelines/terms/20/input-error.html +++ b/guidelines/terms/20/input-error.html @@ -1,4 +1,4 @@ -
    input error
    +
    input error

    information provided by the user that is not accepted

    @@ -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/non-text-content.html b/guidelines/terms/20/non-text-content.html index 612b94689b..76dfc84d6a 100644 --- a/guidelines/terms/20/non-text-content.html +++ b/guidelines/terms/20/non-text-content.html @@ -3,7 +3,7 @@

      any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language

      -

      This includes ASCII Art (which is a pattern of characters), emoticons, leetspeak (which uses character substitution), +

      This includes ASCII art (which is a pattern of characters), emoticons, leetspeak (which uses character substitution), and images representing text

      diff --git a/guidelines/terms/20/on-a-full-screen-window.html b/guidelines/terms/20/on-a-full-screen-window.html index 61de699593..d79dc7fd97 100644 --- a/guidelines/terms/20/on-a-full-screen-window.html +++ b/guidelines/terms/20/on-a-full-screen-window.html @@ -1,7 +1,7 @@
      on a full-screen window
      -

      on the most common sized desktop/laptop display with the viewport maximized

      +

      on the most common sized desktop/laptop display with the viewport maximized

      Since people generally keep their computers for several years, it is best not to rely on the latest desktop/laptop display resolutions but to consider the common desktop/laptop 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

      -

    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