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/workflows/11ty-publish.yaml b/.github/workflows/11ty-publish.yaml new file mode 100644 index 0000000000..adbb274be0 --- /dev/null +++ b/.github/workflows/11ty-publish.yaml @@ -0,0 +1,45 @@ +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 (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/.gitignore b/.gitignore index c23c97841c..598250a1d5 100644 --- a/.gitignore +++ b/.gitignore @@ -220,3 +220,28 @@ pip-log.txt ############# build.properties + +####### +## Node +####### + +node_modules/ + +############# +## Output +############# + +/output/ +/output.html +/techniques/toc.html +/techniques/techniques.xml +/techniques/technique-associations.xml +/techniques/index-flat.html +/techniques/about-flat.html +/understanding/toc.html +/understanding/index-flat.html +/understanding/about-flat.html +/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/.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/.travis.yml b/.travis.yml deleted file mode 100644 index 79c0284299..0000000000 --- a/.travis.yml +++ /dev/null @@ -1,28 +0,0 @@ -language: java -env: - global: - - GH_REF: github.com/w3c/wcag.git - -git: - depth: 3 - -before_install: - - tar -xzvf lib/apache-ant-1.10.6-bin.tar.gz - - export PATH=`pwd`/apache-ant-1.10.6/bin:$PATH - -script: - - 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/master/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/master/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/master/conformance-challenges/index.html -o output/conformance-challenges/index.html -f --retry 3 - - ant deploy - -deploy: - provider: pages - skip-cleanup: true - github-token: $GITHUB_TOKEN - keep-history: true - local-dir: output - on: - branch: master 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) { + const href = $el.attr("href"); + if (!href) throw new Error("expandTechniqueLink: non-link element encountered"); + const id = resolveTechniqueIdFromHref(href); + // id will be empty string for links to index, which we don't need to modify + if (id) $el.replaceWith(`{{ "${id}" | linkTechniques }}`); +} + +const stripHtmlComments = (html: string) => html.replace(//g, ""); + +// Dev note: Eleventy doesn't expose typings for its template engines for us to neatly extend. +// Fortunately, it passes both the content string and the file path through to Liquid#parse: +// https://github.com/11ty/eleventy/blob/9c3a7619/src/Engines/Liquid.js#L253 + +/** + * Liquid class extension that adds support for parts of the existing build process: + * - flattening data-include directives prior to parsing Liquid tags + * (permitting Liquid even inside data-included files) + * - inserting header/footer content within the body of pages + * - generating/expanding sections with auto-generated content + */ +export class CustomLiquid extends Liquid { + public parse(html: string, filepath?: string) { + // Filter out Liquid calls for computed data and includes themselves + if (filepath && !filepath.includes("_includes/") && isHtmlFileContent(html)) { + 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); + + // Clean out elements to be removed + // (e.g. editors.css & sources.css, and leftover template paragraphs) + // NOTE: some paragraphs with the "instructions" class actually have custom content, + // but for now this remains consistent with the XSLT process by stripping all of them. + $(".remove, p.instructions, section#meta, section.meta").remove(); + + const prependedIncludes = ["header"]; + const appendedIncludes = ["wai-site-footer", "site-footer"]; + + if (isUnderstanding) + prependedIncludes.push( + isIndex ? "understanding/navigation-index" : "understanding/navigation" + ); + + if (isIndex) { + if (isTechniques) $("section#changelog li a").each((_, el) => expandTechniqueLink($(el))); + } else { + $("head").append(generateIncludes("head")); + appendedIncludes.push("waiscript"); + + // Remove resources section if it only has a placeholder item + const $resourcesOnlyItem = $("section#resources li:only-child"); + if ( + $resourcesOnlyItem.length && + ($resourcesOnlyItem.html() === "Resource" || $resourcesOnlyItem.html() === "Link") + ) + $("section#resources").remove(); + + // Fix incorrect level-2 and first-child level-3 headings + // (avoid changing h3s that are appropriate but aren't nested within a subsection) + $("body > section section h2").each((_, el) => { + el.tagName = "h3"; + }); + $("body > section > h3:first-child").each((_, el) => { + el.tagName = "h2"; + }); + + if (isTechniques) { + // Expand related technique links to include full title + // (the XSLT process didn't handle this in this particular context) + const siblingCode = basename(filepath).replace(/^([A-Z]+).*$/, "$1"); + $("section#related li") + .find(`a[href^='../'], a[href^=${siblingCode}]`) + .each((_, el) => expandTechniqueLink($(el))); + + // XSLT orders related and tests last, but they are not last in source files + $("body") + .append("\n", $(`body > section#related`)) + .append("\n", $(`body > section#tests`)); + + $("h1") + .after(generateIncludes("techniques/about")) + .replaceWith(generateIncludes("techniques/h1")); + + const sectionCounts: Record = {}; + let hasDuplicates = false; + $("body > section[id]").each((_, el) => { + const id = el.attribs.id.toLowerCase(); + // Fix non-lowercase top-level section IDs (e.g. H99) + el.attribs.id = id; + // Track duplicate sections, to be processed next + if (id in sectionCounts) { + hasDuplicates = true; + sectionCounts[id]++; + } else { + sectionCounts[id] = 1; + } + }); + + // Avoid loop altogether in majority of (correct) cases + if (hasDuplicates) { + for (const [id, count] of Object.entries(sectionCounts)) { + if (count === 1) continue; + console.warn( + `${filepath}: Merging duplicate ${id} sections; please fix this in the source file.` + ); + const $sections = $(`section[id='${id}']`); + const $first = $sections.first(); + $sections.each((i, el) => { + if (i === 0) return; + const $el = $(el); + $el.find("> h2:first-child").remove(); + $first.append($el.contents()); + $el.remove(); + }); + } + } + + $("section#resources h2").after(generateIncludes("techniques/intro/resources")); + $("section#examples section.example").each((i, el) => { + const $el = $(el); + const exampleText = `Example ${i + 1}`; + // Check for multiple h3 under one example, which should be h4 (e.g. SCR33) + $el.find("h3:not(:only-of-type)").each((_, el) => { + el.tagName = "h4"; + }); + + const $h3 = $el.find("h3"); + if ($h3.length) { + const h3Text = $h3.text(); // Used for comparisons below + // Some examples really have an empty h3... + if (!h3Text) $h3.text(exampleText); + // Only prepend "Example N: " if it won't be redundant (e.g. C31, F83) + else if (!/example \d+$/i.test(h3Text) && !/^example \d+/i.test(h3Text)) + $h3.prepend(`${exampleText}: `); + } else { + $el.prepend(`

${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) => { + const name = $el + .text() + .toLowerCase() + .trim() + .replace(/\s*\n+\s*/, " "); + const term = termsMap[name]; + if (!term) { + console.warn(`${scope.page.inputPath}: Term not found: ${name}`); + return; + } + // Return standardized name for Key Terms definition lists + return term.name; + }; + + if (scope.isTechniques) { + $termLinks.each((_, el) => { + const $el = $(el); + const termName = extractTermName($el); + $el + .attr("href", `${scope.guidelinesUrl}#${termName ? termsMap[termName].trId : ""}`) + .attr("target", "terms"); + }); + } else if (scope.isUnderstanding) { + const $termsList = $("section#key-terms dl"); + const extractTermNames = ($links: Cheerio) => + compact(uniq($links.toArray().map((el) => extractTermName($(el))))); + + if ($termLinks.length) { + let termNames = extractTermNames($termLinks); + // This is one loop but effectively multiple passes, + // since terms may reference other terms in their own definitions. + // Each iteration may append to termNames. + for (let i = 0; i < termNames.length; i++) { + const term = termsMap[termNames[i]]; + if (!term) continue; // This will already warn via extractTermNames + + const $definition = load(term.definition); + const $definitionTermLinks = $definition(termLinkSelector); + if ($definitionTermLinks.length) { + termNames = uniq(termNames.concat(extractTermNames($definitionTermLinks))); + } + } + + // Iterate over sorted names to populate alphabetized Key Terms definition list + termNames.sort((a, b) => { + if (a.toLowerCase() < b.toLowerCase()) return -1; + if (a.toLowerCase() > b.toLowerCase()) return 1; + return 0; + }); + for (const name of termNames) { + const term = termsMap[name]; // Already verified existence in the earlier loop + $termsList.append( + `
${term.name}
` + + `
${term.definition}
` + ); + } + + // Iterate over non-href links once more in now-expanded document to add hrefs + $(termLinkSelector).each((_, el) => { + const name = extractTermName($(el)); + el.attribs.href = `#${name ? termsMap[name].id : ""}`; + }); + } else { + // No terms: remove skeleton that was placed in #parse + $("section#key-terms").remove(); + } + } + + // Remove items that end up empty due to invalid technique IDs during #parse + // (e.g. removed/deprecated) + if (scope.isTechniques) { + $("section#related li:empty").remove(); + } else if (scope.isUnderstanding) { + // :empty doesn't work here since there may be whitespace + // (can't trim whitespace in the liquid tag since some links have more text after) + $(`section#techniques li`) + .filter((_, el) => !$(el).text().trim()) + .remove(); + + // Prepend guidelines base URL to non-dfn anchor links in guidelines-derived content + // (including both the guideline/SC box at the top and Key Terms at the bottom) + $("#guideline, #success-criterion, #key-terms") + .find("a[href^='#']:not([href^='#dfn-'])") + .each((_, el) => { + el.attribs.href = scope.guidelinesUrl + el.attribs.href; + }); + } + } + + // Expand note paragraphs after parsing and rendering, + // after Guideline/SC content for Understanding pages is rendered. + // (This is also needed for techniques/about) + $("div.note").each((_, el) => { + const $el = $(el); + $el.replaceWith(`
+

Note

+
${$el.html()}
+
`); + }); + // Handle p variant after div (the reverse would double-process) + $("p.note").each((_, el) => { + const $el = $(el); + $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); + $el.prepend(`

Example

`); + }); + + // We don't need to do any more processing for index/about pages other than stripping comments + if (indexPattern.test(scope.page.inputPath)) return stripHtmlComments($.html()); + + // 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; + if (isNaN(classVersion)) throw new Error(`Invalid wcagXY class found: ${el.attribs.class}`); + if (classVersion > buildVersion) { + $(el).remove(); + } else if (classVersion === buildVersion) { + $(el).prepend(`New in WCAG ${scope.versionDecimal}: `); + } + // Output as-is if content pertains to a version older than what's being built + }); + + if (!scope.isUnderstanding || scope.guideline) { + // Fix inconsistent heading labels + // (another pass is done on top of this for table of contents links below) + $("h2").each((_, el) => { + const $el = $(el); + $el.text(normalizeHeading($el.text())); + }); + } + + // 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)"; + const sectionH2Selector = "h2:first-child"; + const $h2Sections = $(`${sectionSelector}:has(${sectionH2Selector})`); + if ($h2Sections.length) { + // Generate table of contents after parsing and rendering, + // when we have sections and sidebar skeleton already reordered + const $tocList = $(".sidebar nav ul"); + $h2Sections.each((_, el) => { + if (!el.attribs.id) el.attribs.id = generateId($(el).find(sectionH2Selector).text()); + $("") + .attr("href", `#${el.attribs.id}`) + .text(normalizeTocLabel($(el).find(sectionH2Selector).text())) + .appendTo($tocList) + .wrap("
  • "); + $tocList.append("\n"); + }); + } else { + // Remove ToC sidebar that was added in #parse if there's nothing to list in it + $(".sidebar").remove(); + } + + // Autogenerate remaining IDs after constructing table of contents. + // NOTE: This may overwrite some IDs set in HTML (for techniques examples), + // and may result in duplicates; this is consistent with the XSLT process. + const sectionHeadingSelector = ["h3", "h4", "h5"] + .map((tag) => `> ${tag}:first-child`) + .join(", "); + const autoIdSectionSelectors = ["section:not([id])"]; + if (scope.isTechniques) autoIdSectionSelectors.push("section.example"); + $(autoIdSectionSelectors.join(", ")) + .filter(`:has(${sectionHeadingSelector})`) + .each((_, el) => { + el.attribs.id = generateId($(el).find(sectionHeadingSelector).text()); + }); + + return stripHtmlComments($.html()); + } +} diff --git a/11ty/README.md b/11ty/README.md new file mode 100644 index 0000000000..168db395e5 --- /dev/null +++ b/11ty/README.md @@ -0,0 +1,91 @@ +# Eleventy Infrastructure for WCAG Techniques and Understanding + +This subdirectory contains ES Modules re-implementing pieces of the +XSLT-based build process using Eleventy. + +## Usage + +Make sure you have Node.js installed. This has primarily been tested with v20, +the current LTS at time of writing. + +If you use [fnm](https://github.com/Schniz/fnm) or [nvm](https://github.com/nvm-sh/nvm) to manage multiple Node.js versions, +you can switch to the recommended version by typing `fnm use` or `nvm use` +(with no additional arguments) while in the repository directory. + +Otherwise, you can download an installer from [nodejs.org](https://nodejs.org/). + +First, run `npm i` in the root directory of the repository to install dependencies. + +Common tasks: + +- `npm run build` runs a one-time build +- `npm start` runs a local server with hot-reloading to preview changes as you make them: + - http://localhost:8080/techniques + - http://localhost:8080/understanding + +Maintenance tasks (for working with Eleventy config and supporting files under this subdirectory): + +- `npm run check` checks for TypeScript errors +- `npm run fmt` formats all TypeScript files + +## Environment Variables + +### `WCAG_CVSDIR` + +**Usage context:** `publish-w3c` script only + +Indicates top-level path of W3C CVS checkout, for WAI site updates (via `publish-w3c` script). + +**Default:** `../../../w3ccvs` (same as in Ant/XSLT build process) + +### `WCAG_VERBOSE` + +**Usage context:** Local development, debugging + +Prints more log messages that are typically noisy and uninteresting, +but may be useful if you're not seeing what you expect in the output files. + +**Default:** Unset (set to any non-empty value to enable) + +### `WCAG_VERSION` + +**Usage context:** currently this should not be changed, pending future improvements to `21` support + +Indicates WCAG version being built, in `XY` format (i.e. no `.`). +Influences base URLs for links to guidelines, techniques, and understanding pages. + +**Default:** `22` + +### `WCAG_MODE` + +**Usage context:** should not need to be set manually except in specific testing scenarios + +Influences base URLs for links to guidelines, techniques, and understanding pages. +Typically set by specific npm scripts or CI processes. + +Note that setting `WCAG_MODE` to any non-empty value (even one not listed below) will also result +in page footers referencing last modified times based on git, rather than the local filesystem. + +Possible values: + +- Unset **(default)** - Sets base URLs appropriate for local testing +- `editors` - Sets base URLs appropriate for `gh-pages` publishing; used by deploy action +- `publication` - Sets base URLs appropriate for WAI site publishing; used by `publish-w3c` script + +### `GITHUB_REPOSITORY` + +**Usage context:** Automatically set during GitHub workflows; should not need to be set manually + +Influences base URLs for links to guidelines, techniques, and understanding pages, +when `WCAG_MODE=editors` is also set. + +**Default:** `w3c/wcag` + +## Other points of interest + +- The main configuration can be found in top-level `eleventy.config.ts` +- Build commands are defined in top-level `package.json` under `scripts`, + and can be run via `npm run ` +- If you see files named `*.11tydata.*`, these contribute data to the Eleventy build + (see Template and Directory Data files under + [Sources of Data](https://www.11ty.dev/docs/data/#sources-of-data)) diff --git a/11ty/cheerio.ts b/11ty/cheerio.ts new file mode 100644 index 0000000000..f1292be14b --- /dev/null +++ b/11ty/cheerio.ts @@ -0,0 +1,64 @@ +import { load, type CheerioOptions } from "cheerio"; +import { readFileSync } from "fs"; +import { readFile } from "fs/promises"; +import { dirname, resolve } from "path"; + +export { load } from "cheerio"; + +/** Convenience function that combines readFile and load. */ +export const loadFromFile = async ( + inputPath: string, + options?: CheerioOptions | null, + isDocument?: boolean +) => load(await readFile(inputPath, "utf8"), options, isDocument); + +/** + * Retrieves content for a data-include, either from _includes, + * or relative to the input file. + * Operates synchronously for simplicity of use within Cheerio callbacks. + * + * @param includePath A data-include attribute value + * @param inputPath Path (relative to repo root) to file containing the directive + * @returns + */ +function readInclude(includePath: string, inputPath: string) { + const relativePath = resolve(dirname(inputPath), includePath); + if (includePath.startsWith("..")) return readFileSync(relativePath, "utf8"); + + try { + // Prioritize any match under _includes (e.g. over local toc.html built via XSLT) + return readFileSync(resolve("_includes", includePath), "utf8"); + } catch (error) { + return readFileSync(relativePath, "utf8"); + } +} + +/** + * Resolves data-include directives in the given file, a la flatten-document.xslt. + * This is a lower-level version for use in Eleventy configuration; + * you'd probably rather use flattenDomFromFile in other cases. + * + * @param content String containing HTML to process + * @param inputPath Path (relative to repo root) to file containing the HTML + * (needed for data-include resolution) + * @returns Cheerio instance containing "flattened" DOM + */ +export function flattenDom(content: string, inputPath: string) { + const $ = load(content); + + $("body [data-include]").each((_, el) => { + const replacement = readInclude(el.attribs["data-include"], inputPath); + // Replace entire element or children, depending on data-include-replace + if (el.attribs["data-include-replace"]) $(el).replaceWith(replacement); + else $(el).removeAttr("data-include").html(replacement); + }); + + return $; +} + +/** + * Convenience version of flattenDom that requires only inputPath to be passed. + * @see flattenDom + */ +export const flattenDomFromFile = async (inputPath: string) => + flattenDom(await readFile(inputPath, "utf8"), inputPath); diff --git a/11ty/common.ts b/11ty/common.ts new file mode 100644 index 0000000000..ade5d87f14 --- /dev/null +++ b/11ty/common.ts @@ -0,0 +1,30 @@ +/** @fileoverview Common functions used by multiple parts of the build process */ + +import type { Guideline, Principle, SuccessCriterion } from "./guidelines"; + +/** Generates an ID for heading permalinks. Equivalent to wcag:generate-id in base.xslt. */ +export function generateId(title: string) { + if (title === "Parsing (Obsolete and removed)") return "parsing"; + return title + .replace(/\s+/g, "-") + .replace(/[,\():]+/g, "") + .toLowerCase(); +} + +/** Given a string "xy", returns "x.y" */ +export const resolveDecimalVersion = (version: `${number}`) => version.split("").join("."); + +/** Sort function for ordering WCAG principle/guideline/SC numbers ascending */ +export function wcagSort( + a: Principle | Guideline | SuccessCriterion, + b: Principle | Guideline | SuccessCriterion +) { + const aParts = a.num.split(".").map((n) => +n); + const bParts = b.num.split(".").map((n) => +n); + + for (let i = 0; i < 3; i++) { + if (aParts[i] > bParts[i] || (aParts[i] && !bParts[i])) return 1; + if (aParts[i] < bParts[i] || (bParts[i] && !aParts[i])) return -1; + } + return 0; +} diff --git a/11ty/cp-cvs.ts b/11ty/cp-cvs.ts new file mode 100644 index 0000000000..3adf39bb7c --- /dev/null +++ b/11ty/cp-cvs.ts @@ -0,0 +1,53 @@ +/** @fileoverview script to copy already-built output to CVS subfolders */ + +import { glob } from "glob"; +import { mkdirp } from "mkdirp"; + +import { copyFile, unlink } from "fs/promises"; +import { dirname, join } from "path"; + +import { assertIsWcagVersion } from "./guidelines"; + +const outputBase = "_site"; +const cvsBase = process.env.WCAG_CVSDIR || "../../../w3ccvs"; +const wcagVersion = process.env.WCAG_VERSION || "22"; +assertIsWcagVersion(wcagVersion); +const wcagBase = `${cvsBase}/WWW/WAI/WCAG${wcagVersion}`; + +// Map (git) sources to (CVS) destinations, since some don't match case-sensitively +const dirs = { + techniques: "Techniques", + understanding: "Understanding", + "working-examples": "working-examples", +}; + +for (const [srcDir, destDir] of Object.entries(dirs)) { + const cleanPaths = await glob(`**`, { + cwd: join(wcagBase, destDir), + ignore: ["**/CVS/**"], + nodir: true, + }); + + for (const path of cleanPaths) await unlink(join(wcagBase, destDir, path)); + + const indexPaths = await glob(`**/index.html`, { cwd: join(outputBase, srcDir) }); + const nonIndexPaths = await glob(`**`, { + cwd: join(outputBase, srcDir), + ignore: ["**/index.html"], + nodir: true, + }); + + for (const path of indexPaths) { + const srcPath = join(outputBase, srcDir, path); + const destPath = join(wcagBase, destDir, path.replace(/index\.html$/, "Overview.html")); + await mkdirp(dirname(destPath)); + await copyFile(srcPath, destPath); + } + + for (const path of nonIndexPaths) { + const srcPath = join(outputBase, srcDir, path); + const destPath = join(wcagBase, destDir, path); + await mkdirp(dirname(destPath)); + await copyFile(srcPath, destPath); + } +} diff --git a/11ty/guidelines.ts b/11ty/guidelines.ts new file mode 100644 index 0000000000..08c4ec1c3e --- /dev/null +++ b/11ty/guidelines.ts @@ -0,0 +1,227 @@ +import type { Cheerio, Element } from "cheerio"; +import { glob } from "glob"; + +import { readFile } from "fs/promises"; +import { basename } from "path"; + +import { flattenDomFromFile, load } from "./cheerio"; +import { generateId } from "./common"; + +export type WcagVersion = "20" | "21" | "22"; +export function assertIsWcagVersion(v: string): asserts v is WcagVersion { + if (!/^2[012]$/.test(v)) throw new Error(`Unexpected version found: ${v}`); +} + +/** + * Interface describing format of entries in guidelines/act-mapping.json + */ +interface ActRule { + deprecated: boolean; + permalink: string; + proposed: boolean; + successCriteria: string[]; + title: string; + wcagTechniques: string[]; +} + +type ActMapping = { + "act-rules": ActRule[]; +}; + +/** Data used for test-rules sections, from act-mapping.json */ +export const actRules = ( + JSON.parse(await readFile("guidelines/act-mapping.json", "utf8")) as ActMapping +)["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) + */ +export async function getGuidelinesVersions() { + const paths = await glob("*/*.html", { cwd: "understanding" }); + const versions: Record = { "20": [], "21": [], "22": [] }; + + for (const path of paths) { + const [version, filename] = path.split("/"); + assertIsWcagVersion(version); + versions[version].push(basename(filename, ".html")); + } + + 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; +} + +export interface DocNode { + id: string; + name: string; + /** Helps distinguish entity type when passed out-of-context; used for navigation */ + type?: "Principle" | "Guideline" | "SC"; +} + +export interface Principle extends DocNode { + content: string; + num: `${number}`; // typed as string for consistency with guidelines/SC + version: "WCAG20"; + guidelines: Guideline[]; + type: "Principle"; +} + +export interface Guideline extends DocNode { + content: string; + num: `${Principle["num"]}.${number}`; + version: `WCAG${"20" | "21"}`; + successCriteria: SuccessCriterion[]; + type: "Guideline"; +} + +export interface SuccessCriterion extends DocNode { + content: string; + num: `${Guideline["num"]}.${number}`; + /** Level may be empty for obsolete criteria */ + level: "A" | "AA" | "AAA" | ""; + version: `WCAG${WcagVersion}`; + type: "SC"; +} + +export function isSuccessCriterion(criterion: any): criterion is SuccessCriterion { + return !!(criterion?.type === "SC" && "level" in criterion); +} + +/** + * Returns HTML content used for Understanding guideline/SC boxes. + * @param $el Cheerio element of the full section from flattened guidelines/index.html + */ +const getContentHtml = ($el: Cheerio) => { + // 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(); +}; + +/** + * 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"); + + const principles: Principle[] = []; + $(".principle").each((i, el) => { + const guidelines: Guideline[] = []; + $(".guideline", el).each((j, guidelineEl) => { + const successCriteria: SuccessCriterion[] = []; + $(".sc", guidelineEl).each((k, scEl) => { + const resolvedVersion = versions[scEl.attribs.id]; + assertIsWcagVersion(resolvedVersion); + + successCriteria.push({ + content: getContentHtml($(scEl)), + id: scEl.attribs.id, + name: $("h4", scEl).text().trim(), + num: `${i + 1}.${j + 1}.${k + 1}`, + level: $("p.conformance-level", scEl).text().trim() as SuccessCriterion["level"], + type: "SC", + version: `WCAG${resolvedVersion}`, + }); + }); + + guidelines.push({ + content: getContentHtml($(guidelineEl)), + id: guidelineEl.attribs.id, + name: $("h3", guidelineEl).text().trim(), + num: `${i + 1}.${j + 1}`, + type: "Guideline", + version: guidelineEl.attribs.id === "input-modalities" ? "WCAG21" : "WCAG20", + successCriteria, + }); + }); + + principles.push({ + content: getContentHtml($(el)), + id: el.attribs.id, + name: $("h2", el).text().trim(), + num: `${i + 1}`, + type: "Principle", + version: "WCAG20", + guidelines, + }); + }); + + return principles; +} + +/** + * Returns a flattened object hash, mapping shortcodes to each principle/guideline/SC. + */ +export function getFlatGuidelines(principles: Principle[]) { + const map: Record = {}; + for (const principle of principles) { + map[principle.id] = principle; + for (const guideline of principle.guidelines) { + map[guideline.id] = guideline; + for (const criterion of guideline.successCriteria) { + map[criterion.id] = criterion; + } + } + } + return map; +} +export type FlatGuidelinesMap = ReturnType; + +interface Term { + definition: string; + /** generated id for use in Understanding pages */ + id: string; + name: string; + /** id of dfn in TR, which matches original id in terms file */ + trId: string; +} + +/** + * Resolves term definitions from guidelines/index.html organized for lookup by name; + * comparable to the term elements in wcag.xml from the guidelines-xml Ant task. + */ +export async function getTermsMap() { + const $ = await flattenDomFromFile("guidelines/index.html"); + const terms: Record = {}; + + $("dfn").each((_, el) => { + const $el = $(el); + const term: Term = { + // Note: All applicable s have explicit id attributes for TR, + // but the XSLT process generates id from the element's text which is not always the same + id: `dfn-${generateId($el.text())}`, + definition: getContentHtml($el.parent().next()), + name: $el.text(), + trId: el.attribs.id, + }; + + // Include both original and all-lowercase version to simplify lookups + // (since most synonyms are lowercase) while preserving case in name + const names = [term.name, term.name.toLowerCase()].concat( + (el.attribs["data-lt"] || "").toLowerCase().split("|") + ); + for (const name of names) terms[name] = term; + }); + + return terms; +} diff --git a/11ty/techniques.ts b/11ty/techniques.ts new file mode 100644 index 0000000000..94820e7784 --- /dev/null +++ b/11ty/techniques.ts @@ -0,0 +1,278 @@ +import type { Cheerio } from "cheerio"; +import { glob } from "glob"; +import matter from "gray-matter"; +import capitalize from "lodash-es/capitalize"; +import uniqBy from "lodash-es/uniqBy"; + +import { readFile } from "fs/promises"; +import { basename } from "path"; + +import { load, loadFromFile } from "./cheerio"; +import { + assertIsWcagVersion, + isSuccessCriterion, + type FlatGuidelinesMap, + type SuccessCriterion, + type WcagVersion, +} from "./guidelines"; +import { wcagSort } from "./common"; + +/** Maps each technology to its title for index.html */ +export const technologyTitles = { + aria: "ARIA Techniques", + "client-side-script": "Client-Side Script Techniques", + css: "CSS Techniques", + failures: "Common Failures", + flash: "Flash Techniques", // Deprecated in 2020 + general: "General Techniques", + html: "HTML Techniques", + pdf: "PDF Techniques", + "server-side-script": "Server-Side Script Techniques", + smil: "SMIL Techniques", + silverlight: "Silverlight Techniques", // Deprecated in 2020 + text: "Plain-Text Techniques", +}; +export type Technology = keyof typeof technologyTitles; +export const technologies = Object.keys(technologyTitles) as Technology[]; + +function assertIsTechnology( + technology: string +): asserts technology is keyof typeof technologyTitles { + if (!(technology in technologyTitles)) throw new Error(`Invalid technology name: ${technology}`); +} + +const associationTypes = ["sufficient", "advisory", "failure"] as const; +type AssociationType = (typeof associationTypes)[number]; + +interface TechniqueAssociation { + criterion: SuccessCriterion; + type: Capitalize; + /** Indicates this technique must be paired with specific "child" techniques to fulfill SC */ + hasUsageChildren: boolean; + /** + * Technique ID of "parent" technique(s) this is paired with to fulfill SC. + * This is typically 0 or 1 technique, but may be multiple in rare cases. + */ + usageParentIds: string[]; + /** + * Text description of "parent" association, if it does not reference a specific technique; + * only populated if usageParentIds is empty. + */ + usageParentDescription: string; + /** Technique IDs this technique must be implemented with to fulfill SC, if any */ + with: string[]; +} + +function assertIsAssociationType(type?: string): asserts type is AssociationType { + if (!associationTypes.includes(type as AssociationType)) + throw new Error(`Association processed for unexpected section ${type}`); +} + +/** + * Pulls the basename out of a technique link href. + * This intentionally returns empty string (falsy) if a directory link happens to be passed. + */ +export const resolveTechniqueIdFromHref = (href: string) => + href.replace(/^.*\//, "").replace(/\.html$/, ""); + +/** + * Selector that can detect relative and absolute technique links from understanding docs + */ +export const understandingToTechniqueLinkSelector = [ + "[href^='../Techniques/' i]", + "[href^='../../techniques/' i]", + "[href^='https://www.w3.org/WAI/WCAG' i][href*='/Techniques/' i]", +] + .map((value) => `a${value}`) + .join(", ") as "a"; + +/** + * Returns object mapping technique IDs to SCs that reference it; + * comparable to technique-associations.xml but in a more ergonomic format. + */ +export async function getTechniqueAssociations(guidelines: FlatGuidelinesMap) { + const associations: Record = {}; + const itemSelector = associationTypes.map((type) => `section#${type} li`).join(", "); + + const paths = await glob("understanding/*/*.html"); + for (const path of paths) { + const criterion = guidelines[basename(path, ".html")]; + if (!isSuccessCriterion(criterion)) continue; + + const $ = await loadFromFile(path); + $(itemSelector).each((_, liEl) => { + const $liEl = $(liEl); + const $parentListItem = $liEl.closest("ul, ol").closest("li"); + // Identify which expected section the list was found under + const associationType = $liEl + .closest(associationTypes.map((type) => `section#${type}`).join(", ")) + .attr("id"); + assertIsAssociationType(associationType); + + /** Finds matches only within the given list item (not under child lists) */ + const queryNonNestedChildren = ($el: Cheerio, selector: string) => + $el.find(selector).filter((_, aEl) => $(aEl).closest("li")[0] === $el[0]); + + const $techniqueLinks = queryNonNestedChildren($liEl, understandingToTechniqueLinkSelector); + $techniqueLinks.each((_, aEl) => { + const usageParentIds = queryNonNestedChildren( + $parentListItem, + understandingToTechniqueLinkSelector + ) + .toArray() + .map((el) => resolveTechniqueIdFromHref(el.attribs.href)); + + // Capture the "X" in "X or more" phrasing, to include a phrase about + // combining with other techniques if more than one is required. + const descriptionDependencyPattern = + /(?:^|,?\s+)(?:by )?using\s+(?:(\w+) (?:or more )?of )?the\s+(?:following )?techniques(?: below)?(?::|\.)?\s*$/i; + const parentHtml = usageParentIds.length + ? null + : queryNonNestedChildren($parentListItem, "p").html(); + const match = parentHtml && descriptionDependencyPattern.exec(parentHtml); + const parentDescription = parentHtml + ? parentHtml.replace( + descriptionDependencyPattern, + !match?.[1] || match?.[1] === "one" ? "" : "when combined with other techniques" + ) + : ""; + const usageParentDescription = + parentDescription && + (parentDescription.startsWith("when") + ? parentDescription + : `when used for ${parentDescription[0].toLowerCase()}${parentDescription.slice(1)}`); + + const association: TechniqueAssociation = { + criterion, + type: capitalize(associationType) as Capitalize, + hasUsageChildren: !!$liEl.find("ul, ol").length, + usageParentIds, + usageParentDescription, + with: $techniqueLinks + .toArray() + .filter((el) => el !== aEl) + .map((el) => resolveTechniqueIdFromHref(el.attribs.href)), + }; + + const id = resolveTechniqueIdFromHref(aEl.attribs.href); + if (!(id in associations)) associations[id] = [association]; + else associations[id].push(association); + }); + }); + } + + // Remove duplicates (due to similar shape across understanding docs) and sort by SC number + for (const [key, list] of Object.entries(associations)) + associations[key] = uniqBy(list, (v) => JSON.stringify(v)).sort((a, b) => + wcagSort(a.criterion, b.criterion) + ); + + return associations; +} + +interface TechniqueFrontMatter { + /** May be specified via front-matter; message to display RE a technique's obsolescence. */ + obsoleteMessage?: string; + /** May be specified via front-matter to indicate a technique is obsolete as of this version. */ + obsoleteSince?: WcagVersion; +} + +export interface Technique extends TechniqueFrontMatter { + /** Letter(s)-then-number technique code; corresponds to source HTML filename */ + id: string; + /** Technology this technique is filed under */ + technology: Technology; + /** Title derived from each technique page's h1 */ + title: string; + /** Title derived from each technique page's h1, with HTML preserved */ + titleHtml: string; + /** + * Like title, but preserving the XSLT process behavior of truncating + * text on intermediate lines between the first and last for long headings. + * (This was probably accidental, but helps avoid long link text.) + */ + truncatedTitle: string; +} + +/** + * Returns an object mapping each technology category to an array of Techniques. + * Used to generate index table of contents. + * (Functionally equivalent to "techniques-list" target in build.xml) + */ +export async function getTechniquesByTechnology() { + const paths = await glob("*/*.html", { cwd: "techniques" }); + const techniques = technologies.reduce( + (map, technology) => ({ + ...map, + [technology]: [] as string[], + }), + {} as Record + ); + + // Check directory data files (we don't have direct access to 11ty's data cascade here) + const technologyData: Partial> = {}; + for (const technology of technologies) { + try { + const data = JSON.parse( + await readFile(`techniques/${technology}/${technology}.11tydata.json`, "utf8") + ); + if (data) technologyData[technology] = data; + } catch {} + } + + for (const path of paths) { + const [technology, filename] = path.split("/"); + assertIsTechnology(technology); + // Support front-matter within HTML files + const { content, data: frontMatterData } = matter(await readFile(`techniques/${path}`, "utf8")); + const data = { ...technologyData[technology], ...frontMatterData }; + + if (data.obsoleteSince) { + data.obsoleteSince = "" + data.obsoleteSince; + assertIsWcagVersion(data.obsoleteSince); + } + + // Isolate h1 from each file before feeding into Cheerio to save ~300ms total + const h1Match = content.match(/]*>([\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> +) => + Object.values(techniques) + .flat() + .reduce( + (map, technique) => { + map[technique.id] = technique; + return map; + }, + {} as Record + ); diff --git a/11ty/types.ts b/11ty/types.ts new file mode 100644 index 0000000000..9bdd86c9f1 --- /dev/null +++ b/11ty/types.ts @@ -0,0 +1,55 @@ +/** @fileoverview Typings for common Eleventy entities */ + +interface EleventyPage { + date: Date; + filePathStem: string; + fileSlug: string; + inputPath: string; + outputFileExtension: string; + outputPath: string; + rawInput: string; + templateSyntax: string; + url: string; +} + +interface EleventyDirectories { + data: string; + includes: string; + input: string; + layouts?: string; + output: string; +} + +type EleventyRunMode = "build" | "serve" | "watch"; + +interface EleventyMeta { + directories: EleventyDirectories; + env: { + config: string; + root: string; + runMode: EleventyRunMode; + source: "cli" | "script"; + }; + generator: string; + version: string; +} + +/** Limited 11ty data available when defining filters and shortcodes. */ +export interface EleventyContext { + eleventy: EleventyMeta; + page: EleventyPage; +} + +/** Eleventy-supplied data available to templates. */ +export interface EleventyData extends EleventyContext { + content: string; + // Allow access to anything else in data cascade + [index: string]: any; +} + +/** Properties available in Eleventy event callbacks (eleventyConfig.on(...)) */ +export interface EleventyEvent { + dir: EleventyDirectories; + outputMode: "fs" | "json" | "ndjson"; + runMode: EleventyRunMode; +} diff --git a/11ty/understanding.ts b/11ty/understanding.ts new file mode 100644 index 0000000000..c9b414b63f --- /dev/null +++ b/11ty/understanding.ts @@ -0,0 +1,89 @@ +import { resolveDecimalVersion } from "./common"; +import type { DocNode, Principle, WcagVersion } from "./guidelines"; + +/** + * Selector that can detect relative and absolute understanding links from techniques docs + */ +export const techniqueToUnderstandingLinkSelector = [ + "[href^='../../Understanding/' i]", + "[href^='https://www.w3.org/WAI/WCAG' i][href*='/Understanding/' i]", +] + .map((value) => `a${value}`) + .join(", ") as "a"; + +/** + * Resolves information for top-level understanding pages; + * ported from generate-structure-xml.xslt + */ +export async function getUnderstandingDocs(version: WcagVersion): Promise { + const decimalVersion = resolveDecimalVersion(version); + return [ + { + id: "intro", + name: `Introduction to Understanding WCAG ${decimalVersion}`, + }, + { + id: "understanding-techniques", + name: "Understanding Techniques for WCAG Success Criteria", + }, + { + id: "understanding-act-rules", + name: "Understanding Test Rules for WCAG Success Criteria", + }, + { + id: "conformance", + name: "Understanding Conformance", + }, + { + id: "refer-to-wcag", + name: `How to Refer to WCAG ${decimalVersion} from Other Documents`, + }, + { + id: "documenting-accessibility-support", + name: "Documenting Accessibility Support for Uses of a Web Technology", + }, + { + id: "understanding-metadata", + name: "Understanding Metadata", + }, + ]; +} + +interface NavData { + parent?: DocNode; + previous?: DocNode; + next?: DocNode; +} + +/** + * Generates mappings from guideline/SC/understanding doc IDs to next/previous/parent information, + * for efficient lookup when rendering navigation banner + */ +export function generateUnderstandingNavMap(principles: Principle[], understandingDocs: DocNode[]) { + const allGuidelines = Object.values(principles).flatMap(({ guidelines }) => guidelines); + const map: Record = {}; + + // Guideline navigation wraps across principles, so iterate over flattened list + allGuidelines.forEach((guideline, i) => { + map[guideline.id] = { + ...(i > 0 && { previous: allGuidelines[i - 1] }), + ...(i < allGuidelines.length - 1 && { next: allGuidelines[i + 1] }), + }; + guideline.successCriteria.forEach((criterion, j) => { + map[criterion.id] = { + parent: guideline, + ...(j > 0 && { previous: guideline.successCriteria[j - 1] }), + ...(j < guideline.successCriteria.length - 1 && { next: guideline.successCriteria[j + 1] }), + }; + }); + }); + + understandingDocs.forEach((doc, i) => { + map[doc.id] = { + ...(i > 0 && { previous: understandingDocs[i - 1] }), + ...(i < understandingDocs.length - 1 && { next: understandingDocs[i + 1] }), + }; + }); + + return map; +} diff --git a/README.md b/README.md index 223a6681f0..6bee8669d4 100644 --- a/README.md +++ b/README.md @@ -1,7 +1,7 @@ -WCAG (Web Content Accessibility Guidelines) +WCAG (Web Content Accessibility Guidelines) - Branch for production of August 2016 review versions === -Please do not submit any new pull requests against this branch - please look in the list of branches for the most current Working Branch and use that one. +Please use this branch as the target for pull requests until July 10, 2016. This repository is used to develop content for WCAG 2, as well as associated understanding documents and techniques. @@ -11,18 +11,20 @@ This repository is used to develop content for WCAG 2, as well as associated und * Avoid use of RFC2119 terms such as "must", "shall", or "may" in non-normative content, to avoid confusion with normative role. +See also: [WCAG 2 Style Guide](https://github.com/w3c/wcag/wiki/WCAG-2-style-guide) + ## File Structure WCAG 2.0 was maintained in a different file structure than subsequent versions of WCAG. Source files for WCAG 2.0 are in the wcag20 folder and exists primarily for archival purposes. Do not edit content in that folder. -Content for WCAG 2.1 and later is organized accordign to the file structure below. The WCAG repository contains source and auxiliary files for WCAG 2, Understanding WCAG 2, and eventually techniques. It also contains auxiliary files that support automated formatting of the document. To facilitate multi-party editing, each success criterion is in a separate file, consisting of a HTML fragment that can be included into the main guidelines. Key files include: +Content for WCAG 2.1 and later is organized according to the file structure below. The WCAG repository contains source and auxiliary files for WCAG 2, Understanding WCAG 2, and eventually techniques. It also contains auxiliary files that support automated formatting of the document. To facilitate multi-party editing, each success criterion is in a separate file, consisting of a HTML fragment that can be included into the main guidelines. Key files include: -* guidelines/index.html - the main guidelines file -* guidelines/sc//*.html - files for each success criterion -* guidelines/terms//*.html - files for each definition -* understanding//*.html - understanding files for each success criterion +* `guidelines/index.html` - the main guidelines file +* `guidelines/sc/{version}/*.html` - files for each success criterion +* `guidelines/terms/{version}/*.html` - files for each definition +* `understanding/{version}/*.html` - understanding files for each success criterion -Where is "20", content came from WCAG 2.0. "21" is used for content introduced in WCAG 2.1, "22" for WCAG 2.2, etc. +Where `{version}` is "20", content came from WCAG 2.0. "21" is used for content introduced in WCAG 2.1, "22" for WCAG 2.2, etc. ## Editing Draft Success Criteria @@ -34,7 +36,7 @@ Where is "20", content came from WCAG 2.0. "21" is used for content in 1. Open the guidelines/index.html file and remove comment marks around the lines that reference the success criterion and terms you have edited.. 1. Follow the [success criteria format](#user-content-success-criteria-format) below to create the SC content. 1. Save the file and commit the change. NOTE: It is important to also add a suitable 'commit message'. In the comments, reference the issue number from which the proposal was developed starting with a hash, e.g., `#1`. -1. When the success criterion is ready for Working Group review, inform the chairs. Once the proposal has been accepted by the Working Group, the editors will merge the working branch into the master branch, which puts it in the editors' draft and eventual Technical Report publication. +1. When the success criterion is ready for Working Group review, inform the chairs. Once the proposal has been accepted by the Working Group, the editors will merge the working branch into the main branch, which puts it in the editors' draft and eventual Technical Report publication. ### Success Criteria Format @@ -79,21 +81,23 @@ Values you provide are described below. Refer to [Success Criterion 2.2.1](https ### Definitions -If you providing term definitions along with your SC, include them in the glossary. Position them in the appropriate alphabetical order with the rest of the terms and use the following format: +If you are providing term definitions along with your SC, include them in the respective `guidelines/terms/{version}` directory, one-per-file, using the following format: ```html -
    {Term}
    +
    {Term}
    {Definition}
    ``` -The ```dfn``` element tells the script that this is a term and causes special styling and linking features. To link to a term, use an `` element without an `href` attribute; if the link text is the same as the term, the link will be correctly generated. For example, if there is a term `web page` on the page, a link in the form of `web page` will result in a proper link. If the link text has a different form from the canonical term, e.g., "web pages" (note the plural), you can provide a hint on the term definition with the `data-lt` attribute. In this example, modify the term to be `web page`. Multiple alternate names for the term can be separated with pipe characters, with no leading or trailing space, e.g., `web page`. +The ```dfn``` element tells the script that this is a term and causes special styling and linking features. To link to a term, use an `` element without an `href` attribute; if the link text is the same as the term, the link will be correctly generated. For example, if there is a term `web page` on the page, a link in the form of `web page` will result in a proper link. + +If the link text has a different form from the canonical term, e.g., "web pages" (note the plural), you can provide a hint on the term definition with the `data-lt` attribute. In this example, modify the term to be `web page`. Multiple alternate names for the term can be separated with pipe characters, with no leading or trailing space, e.g., `web page`. ## Editing Draft Understanding Content There is one Understanding file per success criterion, plus an index: -* understanding/index.html - index page, need to uncomment or add a reference to individual Understanding pages as they are made available -* understanding//*.html - files for each understanding page, named the same as the success criterion file in the guidelines +* `understanding/index.html` - index page, need to uncomment or add a reference to individual Understanding pages as they are made available +* `understanding/{version}/*.html` - files for each understanding page, named the same as the success criterion file in the guidelines Files are populated with a template that provides the expected structure. Leave the template structure in place, and add content as appropriate within the sections. Elements with class="instructions" provide guidance about what content to include in that section; you can remove those elements if you want but don't have to. The template for examples proposes either a bullet list or a series of sub-sections, choose one of those approaches and remove the other from the template. The template for techniques includes sub-sections for "situations", remove that wrapper section if not needed. @@ -111,8 +115,6 @@ The [technique template](techniques/technique-template.html) shows the structure Techniques can use a temporary style sheet to facilitate review of drafts. This style sheet is replaced by other style sheets and structure for formal publication. To use this style sheet, add `` to the head of the technique. -The generator used to publish techniques uses XML processing, so techniques must be well-formed XML. Techniques use HTML 5 structure so are actually [HTML Polyglot](https://www.w3.org/TR/html-polyglot/). - ### Images, Examples, Cross References for Techniques Techniques can include images. Place the image file in the `img` folder of the relevant technology - meaning all techniques for a technology share a common set of images. Use a relative link to load the image. Most images should be loaded with a `
    ` element and labeled with a `
    ` positioned at the bottom of the figure. `
    ` elements must have an `id` attribute. Small inline images may be loaded with a `` element with suitable `alt` text. @@ -134,10 +136,11 @@ Each new technique should be created in a new branch. Set-up of the branch and f ```Shell bash create-techniques.sh "" ``` -\<technology> is the technology directory for the technique -\<filename> is the temporary filename (without extension) for the technique -\<type> is "technique" or "failure" -\<title> is the title of the technique, enclosed in quotes and escaping special characters with \\ + +* `<technology>` is the technology directory for the technique +* `<filename>` is the temporary filename (without extension) for the technique +* `<type>` is "technique" or "failure" +* `<title>` is the title of the technique, enclosed in quotes and escaping special characters with \\ This automates the following steps: @@ -149,16 +152,36 @@ This automates the following steps: Once a technique branch and file is set up, populate the content and request review: * Populate the template with appropriate content, using other techniques as examples for code formatting choices. Keep the existing structural sections from the template in place. -* When the technique is ready for review, make a pull request into master. +* When the technique is ready for review, make a pull request into the main branch. * If you wish to reference the draft technique from an Understanding document, use the technique's rawgit URI. * After a technique is approved, the chairs will assign it an ID and update links to it in the Undestanding documents. ### Formatting Techniques -Techniques in the repository are plain HTML files with minimal formatting. For publication to the editors' draft and W3C location, techniques are formatted by an XSLT-based generator managed by Apache Ant running in Java. Most people do not need to worry about this, but relevant files are the [Ant build file](build.xml) and [XSLT files](xslt). +Techniques in the repository are plain HTML files with minimal formatting. For publication to the editors' draft and W3C location, techniques are formatted by a build process based on Eleventy for templating and Cheerio for transformations. More details, including instructions for previewing locally, can be found in the [build process README](11ty/README.md). The generator compiles the techniques together as a suite with formatting and navigation. It enforces certain structures, such as ordering top-level sections described above and standardizing headings. It attempts to process cross reference links to make sure the URIs work upon publication. One of the most substantial roles is to populate the Applicability section with references to the guidelines or success criteria to which the technique relates. The information for this comes from the Understanding documents. Proper use of the technique template is important to enable this functionality, and mal-formed techniques may cause the generator to fail. +### Obsolete Techniques + +Obsolete techniques should not be removed from the repository. Instead, they can be marked using YAML front-matter. For example: + +```yaml +--- +obsoleteSince: 22 +obsoleteMessage: | + This failure relates to 4.1.1: Parsing, which was removed as of WCAG 2.2. +--- +``` + +* `obsoleteSince` indicates the earliest version of WCAG 2 when the technique became obsolete + (this may be set to `20` if it should effectively be obsolete for all versions, e.g. for + techniques involving deprecated HTML elements) +* `obsoleteMessage` indicates a message to be displayed within the About this Technique section + +In cases where entire technologies are obsolete (e.g. Flash and Silverlight), these properties may also be specified at the technique subdirectory level, e.g. via `techniques/flash/flash.11tydata.json`. +Note that this case specifically requires JSON format, as this is consumed by both Eleventy and additional code in the build process used to assemble techniques data. + ## Working Examples Examples in techniques should be brief easy-to-consume code samples of how the technique is used in content. Therefore examples should focus on the specific features the technique describes, and not include related content such as style, script, surrounding web content, etc. @@ -174,18 +197,9 @@ To create a working example: * Create a directory for the example inside the working examples directory, using the semantic name for the example minus the prefix used in the branch name, e.g., `working-examples/alt-attribute/`. * If the primary example is HTML, name the file `index.html`. Otherwise, create a suitable file name. * Refer to resources shared among multiple examples using relative links, e.g., `../css/example.css`. Place other resources in the same directory as the main example, e.g., `working-examples/alt-attribute/css/alt.css`. -* Reference working examples from techniques using the rawgit URI to the example in its development branch, e.g., `https://rawgit.com/w3c/wcag/master/working-examples/alt-attribute/`. Editors will update links when examples are approved. -* When the example is complete and functional, submit a pull request into the master branch. +* Reference working examples from techniques using the rawgit URI to the example in its development branch, e.g., `https://rawgit.com/w3c/wcag/main/working-examples/alt-attribute/`. Editors will update links when examples are approved. +* When the example is complete and functional, submit a pull request into the main branch. ## Translations -WCAG 2.1 is ready for translation. WCAG 2.2 is still under development so should not be translated yet. To translate WCAG 2.1, ensure you are set up to use [GitHub](https://github.com/), then: - -* [Fork](https://docs.github.com/en/free-pro-team@latest/github/getting-started-with-github/fork-a-repo) the w3c/wcag repository. -* Change to the [branch](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/about-branches) "WCAG-2.1". -* Create a new branch from this branch. -* Translate all user-oriented content in the "guidelines" folder, including the sub-folders. User-oriented content includes text in elements, and attributes such as "title" and "alt" that provide content to users. **Leave other markup as is.** -* Load the index.html document in a modern browser and allow the script to compile the content and format it. -* Activate the "Respec" link in the top right corner, and choose "Export...", then the "HTML" option. -* Edit the resulting file to translate text that was inserted by the script. -* Edit the file to meet the requirements of the [W3C Authorized Translations](https://www.w3.org/2005/02/TranslationPolicy) process. \ No newline at end of file +WCAG 2.2 is ready for translation. To translate WCAG 2.2, follow instructions at [How to Translate WCAG 2](https://www.w3.org/WAI/about/translating/wcag/). diff --git a/_includes/back-to-top.html b/_includes/back-to-top.html new file mode 100644 index 0000000000..da38ab5fbc --- /dev/null +++ b/_includes/back-to-top.html @@ -0,0 +1,7 @@ +<a class="button button-backtotop" href="#top"> + <span> + <svg focusable="false" aria-hidden="true" class="icon-arrow-up " viewBox="0 0 26 28"> + <path d="M25.172 15.172c0 0.531-0.219 1.031-0.578 1.406l-1.172 1.172c-0.375 0.375-0.891 0.594-1.422 0.594s-1.047-0.219-1.406-0.594l-4.594-4.578v11c0 1.125-0.938 1.828-2 1.828h-2c-1.062 0-2-0.703-2-1.828v-11l-4.594 4.578c-0.359 0.375-0.875 0.594-1.406 0.594s-1.047-0.219-1.406-0.594l-1.172-1.172c-0.375-0.375-0.594-0.875-0.594-1.406s0.219-1.047 0.594-1.422l10.172-10.172c0.359-0.375 0.875-0.578 1.406-0.578s1.047 0.203 1.422 0.578l10.172 10.172c0.359 0.375 0.578 0.891 0.578 1.422z"></path> + </svg> Back to Top + </span> +</a> diff --git a/_includes/head.html b/_includes/head.html new file mode 100644 index 0000000000..55e7145ca2 --- /dev/null +++ b/_includes/head.html @@ -0,0 +1,8 @@ +{% # common tags inserted into all non-index/about pages %} +<meta name="viewport" content="width=device-width, initial-scale=1"/> +<link rel="stylesheet" href="https://w3.org/WAI/assets/css/style.css" /> +{% if isTechniques %} + {% include "techniques/head.html" %} +{% elsif isUnderstanding %} + {% include "understanding/head.html" %} +{% endif %} diff --git a/_includes/header.html b/_includes/header.html new file mode 100644 index 0000000000..df1a329f39 --- /dev/null +++ b/_includes/header.html @@ -0,0 +1,44 @@ +{% comment %} +Expected inputs from directory data for techniques and understanding: +headerUrl and headerLabel (set in both folders) +isUnderstanding and isTechniques (each set to true in respective folder) +{% endcomment %} +<a href="#main" class="button button--skip-link">Skip to content</a> +<div class="minimal-header-container default-grid"> + <header class="minimal-header" id="site-header"> + <div class="minimal-header-name"> + <a href="{{ headerUrl }}">WCAG {{ versionDecimal }} {{ headerLabel }}</a> + </div> + {% if isTechniques %} + <div class="minimal-header-subtitle">Examples of ways to meet WCAG; not required</div> + {% elsif isUnderstanding %} + <div class="minimal-header-subtitle">Informative explanations, not required to meet WCAG</div> + {% endif %} + <a class="minimal-header-link" href="{{ headerUrl }}about">About WCAG {{ headerLabel }}</a> + <div class="minimal-header-logo"> + <a href="http://w3.org/" aria-label="W3C"> + <svg xmlns="http://www.w3.org/2000/svg" height="2em" viewBox="0 0 91.968 44"> + <g fill-rule="evenodd" fill="none"> + <path fill="#015a9c" d="M-.231-.21h92.917v44.659H-.23z" /> + <g fill-rule="nonzero" fill="#fff"> + <path + d="M21.752 0l7.789 26.78L37.329 0H58.444v2.662l-7.95 13.852c2.792.907 4.905 2.555 6.337 4.944 1.432 2.391 2.149 5.196 2.149 8.419 0 3.985-1.048 7.335-3.143 10.05C53.742 42.642 51.029 44 47.7 44c-2.507 0-4.691-.806-6.552-2.417-1.862-1.611-3.24-3.793-4.136-6.546l4.403-1.846c.646 1.666 1.496 2.979 2.552 3.938 1.056.96 2.3 1.438 3.733 1.438 1.504 0 2.775-.85 3.813-2.552 1.039-1.703 1.558-3.747 1.558-6.14 0-2.643-.556-4.69-1.664-6.138-1.29-1.701-3.314-2.554-6.071-2.554h-2.148v-2.606l7.52-13.147H41.63l-.516.889-11.04 37.678h-.536L21.48 16.73l-8.056 27.268h-.537L0 0h5.64l7.787 26.78 5.264-18.033L16.113 0zM87.958 0c-1.077 0-2.044.388-2.777 1.133-.777.79-1.21 1.81-1.21 2.866s.412 2.034 1.167 2.8C85.905 7.579 86.892 8 87.959 8c1.043 0 2.055-.422 2.843-1.188.755-.733 1.166-1.711 1.166-2.811a3.997 3.997 0 00-1.155-2.811A3.946 3.946 0 0087.958 0zm3.476 4.034a3.32 3.32 0 01-1.01 2.41c-.69.668-1.544 1.023-2.489 1.023a3.405 3.405 0 01-2.42-1.033c-.655-.667-1.022-1.523-1.022-2.433 0-.911.378-1.8 1.055-2.489.633-.645 1.488-.988 2.42-.988.955 0 1.81.356 2.477 1.033.645.643.99 1.51.99 2.477zm-3.366-2.378h-1.71v4.533h.855V4.256h.845l.922 1.933h.955l-1.012-2.066c.655-.134 1.033-.578 1.033-1.223 0-.822-.621-1.244-1.888-1.244zm-.155.555c.8 0 1.165.222 1.165.778 0 .533-.365.722-1.144.722h-.722v-1.5zM82.109 0l.862 5.914-3.05 6.588s-1.172-2.795-3.118-4.342c-1.64-1.303-2.708-1.586-4.378-1.198-2.145.5-4.577 3.394-5.638 6.963-1.27 4.27-1.283 6.336-1.328 8.234-.071 3.042.354 4.841.354 4.841s-1.853-3.868-1.835-9.533c.012-4.043.576-7.71 2.233-11.328 1.459-3.181 3.626-5.09 5.55-5.315 1.99-.232 3.562.85 4.777 2.02 1.276 1.23 2.565 3.918 2.565 3.918zM82.202 31.824s-1.338 2.567-2.171 3.556c-.834.99-2.326 2.732-4.167 3.603-1.842.872-2.808 1.036-4.628.849-1.82-.188-3.51-1.319-4.102-1.79-.592-.472-2.106-1.861-2.962-3.156C63.317 33.59 61.98 31 61.98 31s.745 2.596 1.212 3.698c.269.635 1.094 2.574 2.265 4.262 1.092 1.576 3.214 4.287 6.438 4.899 3.224.613 5.44-.942 5.987-1.319.549-.376 1.704-1.416 2.436-2.256.763-.877 1.486-1.995 1.886-2.666.292-.49.768-1.485.768-1.485z" /> + </g> + </g> + </svg> + </a> + <a href="http://w3.org/WAI/" aria-label="Web Accessibility Initiative"> + <svg xmlns="http://www.w3.org/2000/svg" height="2em" viewBox="0 0 162.5 45.9"> + <g fill="none" fill-rule="evenodd"> + <path d="M0 0h162.5v45.9H0z" fill="#015a9c" /> + <path d="M1.2 24.5h160" stroke="#eed009" stroke-linecap="square" stroke-width="2" /> + <g fill="#fff" fill-rule="nonzero"> + <path + d="M15.741 15.5h-1.816L11.14 6.145c-.41-1.394-.65-2.334-.722-2.823-.104.749-.332 1.71-.684 2.881L7.04 15.5H5.223L1.444 1.223H3.32l2.217 8.72c.3 1.14.527 2.272.684 3.399.143-1.068.397-2.237.761-3.506l2.52-8.613h1.855l2.627 8.681c.339 1.127.6 2.272.781 3.438.105-.899.336-2.038.694-3.418l2.207-8.701h1.875zm10.127.195c-1.608 0-2.87-.486-3.784-1.46-.915-.973-1.372-2.312-1.372-4.018 0-1.719.426-3.088 1.279-4.107.853-1.019 2.005-1.528 3.457-1.528 1.348 0 2.422.435 3.223 1.304.8.869 1.2 2.046 1.2 3.53v1.064h-7.343c.033 1.218.342 2.142.928 2.774.586.631 1.416.947 2.49.947a8.46 8.46 0 001.631-.151c.514-.101 1.116-.298 1.807-.591v1.543a8.506 8.506 0 01-1.67.537c-.521.104-1.136.156-1.846.156zm-.44-9.677c-.84 0-1.503.27-1.992.81-.488.54-.778 1.292-.869 2.256h5.46c-.014-1.003-.245-1.764-.694-2.285-.45-.521-1.084-.781-1.904-.781zm12.237-1.416c1.413 0 2.503.486 3.271 1.46.769.973 1.153 2.332 1.153 4.077 0 1.77-.39 3.14-1.172 4.106-.781.967-1.865 1.45-3.252 1.45-.723 0-1.367-.13-1.934-.39a3.384 3.384 0 01-1.386-1.162h-.137a48.165 48.165 0 01-.362 1.357h-1.26V.305h1.759v3.691c0 .736-.033 1.471-.098 2.207h.098c.722-1.068 1.829-1.601 3.32-1.601zm-.293 1.455c-1.08 0-1.856.306-2.324.918-.47.612-.703 1.647-.703 3.105v.078c0 1.465.239 2.512.717 3.14.479.628 1.262.942 2.349.942.963 0 1.681-.353 2.153-1.06.472-.706.708-1.726.708-3.06 0-1.355-.237-2.37-.713-3.048-.475-.677-1.204-1.015-2.187-1.015zM59.286 15.5l-1.719-4.424h-5.664l-1.7 4.424h-1.816l5.577-14.336h1.62L61.152 15.5zM57.03 9.484L55.43 5.158l-.684-2.138c-.195.78-.4 1.494-.615 2.138l-1.621 4.326zm10.137 6.211c-1.543 0-2.744-.473-3.604-1.42-.86-.948-1.289-2.307-1.289-4.078 0-1.797.435-3.182 1.304-4.155.87-.973 2.108-1.46 3.716-1.46.52 0 1.037.054 1.548.161.51.108.932.246 1.264.415l-.537 1.465c-.905-.338-1.676-.508-2.314-.508-1.081 0-1.879.34-2.393 1.02-.514.681-.771 1.695-.771 3.043 0 1.295.257 2.287.771 2.973.514.687 1.276 1.03 2.285 1.03.944 0 1.872-.208 2.783-.624v1.562c-.742.384-1.663.576-2.763.576zm9.6 0c-1.544 0-2.745-.473-3.604-1.42-.86-.948-1.29-2.307-1.29-4.078 0-1.797.435-3.182 1.305-4.155.869-.973 2.107-1.46 3.715-1.46.521 0 1.037.054 1.548.161.511.108.933.246 1.265.415l-.537 1.465c-.905-.338-1.677-.508-2.315-.508-1.08 0-1.878.34-2.392 1.02-.515.681-.772 1.695-.772 3.043 0 1.295.257 2.287.772 2.973.514.687 1.276 1.03 2.285 1.03.944 0 1.872-.208 2.783-.624v1.562c-.742.384-1.663.576-2.764.576zm9.863 0c-1.608 0-2.87-.486-3.784-1.46-.915-.973-1.373-2.312-1.373-4.018 0-1.719.427-3.088 1.28-4.107.853-1.019 2.005-1.528 3.457-1.528 1.347 0 2.422.435 3.222 1.304.801.869 1.202 2.046 1.202 3.53v1.064H83.29c.032 1.218.342 2.142.928 2.774.586.631 1.416.947 2.49.947a8.46 8.46 0 001.63-.151c.515-.101 1.117-.298 1.807-.591v1.543a8.506 8.506 0 01-1.67.537c-.52.104-1.136.156-1.845.156zm-.44-9.677c-.84 0-1.504.27-1.992.81s-.778 1.292-.87 2.256h5.46c-.013-1.003-.244-1.764-.693-2.285-.45-.521-1.084-.781-1.905-.781zm14.14 6.523c0 1.003-.373 1.779-1.122 2.33-.749.55-1.8.824-3.154.824-1.413 0-2.536-.224-3.37-.674V13.42c1.179.573 2.315.86 3.409.86.885 0 1.53-.144 1.933-.43.404-.287.606-.671.606-1.153 0-.423-.194-.781-.581-1.074-.388-.293-1.076-.628-2.066-1.006-1.009-.39-1.719-.724-2.129-1-.41-.277-.711-.588-.903-.933-.192-.345-.288-.765-.288-1.26 0-.88.358-1.572 1.074-2.08.716-.508 1.7-.762 2.95-.762a8.17 8.17 0 013.417.723L99.511 6.7c-1.088-.456-2.068-.683-2.94-.683-.73 0-1.282.115-1.66.346-.378.231-.566.549-.566.952 0 .391.162.715.488.972.325.257 1.084.614 2.275 1.07.892.331 1.551.64 1.978.927.426.287.74.609.942.967.202.358.303.788.303 1.289zm9.58 0c0 1.003-.373 1.779-1.122 2.33-.749.55-1.8.824-3.154.824-1.413 0-2.536-.224-3.37-.674V13.42c1.179.573 2.315.86 3.409.86.885 0 1.53-.144 1.933-.43.404-.287.606-.671.606-1.153 0-.423-.194-.781-.581-1.074-.388-.293-1.076-.628-2.066-1.006-1.009-.39-1.719-.724-2.129-1-.41-.277-.71-.588-.903-.933-.192-.345-.288-.765-.288-1.26 0-.88.358-1.572 1.074-2.08.716-.508 1.7-.762 2.95-.762a8.17 8.17 0 013.417.723l-.595 1.396c-1.088-.456-2.067-.683-2.94-.683-.729 0-1.282.115-1.66.346-.378.231-.566.549-.566.952 0 .391.162.715.488.972.325.257 1.084.614 2.275 1.07.892.331 1.551.64 1.978.927.426.287.74.609.942.967.202.358.303.788.303 1.289zm4.356 2.959h-1.757V4.777h1.757zm-1.894-13.623c0-.39.1-.674.298-.85.198-.175.444-.263.737-.263.273 0 .513.088.718.263.205.176.307.46.307.85 0 .384-.102.667-.307.85a1.047 1.047 0 01-.718.273 1.05 1.05 0 01-.737-.273c-.199-.183-.298-.466-.298-.85zm10.371 2.725c1.413 0 2.503.486 3.271 1.46.769.973 1.153 2.332 1.153 4.077 0 1.77-.39 3.14-1.172 4.106-.781.967-1.865 1.45-3.252 1.45-.723 0-1.367-.13-1.934-.39a3.384 3.384 0 01-1.386-1.162h-.137a48.244 48.244 0 01-.361 1.357h-1.26V.305h1.758v3.691c0 .736-.033 1.471-.098 2.207h.098c.722-1.068 1.83-1.601 3.32-1.601zm-.293 1.455c-1.08 0-1.855.306-2.324.918-.469.612-.703 1.647-.703 3.105v.078c0 1.465.239 2.512.717 3.14.479.628 1.262.942 2.35.942.963 0 1.68-.353 2.152-1.06.472-.706.708-1.726.708-3.06 0-1.355-.237-2.37-.713-3.048-.475-.677-1.204-1.015-2.187-1.015zm9.277 9.443h-1.757V4.777h1.757zm-1.894-13.623c0-.39.1-.674.298-.85.198-.175.444-.263.737-.263.273 0 .513.088.718.263.205.176.307.46.307.85 0 .384-.102.667-.307.85a1.047 1.047 0 01-.718.273 1.05 1.05 0 01-.737-.273c-.199-.183-.298-.466-.298-.85zm7.05 13.623h-1.757V.305h1.758zm5.157 0h-1.758V4.777h1.758zm-1.895-13.623c0-.39.1-.674.298-.85.199-.175.444-.263.737-.263.274 0 .513.088.718.263.205.176.308.46.308.85 0 .384-.103.667-.308.85a1.047 1.047 0 01-.718.273 1.05 1.05 0 01-.737-.273c-.198-.183-.298-.466-.298-.85zm8.877 12.383c.228 0 .495-.023.801-.069.306-.045.537-.097.693-.156v1.348c-.162.071-.415.141-.756.21a5.29 5.29 0 01-1.04.102c-2.097 0-3.145-1.103-3.145-3.31v-6.24h-1.514v-.84l1.534-.703.703-2.286h1.045v2.461h3.095v1.368h-3.095v6.19c0 .62.148 1.095.444 1.427.296.332.708.498 1.235.498zm1.953-9.483h1.885l2.315 6.104c.488 1.328.787 2.301.898 2.92h.078c.059-.241.192-.692.4-1.353.209-.66.385-1.19.528-1.587l2.178-6.084h1.894l-4.619 12.207c-.45 1.185-.983 2.035-1.602 2.55-.618.514-1.383.77-2.294.77-.489 0-.974-.055-1.456-.165v-1.397c.326.078.717.117 1.172.117.56 0 1.035-.154 1.426-.463.39-.31.71-.787.957-1.431l.557-1.426zM7.157 45.5H2.001v-1.035l1.68-.381V32.658l-1.68-.4v-1.035h5.156v1.035l-1.68.4v11.426l1.68.38zm9.824 0v-6.855c0-.873-.193-1.522-.58-1.949-.388-.426-.995-.64-1.822-.64-1.1 0-1.9.305-2.398.914-.498.608-.747 1.6-.747 2.973V45.5H9.677V34.777h1.416l.263 1.465h.098a3.31 3.31 0 011.396-1.225 4.492 4.492 0 011.983-.435c1.315 0 2.292.319 2.93.957.638.638.957 1.63.957 2.979V45.5zm6.817 0H22.04V34.777h1.758zm-1.895-13.623c0-.39.1-.674.298-.85.199-.175.444-.263.737-.263.274 0 .513.088.718.263.205.176.308.46.308.85 0 .384-.103.667-.308.85a1.047 1.047 0 01-.718.273 1.05 1.05 0 01-.737-.273c-.199-.183-.298-.466-.298-.85zM30.78 44.26c.228 0 .495-.023.8-.069.307-.045.538-.097.694-.156v1.348c-.163.071-.415.141-.757.21a5.29 5.29 0 01-1.04.102c-2.096 0-3.144-1.103-3.144-3.31v-6.24h-1.514v-.84l1.533-.703.703-2.286H29.1v2.461h3.096v1.368H29.1v6.19c0 .62.149 1.095.445 1.427.296.332.708.498 1.235.498zm5.39 1.24h-1.757V34.777h1.758zm-1.894-13.623c0-.39.1-.674.298-.85.199-.175.444-.263.737-.263.274 0 .513.088.718.263.205.176.308.46.308.85 0 .384-.103.667-.308.85a1.047 1.047 0 01-.718.273 1.05 1.05 0 01-.737-.273c-.199-.183-.298-.466-.298-.85zM46.19 45.5l-.342-1.523h-.078c-.534.67-1.066 1.124-1.596 1.362-.53.237-1.2.356-2.007.356-1.055 0-1.882-.276-2.48-.83-.6-.553-.9-1.334-.9-2.344 0-2.174 1.716-3.313 5.147-3.417l1.817-.069V38.4c0-.813-.176-1.414-.528-1.801-.351-.388-.914-.581-1.689-.581-.566 0-1.102.084-1.606.253-.505.17-.979.359-1.421.567l-.537-1.318a7.958 7.958 0 011.767-.674 7.642 7.642 0 011.895-.244c1.295 0 2.259.286 2.89.859.632.573.948 1.484.948 2.734V45.5zm-3.623-1.22c.983 0 1.756-.266 2.32-.797.563-.53.844-1.284.844-2.26v-.967l-1.582.068c-1.23.046-2.127.241-2.69.586-.563.345-.845.889-.845 1.631 0 .56.171.99.513 1.29.342.299.822.448 1.44.448zm11.807-.02c.228 0 .495-.023.8-.069.307-.045.538-.097.694-.156v1.348c-.163.071-.415.141-.757.21a5.29 5.29 0 01-1.04.102c-2.096 0-3.144-1.103-3.144-3.31v-6.24h-1.514v-.84l1.533-.703.703-2.286h1.045v2.461h3.096v1.368h-3.096v6.19c0 .62.148 1.095.444 1.427.297.332.708.498 1.236.498zm5.39 1.24h-1.757V34.777h1.757zM57.87 31.877c0-.39.1-.674.298-.85.198-.175.444-.263.737-.263.274 0 .513.088.718.263.205.176.307.46.307.85 0 .384-.102.667-.307.85a1.047 1.047 0 01-.718.273 1.05 1.05 0 01-.737-.273c-.199-.183-.298-.466-.298-.85zM65.526 45.5l-4.062-10.723h1.884l2.276 6.319c.45 1.27.736 2.216.86 2.842h.077a11.495 11.495 0 01.176-.64c.04-.127.28-.861.723-2.202l2.285-6.319h1.875L67.548 45.5zm12.354.195c-1.608 0-2.87-.486-3.784-1.46-.915-.973-1.373-2.312-1.373-4.018 0-1.719.427-3.088 1.28-4.107.853-1.019 2.005-1.528 3.457-1.528 1.347 0 2.422.435 3.222 1.304.801.869 1.202 2.046 1.202 3.53v1.064H74.54c.032 1.218.342 2.142.928 2.774.586.631 1.416.947 2.49.947a8.46 8.46 0 001.63-.151c.515-.101 1.117-.298 1.807-.591v1.543a8.506 8.506 0 01-1.67.537c-.52.104-1.136.156-1.845.156zm-.44-9.677c-.84 0-1.504.27-1.992.81s-.778 1.292-.87 2.256h5.46c-.013-1.003-.244-1.764-.693-2.285-.45-.521-1.084-.781-1.905-.781zM137.741 45.5h-1.816l-2.784-9.355c-.41-1.394-.65-2.334-.722-2.823-.104.749-.332 1.71-.684 2.881L129.04 45.5h-1.817l-3.779-14.277h1.875l2.217 8.72c.3 1.14.527 2.272.684 3.399.143-1.068.397-2.237.761-3.506l2.52-8.613h1.855l2.627 8.681c.339 1.127.6 2.272.781 3.438.105-.899.336-2.038.694-3.418l2.207-8.701h1.875zm14.57 0l-1.718-4.424h-5.664l-1.7 4.424h-1.816l5.576-14.336h1.621l5.567 14.336zm-2.256-6.016l-1.601-4.326-.684-2.138c-.195.78-.4 1.494-.615 2.138l-1.621 4.326zm10.098 6.016h-5.156v-1.035l1.68-.381V32.658l-1.68-.4v-1.035h5.156v1.035l-1.68.4v11.426l1.68.38z" /> + </g> + </g> + </svg> + </a> + </div> + </header> +</div> diff --git a/_includes/help-improve.html b/_includes/help-improve.html new file mode 100644 index 0000000000..340acedf69 --- /dev/null +++ b/_includes/help-improve.html @@ -0,0 +1,17 @@ +<aside class="box box-icon box-space-above" id="helpimprove" style="grid-column: 2 / 8; grid-row: 3"> + <header class="box-h box-h-icon box-h-space-above box-h-icon"> + <svg focusable="false" aria-hidden="true" class="icon-comments" viewBox="0 0 28 28"> + <path d="M22 12c0 4.422-4.922 8-11 8-0.953 0-1.875-0.094-2.75-0.25-1.297 0.922-2.766 1.594-4.344 2-0.422 0.109-0.875 0.187-1.344 0.25h-0.047c-0.234 0-0.453-0.187-0.5-0.453v0c-0.063-0.297 0.141-0.484 0.313-0.688 0.609-0.688 1.297-1.297 1.828-2.594-2.531-1.469-4.156-3.734-4.156-6.266 0-4.422 4.922-8 11-8s11 3.578 11 8zM28 16c0 2.547-1.625 4.797-4.156 6.266 0.531 1.297 1.219 1.906 1.828 2.594 0.172 0.203 0.375 0.391 0.313 0.688v0c-0.063 0.281-0.297 0.484-0.547 0.453-0.469-0.063-0.922-0.141-1.344-0.25-1.578-0.406-3.047-1.078-4.344-2-0.875 0.156-1.797 0.25-2.75 0.25-2.828 0-5.422-0.781-7.375-2.063 0.453 0.031 0.922 0.063 1.375 0.063 3.359 0 6.531-0.969 8.953-2.719 2.609-1.906 4.047-4.484 4.047-7.281 0-0.812-0.125-1.609-0.359-2.375 2.641 1.453 4.359 3.766 4.359 6.375z"></path> + </svg> + <h2> Help improve this page </h2> + </header> + <div class="box-i"> + <p>Please share your ideas, suggestions, or comments via e-mail to the publicly-archived list <a href="mailto:public-agwg-comments@w3.org?subject=%5BUnderstanding%20and%20Techniques%20Feedback%5D">public-agwg-comments@w3.org</a> or via GitHub</p> + <div class="button-group"> + <a href="mailto:public-agwg-comments@w3.org?subject=%5BUnderstanding%20and%20Techniques%20Feedback%5D" + class="button"><span>E-mail</span></a> + <a href="https://github.com/w3c/wcag/issues/" class="button"><span>Fork & Edit on GitHub</span></a> + <a href="https://github.com/w3c/wcag/issues/new" class="button"><span>New GitHub Issue</span></a> + </div> + </div> +</aside> diff --git a/_includes/sidebar.html b/_includes/sidebar.html new file mode 100644 index 0000000000..529933f9a0 --- /dev/null +++ b/_includes/sidebar.html @@ -0,0 +1,8 @@ +<aside class="box nav-hack sidebar standalone-resource__sidebar"> + <header class="box-h">Page Contents</header> + <div class="box-i"> + <nav aria-label="page contents" class="navtoc"> + <ul>{% # Table of Contents is added after Liquid render, in CustomLiquid.ts %}</ul> + </nav> + </div> +</aside> diff --git a/_includes/site-footer.html b/_includes/site-footer.html new file mode 100644 index 0000000000..4d142dad4f --- /dev/null +++ b/_includes/site-footer.html @@ -0,0 +1,29 @@ +<footer class="site-footer grid-4q" aria-label="Site"> + <div class="q1-start q3-end about"> + <div> + <p><a class="largelink" href="https://www.w3.org/WAI/" dir="auto" translate="no" lang="en">W3C Web Accessibility Initiative (WAI)</a></p> + <p>Strategies, standards, and supporting resources to make the Web accessible to people with disabilities.</p> + </div> + <div class="social" dir="auto" translate="no" lang="en"> + <ul> + <li><a href="https://twitter.com/w3c_wai"><svg focusable="false" aria-hidden="true" class="icon-twitter " viewBox="0 0 32 32"><path d="M31.939 6.092c-1.18 0.519-2.44 0.872-3.767 1.033 1.352-0.815 2.392-2.099 2.884-3.631-1.268 0.74-2.673 1.279-4.169 1.579-1.195-1.279-2.897-2.079-4.788-2.079-3.623 0-6.56 2.937-6.56 6.556 0 0.52 0.060 1.020 0.169 1.499-5.453-0.257-10.287-2.876-13.521-6.835-0.569 0.963-0.888 2.081-0.888 3.3 0 2.28 1.16 4.284 2.917 5.461-1.076-0.035-2.088-0.331-2.971-0.821v0.081c0 3.18 2.257 5.832 5.261 6.436-0.551 0.148-1.132 0.228-1.728 0.228-0.419 0-0.82-0.040-1.221-0.115 0.841 2.604 3.26 4.503 6.139 4.556-2.24 1.759-5.079 2.807-8.136 2.807-0.52 0-1.039-0.031-1.56-0.089 2.919 1.859 6.357 2.945 10.076 2.945 12.072 0 18.665-9.995 18.665-18.648 0-0.279 0-0.56-0.020-0.84 1.281-0.919 2.4-2.080 3.28-3.397l-0.063-0.027z"></path></svg> Twitter</a></li> + <li><a href="https://www.w3.org/WAI/feed.xml"><svg focusable="false" aria-hidden="true" class="icon-rss " viewBox="0 0 32 32"><path d="M25.599 32c0-14.044-11.555-25.6-25.599-25.6v-6.4c17.553 0 32 14.447 32 32h-6.401zM4.388 23.22c2.419 0 4.391 1.972 4.391 4.393 0 2.417-1.98 4.387-4.401 4.387-2.417 0-4.377-1.965-4.377-4.387s1.967-4.392 4.388-4.393zM21.212 32h-6.22c0-8.225-6.767-14.993-14.992-14.993v-6.22c11.636 0 21.212 9.579 21.212 21.213z"></path></svg> Feed</a></li> + <li><a href="https://www.youtube.com/channel/UCU6ljj3m1fglIPjSjs2DpRA/playlistsv"><svg focusable="false" aria-hidden="true" class="icon-youtube " viewBox="0 0 32 32"><path d="M31.327 8.273c-0.386-1.353-1.431-2.398-2.756-2.777l-0.028-0.007c-2.493-0.668-12.528-0.668-12.528-0.668s-10.009-0.013-12.528 0.668c-1.353 0.386-2.398 1.431-2.777 2.756l-0.007 0.028c-0.443 2.281-0.696 4.903-0.696 7.585 0 0.054 0 0.109 0 0.163l-0-0.008c-0 0.037-0 0.082-0 0.126 0 2.682 0.253 5.304 0.737 7.845l-0.041-0.26c0.386 1.353 1.431 2.398 2.756 2.777l0.028 0.007c2.491 0.669 12.528 0.669 12.528 0.669s10.008 0 12.528-0.669c1.353-0.386 2.398-1.431 2.777-2.756l0.007-0.028c0.425-2.233 0.668-4.803 0.668-7.429 0-0.099-0-0.198-0.001-0.297l0 0.015c0.001-0.092 0.001-0.201 0.001-0.31 0-2.626-0.243-5.196-0.708-7.687l0.040 0.258zM12.812 20.801v-9.591l8.352 4.803z"></path></svg> YouTube</a></li> + <li><a href="https://www.w3.org/WAI/news/subscribe/" class="button">Get News in Email</a></li> + </ul> + </div> + <div dir="auto" translate="no" lang="en"> + <p>Copyright © {{ "now" | date: "%Y" }} World Wide Web Consortium (<a href="https://www.w3.org/">W3C</a><sup>®</sup>). See <a href="/WAI/about/using-wai-material/">Permission to Use WAI Material</a>.</p> + </div> + </div> + <div dir="auto" translate="no" class="q4-start q4-end" lang="en"> + <ul style="margin-bottom:0"> + <li><a href="/WAI/about/contacting/">Contact WAI</a></li> + <li><a href="/WAI/sitemap/">Site Map</a></li> + <li><a href="/WAI/news/">News</a></li> + <li><a href="/WAI/about/accessibility-statement/">Accessibility Statement</a></li> + <li><a href="/WAI/translations/"> Translations</a></li> + <li><a href="/WAI/roles/">Resources for Roles</a></li> + </ul> + </div> +</footer> diff --git a/_includes/techniques/about.html b/_includes/techniques/about.html new file mode 100644 index 0000000000..a21e7c6107 --- /dev/null +++ b/_includes/techniques/about.html @@ -0,0 +1,34 @@ +{% if technique.obsoleteSince <= version %} +<section class="box obsolete-message"> + <h2 class="box-h">Obsolete</h2> + {% if technique.obsoleteMessage %}<div class="box-i">{{ technique.obsoleteMessage }}</div>{% endif %} +</section> +{% endif %} +{% sectionbox "technique" "About this Technique" %} +{% include "techniques/applicability.html" %} +{% case technique.technology %} +{% when "aria" %} + <p>This technique applies to content using <a href="https://www.w3.org/TR/wai-aria/">WAI-<abbr title="Accessible Rich Internet Applications">ARIA</abbr></a>.</p> +{% when "client-side-script" %} + <p>This technique applies to content using client-side script (JavaScript, ECMAScript).</p> +{% when "css" %} + <p>This technique applies to content using technologies that support <a href="https://www.w3.org/TR/CSS/"><abbr title="Cascading Style Sheets">CSS</abbr></a>.</p> +{% # failures intentionally has no applicability statement %} +{% when "flash" %} + <p>This technique applies to content implemented in Adobe Flash.</p> +{% when "general" %} + <p>This technique applies to content implemented in any technology.</p> +{% when "html" %} + <p>This technique applies to content structured in <a href="https://www.w3.org/TR/html/"><abbr title="HyperText Markup Language">HTML</abbr></a>.</p> +{% when "pdf" %} + <p>This technique applies to content implemented in Adobe Tagged PDF.</p> +{% when "server-side-script" %} + <p>This technique applies to content modified by the server before being sent to the user.</p> +{% when "silverlight" %} + <p>This technique applies to content implemented in Microsoft Silverlight.</p> +{% when "smil" %} + <p>This technique applies to content implemented in <a href="https://www.w3.org/TR/SMIL/">Synchronized Multimedia Integration Language (SMIL)</a>.</p> +{% when "text" %} + <p>This technique applies to content implemented in plain text, including Markdown and similar formats, without use of a structure technology.</p> +{% endcase %} +{% endsectionbox %} diff --git a/_includes/techniques/applicability-association.html b/_includes/techniques/applicability-association.html new file mode 100644 index 0000000000..7ded7f2b75 --- /dev/null +++ b/_includes/techniques/applicability-association.html @@ -0,0 +1,15 @@ +{% # See getTechniqueAssociations in 11ty/techniques.ts for typings %} +{{ association.criterion.id | linkUnderstanding }} +(<strong>{{ association.type }}</strong> +{%- if association.with.length > 0 -%} + , together with {{ association.with | linkTechniques }} +{%- endif -%} +{%- if association.hasUsageChildren %} + using a more specific technique +{%- endif -%} +{%- if association.usageParentIds.length > 0 %} + when used with {{ association.usageParentIds | linkTechniques }} +{%- elsif association.usageParentDescription != "" %} + {{ association.usageParentDescription }} +{%- endif -%} +) \ No newline at end of file diff --git a/_includes/techniques/applicability.html b/_includes/techniques/applicability.html new file mode 100644 index 0000000000..3b62424a2e --- /dev/null +++ b/_includes/techniques/applicability.html @@ -0,0 +1,19 @@ +{% # Autogenerated content added to About box %} +{% if techniqueAssociations %} + {% if techniqueAssociations.size == 1 %} + <p> + This technique relates to + {% include "techniques/applicability-association.html", association: techniqueAssociations[0] %}.</p> + {% else %} + <p>This technique relates to:</p> + <ul> + {% for association in techniqueAssociations %} + <li> + {% include "techniques/applicability-association.html", association: association %} + </li> + {% endfor %} + </ul> + {% endif %} +{% else %} + <p>This technique is not referenced from any Understanding document.</p> +{% endif %} diff --git a/_includes/techniques/h1.html b/_includes/techniques/h1.html new file mode 100644 index 0000000000..3e99c97508 --- /dev/null +++ b/_includes/techniques/h1.html @@ -0,0 +1 @@ +<h1><span>Technique {{ page.fileSlug }}:</span>{{ technique.titleHtml }}</h1> diff --git a/_includes/techniques/head.html b/_includes/techniques/head.html new file mode 100644 index 0000000000..ea96946262 --- /dev/null +++ b/_includes/techniques/head.html @@ -0,0 +1 @@ +<link rel="stylesheet" href="../base.css" /> diff --git a/_includes/techniques/intro/resources.html b/_includes/techniques/intro/resources.html new file mode 100644 index 0000000000..bccea53ad1 --- /dev/null +++ b/_includes/techniques/intro/resources.html @@ -0,0 +1 @@ +<p style="margin-bottom: 1.5em;"><em><small>No endorsement implied.</small></em></p> diff --git a/_includes/test-rules.html b/_includes/test-rules.html new file mode 100644 index 0000000000..c2842bf0df --- /dev/null +++ b/_includes/test-rules.html @@ -0,0 +1,25 @@ +{% if testRules.size > 0 %} +{%- if isTechniques -%} + {% assign understandingActRulesHref = "../../understanding/understanding-act-rules.html" %} +{%- else -%} + {% assign understandingActRulesHref = "understanding-act-rules.html" %} +{%- endif -%} +<section id="test-rules"> + <h2>Test Rules</h2> + <p> + The following are Test Rules + {% if isTechniques -%} + related to this Technique. + {%- elsif isUnderstanding -%} + for certain aspects of this Success Criterion. + {%- endif %} + It is not necessary to use these particular Test Rules to check for conformance with WCAG, but they are defined and approved test methods. + For information on using Test Rules, see <a href="{{ understandingActRulesHref }}">Understanding Test Rules for WCAG Success Criteria</a>. + </p> + <ul> + {% for rule in testRules %} + <li><a href="/WAI{{ rule.permalink }}">{{ rule.title }}</a></li> + {% endfor %} + </ul> +</section> +{%- endif %} diff --git a/_includes/toc.html b/_includes/toc.html new file mode 100644 index 0000000000..4c521cea3a --- /dev/null +++ b/_includes/toc.html @@ -0,0 +1,38 @@ +{% if isTechniques %} + {% for technology in technologies %} + {%- if techniques[technology].size == 0 -%}{%- continue -%}{%- endif -%} + {%- assign technologyTitle = technologyTitles[technology] -%} + <h2 id="{{ technology }}">{{ technologyTitle }}<span class="permalink"><a href="#{{ technology }}" aria-label="Permalink for {{ technologyTitle }}" title="Permalink for {{ technologyTitle }}"><span>§</span></a></span></h2> + + <ul class="toc-wcag-docs"> + {% for technique in techniques[technology] %} + <li>{{ technique.id | linkTechniques }}</li> + {% endfor %} + </ul> + {% endfor %} +{% elsif isUnderstanding %} + {%- # See 11ty/guidelines.ts for typings -%} + {% for principle in principles %} + <section id="{{ principle.id }}"> + <h2>{{ principle.name }}</h2> + {% for guideline in principle.guidelines %} + <section id="{{ guideline.id }}"> + <h3><a href="{{ guideline.id }}"><span class="secno">{{ guideline.num }} </span>{{ guideline.name }}</a></h3> + <ul> + {% for criterion in guideline.successCriteria %} + <li><a href="{{ criterion.id }}"><span class="secno">{{ criterion.num }} </span>{{ criterion.name }}</a></li> + {% endfor %} + </ul> + </section> + {% endfor %} + </section> + {% endfor %} + <section id="other"> + <h2>Other Understanding documents</h2> + <ul class="toc-wcag-docs"> + {% for doc in understandingDocs %} + <li><a href="{{ doc.id }}">{{ doc.name }}</a></li> + {% endfor %} + </ul> + </section> +{% endif %} diff --git a/_includes/understanding/about.html b/_includes/understanding/about.html new file mode 100644 index 0000000000..098d0b9997 --- /dev/null +++ b/_includes/understanding/about.html @@ -0,0 +1,9 @@ +{%- if guideline.type == "SC" -%} + {% sectionbox "success-criterion" "Success Criterion (SC)" -%} + {{ guideline.content }} + {%- endsectionbox %} +{%- elsif guideline.type == "Guideline" -%} + {% sectionbox "guideline" "Guideline" -%} + {{ guideline.content }} + {%- endsectionbox %} +{%- endif -%} diff --git a/_includes/understanding/h1.html b/_includes/understanding/h1.html new file mode 100644 index 0000000000..29db4de86b --- /dev/null +++ b/_includes/understanding/h1.html @@ -0,0 +1,10 @@ +{%- # Expanded heading content, intended only for guideline and SC understanding pages -%} +<h1> + <span class="standalone-resource__type-of-guidance"> + Understanding + <a href="https://w3.org/TR/WCAG{{ version }}#{{ page.fileSlug }}"> + {{- guideline.type }} {{ guideline.num -}} + </a>: + </span>{{ guideline.name }} + {%- if guideline.level %} (Level {{ guideline.level }}){% endif %} +</h1> diff --git a/_includes/understanding/head.html b/_includes/understanding/head.html new file mode 100644 index 0000000000..a4e625abff --- /dev/null +++ b/_includes/understanding/head.html @@ -0,0 +1 @@ +<link rel="stylesheet" href="base.css" /> diff --git a/_includes/understanding/intro/advisory.html b/_includes/understanding/intro/advisory.html new file mode 100644 index 0000000000..3c64c9a91c --- /dev/null +++ b/_includes/understanding/intro/advisory.html @@ -0,0 +1,15 @@ +{%- if guideline.type == "Guideline" -%} +<p> + Specific techniques for meeting each Success Criterion for this guideline + are listed in the understanding sections for each Success Criterion (listed below). + If there are techniques, however, for addressing this guideline that do not fall under + any of the success criteria, they are listed here. + These techniques are not required or sufficient for meeting any success criteria, + but can make certain types of Web content more accessible to more people. +</p> +{%- else -%} +<p> + Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. + Not all techniques can be used or would be effective in all situations. +</p> +{%- endif -%} diff --git a/_includes/understanding/intro/failure.html b/_includes/understanding/intro/failure.html new file mode 100644 index 0000000000..b1865f7e74 --- /dev/null +++ b/_includes/understanding/intro/failure.html @@ -0,0 +1,3 @@ +<p> + The following are common mistakes that are considered failures of this Success Criterion by the WCAG Working Group. +</p> diff --git a/_includes/understanding/intro/resources.html b/_includes/understanding/intro/resources.html new file mode 100644 index 0000000000..a782d78bdc --- /dev/null +++ b/_includes/understanding/intro/resources.html @@ -0,0 +1 @@ +<p>Resources are for information purposes only, no endorsement implied.</p> diff --git a/_includes/understanding/intro/sufficient-situation.html b/_includes/understanding/intro/sufficient-situation.html new file mode 100644 index 0000000000..fabc003240 --- /dev/null +++ b/_includes/understanding/intro/sufficient-situation.html @@ -0,0 +1,4 @@ +<p> + Select the situation below that matches your content. + Each situation includes techniques or combinations of techniques that are known and documented to be sufficient for that situation. +</p> diff --git a/_includes/understanding/intro/techniques.html b/_includes/understanding/intro/techniques.html new file mode 100644 index 0000000000..bfb3ffa5e9 --- /dev/null +++ b/_includes/understanding/intro/techniques.html @@ -0,0 +1,8 @@ +<p> + Each numbered item in this section represents a technique or combination of techniques + that the WCAG Working Group deems sufficient for meeting this Success Criterion. + However, it is not necessary to use these particular techniques. + For information on using other techniques, see + <a href="understanding-techniques">Understanding Techniques for WCAG Success Criteria</a>, + particularly the "Other Techniques" section. +</p> diff --git a/_includes/understanding/key-terms.html b/_includes/understanding/key-terms.html new file mode 100644 index 0000000000..bea2906e38 --- /dev/null +++ b/_includes/understanding/key-terms.html @@ -0,0 +1,6 @@ +<section id="key-terms"> + <details> + <summary><h2>Key Terms</h2></summary> + <dl></dl> + </details> +</section> diff --git a/_includes/understanding/navigation-index.html b/_includes/understanding/navigation-index.html new file mode 100644 index 0000000000..12fdd810df --- /dev/null +++ b/_includes/understanding/navigation-index.html @@ -0,0 +1,19 @@ +{% comment %} +Navigation used for Understanding index/about pages only. +See _includes/header.html for expected input notes +{% endcomment %} +<div class="default-grid nav-container nav-page-specific"> + <div class="default-grid"> + <nav class="nav" aria-label="{{ headerLabel }}"> + <ul> + <li class="nav__item"> + {% if page.fileSlug == "understanding" %} + <a href="." class="active" aria-current="page">All {{ headerLabel }}</a> + {% else %} + <a href=".">All {{ headerLabel }}</a> + {% endif %} + </li> + </ul> + </nav> + </div> +</div> diff --git a/_includes/understanding/navigation.html b/_includes/understanding/navigation.html new file mode 100644 index 0000000000..9f41d9ae5e --- /dev/null +++ b/_includes/understanding/navigation.html @@ -0,0 +1,50 @@ +{% comment %} +Navigation used for individual Understanding pages. +See _includes/header.html for expected input notes +{% endcomment %} +<div class="default-grid nav-container nav-page-specific"> + <div class="nav"> + <nav class="nav standalone-resource-pager" aria-label="{{ headerLabel }}"> + <ul> + <li class="nav__item"> + {% if page.fileSlug == "understanding" %} + <a href="." class="active" aria-current="page">All {{ headerLabel }}</a> + {% else %} + <a href=".">All {{ headerLabel }}</a> + {% endif %} + </li> + {% # nav data is set up in eleventy.config.ts via 11ty/guidelines.ts %} + {% if nav.parent %} + <li class="nav__item"> + <a href="{{ nav.parent.id }}"> + <svg alt="up" focusable="false" aria-hidden="true" class="icon-arrow-up-thin pager-icon" viewBox="0 0 16 16"> + <path fill-rule="evenodd" d="M8 12a.5.5 0 0 0 .5-.5V5.707l2.146 2.147a.5.5 0 0 0 .708-.708l-3-3a.5.5 0 0 0-.708 0l-3 3a.5.5 0 1 0 .708.708L7.5 5.707V11.5a.5.5 0 0 0 .5.5z"></path> + </svg> + {{ nav.parent.type }}: {{ nav.parent.name }} + </a> + </li> + {% endif %} + {% if nav.previous %} + <li class="nav__item"> + <a href="{{ nav.previous.id }}"> + <svg focusable="false" aria-hidden="true" class="icon-arrow-left-thin pager-icon" viewBox="0 0 16 16"> + <path fill-rule="evenodd" d="M12 8a.5.5 0 0 1-.5.5H5.707l2.147 2.146a.5.5 0 0 1-.708.708l-3-3a.5.5 0 0 1 0-.708l3-3a.5.5 0 1 1 .708.708L5.707 7.5H11.5a.5.5 0 0 1 .5.5z"></path> + </svg> + Previous {{ nav.previous.type }}: {{ nav.previous.name }} + </a> + </li> + {% endif %} + {% if nav.next %} + <li class="nav__item"> + <a href="{{ nav.next.id }}"> + Next {{ nav.next.type }}: {{ nav.next.name }} + <svg focusable="false" aria-hidden="true" class="icon-arrow-right-thin pager-icon" viewBox="0 0 16 16"> + <path fill-rule="evenodd" d="M4 8a.5.5 0 0 1 .5-.5h5.793L8.146 5.354a.5.5 0 1 1 .708-.708l3 3a.5.5 0 0 1 0 .708l-3 3a.5.5 0 0 1-.708-.708L10.293 8.5H4.5A.5.5 0 0 1 4 8z"></path> + </svg> + </a> + </li> + {% endif %} + </ul> + </nav> + </div> +</div> diff --git a/_includes/understanding/success-criteria.html b/_includes/understanding/success-criteria.html new file mode 100644 index 0000000000..5a1804afc2 --- /dev/null +++ b/_includes/understanding/success-criteria.html @@ -0,0 +1,10 @@ +{%- if guideline.successCriteria %} + <section id="success-criteria"> + <h2>Success Criteria for this Guideline</h2> + <ul> + {% for criterion in guideline.successCriteria %} + <li><a href="{{ criterion.id }}">{{ criterion.num }} {{ criterion.name }}</a></li> + {% endfor %} + </ul> + </section> +{% endif -%} diff --git a/_includes/wai-site-footer.html b/_includes/wai-site-footer.html new file mode 100644 index 0000000000..fe7fabd0f1 --- /dev/null +++ b/_includes/wai-site-footer.html @@ -0,0 +1,17 @@ +<footer id="wai-site-footer" class="page-footer default-grid" aria-label="Page"> + <div class="inner" style="grid-column: 2 / 8"> + <p><strong>Date:</strong> Updated {{ page.date | date_to_long_string }}.</p> + <p><strong>Developed by</strong> + <a href="https://www.w3.org/groups/wg/ag/participants">Accessibility Guidelines Working Group (AG WG) Participants</a> + (Co-Chairs: Alastair Campbell, Charles Adams, Rachael Bradley Montgomery. W3C Staff Contact: Kevin White). + </p> + <p>The content was developed as part of the + <a href="https://www.w3.org/WAI/about/projects/#us">WAI-Core projects</a> funded by U.S. Federal funds. + The user interface was designed by the Education and Outreach Working Group + (<a href="https://www.w3.org/groups/wg/eowg/participants">EOWG</a>) with contributions from + Shadi Abou-Zahra, Steve Lee, and Shawn Lawton Henry as part of the + <a href="https://www.w3.org/WAI/about/projects/wai-guide/">WAI-Guide</a> project, + co-funded by the European Commission. + </p> + </div> +</footer> diff --git a/_includes/waiscript.html b/_includes/waiscript.html new file mode 100644 index 0000000000..7f65b9f8f8 --- /dev/null +++ b/_includes/waiscript.html @@ -0,0 +1,29 @@ +<link rel="stylesheet" href="../a11y-light.css" /> +<script src="../highlight.min.js"></script> +<script> + hljs.configure({ + cssSelector: 'pre' + }); + hljs.highlightAll(); + var translationStrings = {}; /* fix WAI JS */ +</script> +<script src="https://www.w3.org/WAI/assets/scripts/main.js"></script> +{% # Matomo %} +<script> + var _paq = _paq || []; + /* tracker methods like "setCustomDimension" should be called before "trackPageView" */ + _paq.push(["setDoNotTrack", true]); + _paq.push(['trackPageView']); + _paq.push(['enableLinkTracking']); + (function () { + var u = "//www.w3.org/analytics/piwik/"; + _paq.push(['setTrackerUrl', u + 'piwik.php']); + _paq.push(['setSiteId', '328']); + var d = document, g = d.createElement('script'), s = d.getElementsByTagName('script')[0]; + g.type = 'text/javascript'; g.async = true; g.defer = true; g.src = u + 'piwik.js'; s.parentNode.insertBefore(g, s); + })(); +</script> +<noscript> + <p><img src="//www.w3.org/analytics/piwik/piwik.php?idsite=328&rec=1" style="border:0;" alt="" /></p> +</noscript> +{% # End Matomo Code %} diff --git a/acknowledgements/ag-contributors.html b/acknowledgements/ag-contributors.html index 51f9e6ddaa..4d1a2542cd 100644 --- a/acknowledgements/ag-contributors.html +++ b/acknowledgements/ag-contributors.html @@ -1,4 +1,4 @@ <section id="ack_participants-previous"> <h2>Other previously active WCAG WG participants and other contributors to WCAG 2.0, WCAG 2.1, or supporting resources </h2> - <p>Paul Adam, Jenae Andershonis, Wilhelm Joys Andersen, Andrew Arch, Avi Arditti, Aries Arditi, Mark Barratt, Mike Barta, Sandy Bartell, Kynn Bartlett, Chris Beer, Charles Belov, Marco Bertoni, Harvey Bingham, Chris Blouch, Paul Bohman, Frederick Boland, Denis Boudreau, Patrice Bourlon, Andy Brown, Dick Brown, Doyle Burnett, Raven Calais, Ben Caldwell, Tomas Caspers, Roberto Castaldo, Sofia Celic-Li, Sambhavi Chandrashekar, Mike Cherim, Jonathan Chetwynd, Wendy Chisholm, Alan Chuter, David M Clark, Joe Clark, Darcy Clarke, James Coltham, Earl Cousins, James Craig, Tom Croucher, Pierce Crowell, Nir Dagan, Daniel Dardailler, Geoff Deering, Sébastien Delorme, Pete DeVasto, Iyad Abu Doush, Sylvie Duchateau, Cherie Eckholm, Roberto Ellero, Don Evans, Gavin Evans, Neal Ewers, Steve Faulkner, Bengt Farre, Lainey Feingold, Wilco Fiers, Michel Fitos, Alan J. Flavell, Nikolaos Floratos, Kentarou Fukuda, Miguel Garcia, P.J. Gardner, Alistair Garrison, Greg Gay, Becky Gibson, Al Gilman, Kerstin Goldsmith, Michael Grade, Karl Groves, Loretta Guarino Reid, Jon Gunderson, Emmanuelle Gutiérrez y Restrepo, Brian Hardy, Eric Hansen, Benjamin Hawkes-Lewis, Sean Hayes, Shawn Henry, Hans Hillen, Donovan Hipke, Bjoern Hoehrmann, Allen Hoffman, Chris Hofstader, Yvette Hoitink, Martijn Houtepen, Carlos Iglesias, Richard Ishida, Jonas Jacek, Ian Jacobs, Phill Jenkins, Barry Johnson, Duff Johnson, Jyotsna Kaki, Shilpi Kapoor, Leonard R. Kasday, Kazuhito Kidachi, Ken Kipness, Johannes Koch, Marja-Riitta Koivunen, Preety Kumar, Kristjan Kure, Andrew LaHart, Gez Lemon, Chuck Letourneau, Aurélien Levy, Harry Loots, Scott Luebking, Tim Lacy, Jim Ley, Alex Li, William Loughborough, N Maffeo, Mark Magennis, Kapsi Maria, Luca Mascaro, Matt May, Sheena McCullagh, Liam McGee, Jens Oliver Meiert, Niqui Merret, Jonathan Metz, Alessandro Miele, Steven Miller, Mathew J Mirabella, Matt May, Marti McCuller, Sorcha Moore, Charles F. Munat, Robert Neff, Charles Nevile, Liddy Nevile, Dylan Nicholson, Bruno von Niman, Tim Noonan, Sebastiano Nutarelli, Graham Oliver, Sean B. Palmer, Devarshi Pant, Nigel Peck, Anne Pemberton, David Poehlman, Ian Pouncey, Charles Pritchard, Kerstin Probiesch, W Reagan, Adam Victor Reed, Chris Reeve, Chris Ridpath, Lee Roberts, Mark Rogers, Raph de Rooij, Gregory J. Rosmaita, Matthew Ross, Sharron Rush, Joel Sanda, Janina Sajka, Roberto Scano, Gordon Schantz, Tim van Schie, Wolf Schmidt, Stefan Schnabel, Cynthia Shelly, Glenda Sims, John Slatin, Becky Smith, Jared Smith, Andi Snow-Weaver, Neil Soiffer, Mike Squillace, Michael Stenitzer, Diane Stottlemyer, Christophe Strobbe, Sarah J Swierenga, Jim Thatcher, Terry Thompson, Justin Thorp, David Todd, Mary Utt, Jean Vanderdonckt, Carlos A Velasco, Eric Velleman, Gijs Veyfeyken, Dena Wainwright, Paul Walsch, Daman Wandke, Richard Warren, Elle Waters, Takayuki Watanabe, Gian Wild, David Wooley, Wu Wei, Kenny Zhang, Leona Zumbo.</p> + <p>Paul Adam, Jenae Andershonis, Wilhelm Joys Andersen, Andrew Arch, Avi Arditti, Aries Arditi, Tom Babinszki, Mark Barratt, Mike Barta, Sandy Bartell, Kynn Bartlett, Chris Beer, Charles Belov, Marco Bertoni, Harvey Bingham, Chris Blouch, Paul Bohman, Frederick Boland, Denis Boudreau, Patrice Bourlon, Andy Brown, Dick Brown, Doyle Burnett, Raven Calais, Ben Caldwell, Tomas Caspers, Roberto Castaldo, Sofia Celic-Li, Sambhavi Chandrashekar, Mike Cherim, Jonathan Chetwynd, Wendy Chisholm, Alan Chuter, David M Clark, Joe Clark, Darcy Clarke, James Coltham, Earl Cousins, James Craig, Tom Croucher, Pierce Crowell, Nir Dagan, Daniel Dardailler, Geoff Deering, Sébastien Delorme, Pete DeVasto, Iyad Abu Doush, Sylvie Duchateau, Cherie Eckholm, Roberto Ellero, Don Evans, Gavin Evans, Neal Ewers, Steve Faulkner, Bengt Farre, Lainey Feingold, Wilco Fiers, Michel Fitos, Alan J. Flavell, Nikolaos Floratos, Kentarou Fukuda, Miguel Garcia, P.J. Gardner, Alistair Garrison, Greg Gay, Becky Gibson, Al Gilman, Kerstin Goldsmith, Michael Grade, Karl Groves, Loretta Guarino Reid, Jon Gunderson, Emmanuelle Gutiérrez y Restrepo, Brian Hardy, Eric Hansen, Benjamin Hawkes-Lewis, Sean Hayes, Shawn Henry, Hans Hillen, Donovan Hipke, Bjoern Hoehrmann, Allen Hoffman, Chris Hofstader, Yvette Hoitink, Martijn Houtepen, Carlos Iglesias, Richard Ishida, Jonas Jacek, Ian Jacobs, Phill Jenkins, Barry Johnson, Duff Johnson, Jyotsna Kaki, Shilpi Kapoor, Leonard R. Kasday, Kazuhito Kidachi, Ken Kipness, Johannes Koch, Marja-Riitta Koivunen, Maureen Kraft, Preety Kumar, Kristjan Kure, Andrew LaHart, Gez Lemon, Chuck Letourneau, Aurélien Levy, Harry Loots, Scott Luebking, Tim Lacy, Jim Ley, Alex Li, William Loughborough, N Maffeo, Mark Magennis, Erich Manser, Kapsi Maria, Luca Mascaro, Matt May, Sheena McCullagh, Liam McGee, Jens Oliver Meiert, Niqui Merret, Jonathan Metz, Alessandro Miele, Steven Miller, Mathew J Mirabella, Matt May, Marti McCuller, Sorcha Moore, Charles F. Munat, Robert Neff, Charles Nevile, Liddy Nevile, Dylan Nicholson, Bruno von Niman, Tim Noonan, Sebastiano Nutarelli, Graham Oliver, Sean B. Palmer, Charu Pandhi, evarshi Pant, Nigel Peck, Anne Pemberton, David Poehlman, Ian Pouncey, Charles Pritchard, Kerstin Probiesch, W Reagan, Adam Victor Reed, Chris Reeve, Chris Ridpath, Lee Roberts, Mark Rogers, Raph de Rooij, Gregory J. Rosmaita, Matthew Ross, Sharron Rush, Joel Sanda, Janina Sajka, Roberto Scano, Gordon Schantz, Tim van Schie, Wolf Schmidt, Stefan Schnabel, Cynthia Shelly, Glenda Sims, John Slatin, Becky Smith, Jared Smith, Andi Snow-Weaver, Neil Soiffer, Mike Squillace, Michael Stenitzer, Diane Stottlemyer, Christophe Strobbe, Sarah J Swierenga, Jim Thatcher, Terry Thompson, Justin Thorp, David Todd, Mary Utt, Jean Vanderdonckt, Carlos A Velasco, Eric Velleman, Gijs Veyfeyken, Dena Wainwright, Paul Walsch, Daman Wandke, Richard Warren, Elle Waters, Takayuki Watanabe, Gian Wild, David Wooley, Wu Wei, Kenny Zhang, Leona Zumbo.</p> </section> \ No newline at end of file diff --git a/acknowledgements/ag-wg-active.html b/acknowledgements/ag-wg-active.html index 811548ec79..19cc2fd7ea 100644 --- a/acknowledgements/ag-wg-active.html +++ b/acknowledgements/ag-wg-active.html @@ -2,110 +2,92 @@ <h2>Participants of the AG WG active in the development of this document:</h2> <ul> <li>Jake Abma (Invited Expert)</li> - <li>Shadi Abou-Zahra (W3C)</li> + <li>Shadi Abou-Zahra (Amazon)</li> <li>Chuck Adams (Oracle Corporation)</li> <li>Amani Ali (Nomensa)</li> <li>Jim Allan (Invited Expert)</li> - <li>Paul Adam (Deque Systems, Inc.)</li> - <li>Christopher Auclair (VitalSource | Ingram Content Group)</li> <li>Jon Avila (Level Access)</li> - <li>Tom Babinszki (IBM Corporation)</li> <li>Bruce Bailey (U.S. Access Board)</li> <li>Renaldo Bernard (University of Southampton)</li> - <li>Chris Blouch (Level Access)</li> - <li>Denis Boudreau (Deque Systems, Inc.)</li> + <li>Dan Bjorge (Deque Systems, Inc.)</li> + <li>Peter Bossley (Thomson Reuters)</li> + <li>Rachael Bradley Montgomery (Library of Congress)</li> <li>Judy Brewer (W3C)</li> <li>Shari Butler (Pearson plc)</li> <li>Thaddeus Cambron (Invited Expert)</li> <li>Alastair Campbell (Nomensa)</li> <li>Laura Carlson (Invited Expert)</li> - <li>Louis Cheng (Google)</li> - <li>Pietro Cirrincione (Invited Expert)</li> - <li>Vivienne Conway (Web Key IT Pty Ltd)</li> + <li>Sukriti Chadha (Invited Expert)</li> + <li>Rafal Charlampowicz (AccessibilityOZ)</li> <li>Michael Cooper (W3C)</li> <li>Jennifer Delisi (Invited Expert)</li> - <li>Romain Deltour (DAISY Consortium)</li> <li>Wayne Dick (Knowbility, Inc)</li> - <li>Chaohai Ding (University of Southampton)</li> <li>Kim Dirks (Thomson Reuters)</li> - <li>Shwetank Dixit (BarrierBreak Technologies)</li> - <li>Anthony Doran (TextHelp)</li> <li>E.A. Draffan (University of Southampton)</li> <li>Eric Eggert (W3C)</li> <li>Michael Elledge (Invited Expert)</li> + <li>Steve Faulkner (TPGi)</li> <li>David Fazio (Invited Expert)</li> <li>Wilco Fiers (Deque Systems, Inc.)</li> <li>Detlev Fischer (Invited Expert)</li> - <li>John Foliot (Deque Systems, Inc.)</li> + <li>John Foliot (Invited Expert)</li> <li>Matt Garrish (DAISY Consortium)</li> <li>Alistair Garrison (Level Access)</li> + <li>Jaunita George (Navy Federal Credit Union)</li> <li>Michael Gower (IBM Corporation)</li> - <li>Jon Gunderson</li> <li>Markku Hakkinen (Educational Testing Service)</li> + <li>Charles Hall (Invited Expert)</li> <li>Katie Haritos-Shea (Knowbility, Inc)</li> - <li>Andy Heath (Invited Expert)</li> + <li>Dan Harper-Wain (HM Government)</li> <li>Shawn Henry (W3C)</li> - <li>Thomas Hoffman (Educational Testing Service)</li> - <li>Sarah Horton (The Paciello Group, LLC)</li> - <li>Stefan Johansson (Invited Expert)</li> + <li>Sarah Horton (Invited Expert)</li> + <li>Abi James (University of Southampton)</li> <li>Marc Johlic (IBM Corporation)</li> - <li>Rick Johnson (VitalSource | Ingram Content Group)</li> - <li>Crystal Jones (Microsoft Corporation)</li> + <li>Oliver Keim (SAP SE)</li> <li>Andrew Kirkpatrick (Adobe)</li> <li>John Kirkwood (Invited Expert)</li> - <li>Jason Kiss (Department of Internal Affairs, New Zealand Government)</li> - <li>Maureen Kraft (IBM Corporation)</li> - <li>JaEun Ku (University of Illinois at Urbana-Champaign)</li> - <li>Patrick Lauke (The Paciello Group, LLC)</li> + <li>JaEun Jemma Ku (University of Illinois Chicago)</li> + <li>Patrick H. Lauke (TetraLogical)</li> <li>Shawn Lauriat (Google, Inc.)</li> <li>Steve Lee (Invited Expert)</li> - <li>Alex Li (Microsoft Corporation)</li> <li>Chris Loiselle (Invited Expert)</li> - <li>Greg Lowney (Invited Expert)</li> - <li>Adam Lund (Thomson Reuters)</li> <li>David MacDonald (Invited Expert)</li> - <li>Erich Manser (IBM Corporation)</li> - <li>Kurt Mattes (Deque Systems, Inc.)</li> - <li>Scott McCormack (Level Access)</li> - <li>Chris McMeeking (Deque Systems, Inc.)</li> <li>Jan McSorley (Pearson plc)</li> + <li>Rain Breaw Michaels (Google LLC)</li> <li>Neil Milliken (Unify Software and Solutions)</li> - <li>Rachael Montgomery (Invited Expert)</li> <li>Mary Jo Mueller (IBM Corporation)</li> + <li>Jay Mullen (College Board)</li> <li>Brooks Newton (Thomson Reuters)</li> + <li>Gundula Niemann (SAP SE)</li> <li>James Nurthen (Oracle Corporation)</li> + <li>Lori Oakley (Oracle Corporation)</li> <li>Joshue O Connor (Invited Expert)</li> + <li>Scott O'Hara (Microsoft)</li> <li>Sailesh Panchang (Deque Systems, Inc.)</li> - <li>Charu Pandhi (IBM Corporation)</li> <li>Kim Patch (Invited Expert)</li> <li>Melanie Philipp (Deque Systems, Inc.)</li> <li>Mike Pluke (Invited Expert)</li> - <li>Ian Pouncey (The Paciello Group, LLC)</li> + <li>Ian Pouncey (TetraLogical)</li> <li>Ruoxi Ran (W3C)</li> <li>Stephen Repsher (Invited Expert)</li> - <li>Jan Richards (Invited Expert)</li> <li>John Rochford (Invited Expert)</li> - <li>Marla Runyan (Invited Expert)</li> <li>Stefan Schnabel (SAP SE)</li> <li>Ayelet Seeman (Invited Expert)</li> <li>Lisa Seeman-Kestenbaum (Invited Expert)</li> <li>Glenda Sims (Deque Systems, Inc.)</li> <li>Avneesh Singh (DAISY Consortium)</li> - <li>David Sloan (The Paciello Group, LLC)</li> - <li>Alan Smith (Invited Expert)</li> - <li>Jim Smith (Unify Software and Solutions)</li> + <li>David Sloan (TPGi)</li> <li>Andrew Somers (Invited Expert)</li> - <li>Adam Solomon (Invited Expert)</li> - <li>Jaeil Song (National Information Society Agency (NIA))</li> <li>Jeanne Spellman (TetraLogical)</li> + <li>Francis Storr (Intel)</li> + <li>Poornima Badhan Subramanian (Invited Expert)</li> + <li>Ben Tillyer (Invited Expert)</li> <li>Makoto Ueki (Invited Expert)</li> - <li>Jatin Vaishnav (Deque Systems, Inc.)</li> <li>Gregg Vanderheiden (Raising the Floor)</li> - <li>Evangelos Vlachogiannis (Fraunhofer Gesellschaft)</li> <li>Kathleen Wahlbin (Invited Expert)</li> - <li>Can Wang (Zhejiang University)</li> - <li>Léonie Watson (The Paciello Group, LLC)</li> + <li>Léonie Watson (TetraLogical)</li> <li>Jason White (Educational Testing Service)</li> + <li>White, Kevin (W3C Staff)</li> <li>Mark Wilcock (Unify Software and Solutions)</li> </ul> -</section> \ No newline at end of file +</section> diff --git a/acknowledgements/ag-wg-participants.html b/acknowledgements/ag-wg-participants.html index 2e5143a84a..bd53c4ded9 100644 --- a/acknowledgements/ag-wg-participants.html +++ b/acknowledgements/ag-wg-participants.html @@ -1,8 +1,8 @@ <section class="section" id="ack_group"> - <h4>Participants active in the ARIA WG at the time of publication</h4> + <h4>Participants active in the AG WG at the time of publication</h4> <ul> <li>Abma, Jake (Invited expert)</li> - <li>Abou-Zahra, Shadi (W3C Staff)</li> + <li>Abou-Zahra, Shadi (Amazon)</li> <li>Adams, Charles (Oracle Corporation)</li> <li>Ali, Amani (Nomensa)</li> <li>Allan, Jim (W3C invited expert)</li> @@ -17,11 +17,13 @@ <h4>Participants active in the ARIA WG at the time of publication</h4> <li>Bohman, Paul (Deque Systems, Inc.)</li> <li>Bostic, Trevor (MITRE Corporation)</li> <li>Boudreau, Denis (Deque Systems, Inc.)</li> + <li>Bradley Montgomery, Rachael (Library of Congress)</li> <li>Brewer, Judy (W3C Staff)</li> <li>Bunge, Kim (The Paciello Group, LLC)</li> <li>Butler, Shari (Pearson plc)</li> <li>Campbell, Alastair (Nomensa)</li> <li>Carlson, Laura (Invited expert)</li> + <li>Chadha, Sukriti (Invited expert)</li> <li>Charlampowicz, Rafal (AccessibilityOz)</li> <li>Conway, Vivienne (Web Key IT Pty Ltd)</li> <li>Cooper, Michael (W3C Staff)</li> @@ -79,7 +81,7 @@ <h4>Participants active in the ARIA WG at the time of publication</h4> <li>Ku, JaEun (University of Illinois at Urbana-Champaign)</li> <li>Kumar, Preety (Deque Systems, Inc.)</li> <li>Kurapati, Sujasree (Deque Systems, Inc.)</li> - <li>Lauke, Patrick (The Paciello Group, LLC)</li> + <li>Lauke, Patrick (TetraLogical)</li> <li>Lauriat, Shawn (Google, Inc.)</li> <li>Lazrus, Robin (Pearson plc)</li> <li>Lee, Jerry (Macmillan Learning)</li> @@ -93,7 +95,6 @@ <h4>Participants active in the ARIA WG at the time of publication</h4> <li>McCormack, Scott (SSB BART Group)</li> <li>McMeeking, Chris (Deque Systems, Inc.)</li> <li>McSorley, Jan (Pearson plc)</li> - <li>Montgomery, Rachael (Invited expert)</li> <li>Mueller, Mary Jo (IBM Corporation)</li> <li>Mussinelli, Cristina (Fondazione LIA)</li> <li>Nandakumar, Jey (Deque Systems, Inc.)</li> @@ -141,6 +142,7 @@ <h4>Participants active in the ARIA WG at the time of publication</h4> <li>Wegner, Shane (Thomson Reuters Corp.)</li> <li>Wentz, Pascal (SAP SE)</li> <li>White, Jason (Educational Testing Service)</li> + <li>White, Kevin (W3C Staff)</li> <li>Wild, Gian (AccessibilityOz)</li> <li>Williams, Jan (The Paciello Group, LLC)</li> </ul> diff --git a/acknowledgements/funders.html b/acknowledgements/funders.html index 77b78f87d7..7d1b5f9402 100644 --- a/acknowledgements/funders.html +++ b/acknowledgements/funders.html @@ -1,4 +1,4 @@ -<section> +<section id="enabling-funders"> <h2>Enabling funders</h2> - <p>This publication has been funded in part with U.S. Federal funds from the Health and Human Services, National Institute on Disability, Independent Living, and Rehabilitation Research (NIDILRR), initially under contract number ED-OSE-10-C-0067 and now under contract number HHSP23301500054C. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Health and Human Services or the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.</p> -</section> \ No newline at end of file + <p>This publication has been funded in part with U.S. Federal funds from the Health and Human Services, National Institute on Disability, Independent Living, and Rehabilitation Research (NIDILRR), initially under contract number ED-OSE-10-C-0067, then under contract number HHSP23301500054C, and now under HHS75P00120P00168. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Health and Human Services or the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.</p> +</section> diff --git a/act.xml b/act.xml new file mode 100644 index 0000000000..b994f53627 --- /dev/null +++ b/act.xml @@ -0,0 +1 @@ +<?xml version="1.0" encoding="UTF-8"?> \ No newline at end of file diff --git a/biblio.js b/biblio.js index c87140e278..d98875bab7 100644 --- a/biblio.js +++ b/biblio.js @@ -26,26 +26,22 @@ respecConfig.localBiblio = { }, "ISO_9241-112": { - "uri": "https://www.iso.org/standard/64840.html", + "isoNumber": "9241-112", + "href": "https://www.iso.org/standard/64840.html", "title": "Ergonomics of human-system interaction -- Part 112: Principles for the presentation of information", "publisher": "International Standards Organization" }, - "sRGB": { - "authors": [ - "M. Stokes", - "M. Anderson", - "S. Chandrasekar", - "R. Motta" - ], - "date": "November 5, 1996", - "href": "https://www.w3.org/Graphics/Color/sRGB.html", - "title": "A Standard Default Color Space for the Internet - sRGB, Version 1.10" - }, + "ISO_9241-391": { + "isoNumber": "9241-391", + "href": "https://www.iso.org/standard/56350.html", + "title": "Ergonomics of human-system interaction—Part 391: Requirements, analysis and compliance test methods for the reduction of photosensitive seizures", + "publisher": "International Standards Organization" + }, "UNESCO": { - "date": "1997", - "href": "http://www.unesco.org/education/information/nfsunesco/doc/isced_1997.htm", + "date": "2011", + "href": "https://unesdoc.unesco.org/ark:/48223/pf0000219109", "title": "International Standard Classification of Education" } diff --git a/build.xml b/build.xml index 6a77f60971..826a539a19 100644 --- a/build.xml +++ b/build.xml @@ -42,11 +42,15 @@ <delete file="${inputdir.guidelines}/index-flat.html" failonerror="false"/> <delete file="${inputdir.techniques}/index-flat.html" failonerror="false"/> <delete file="${inputdir.understanding}/index-flat.html" failonerror="false"/> + <delete file="${inputdir.understanding}/about-flat.html" failonerror="false"/> <delete file="${inputdir.guidelines}/wcag.xml" failonerror="false"/> <delete file="${inputdir.guidelines}/wcag.json" failonerror="false"/> <delete file="${inputdir.guidelines}/versions.xml" failonerror="false"/> + <delete file="${inputdir.guidelines}/test-sql.sql" failonerror="false"/> <delete file="${inputdir.techniques}/techniques.xml" failonerror="false"/> <delete file="${inputdir.techniques}/technique-associations.xml" failonerror="false"/> + <delete file="${inputdir.techniques}/about-flat.html" failonerror="false"/> + <delete file="${inputdir.understanding}/about-flat.html" failonerror="false"/> <delete file="output.html" failonerror="false"/> <delete dir="output" failonerror="false"/> <delete dir="input" failonerror="false"/> @@ -61,7 +65,7 @@ </xslt> </target> - <target name="guidelines-xml" depends="flatten" description="Build an XML representation of the guidelines"> + <target name="guidelines-xml" depends="flatten, guidelines-versions" description="Build an XML representation of the guidelines"> <xslt in="${inputdir.guidelines}/index-flat.html" out="${inputdir.guidelines}/wcag.xml" style="xslt/generate-structure-xml.xslt"> <classpath path="${classpath.saxon}"/> <factory name="${xslt.factory}"/> @@ -101,7 +105,7 @@ <mkdir dir="output/guidelines/${guidelines.version}"/> <copy file="css/base.css" todir="output/guidelines/${guidelines.version}"/> <copy file="guidelines/guidelines.css" todir="output/guidelines/${guidelines.version}"/> - <copy file="guidelines/relative-luminance.xml" todir="output/guidelines/${guidelines.version}"/> + <copy file="guidelines/relative-luminance.html" todir="output/guidelines/${guidelines.version}"/> <exec executable="curl"> <arg value=""https://labs.w3.org/spec-generator/?type=respec&url=https://raw.githack.com/w3c/wcag/master/guidelines/index.html""/> <arg value="-o"/> @@ -168,194 +172,39 @@ </xslt> </target> - <target name="techniques" depends="techniques-list, techniques-association, techniques-index"> - <makeurl file="${basedir}/techniques/" property="base.techniques"/> - <makeurl file="${basedir}/techniques/technique-associations.xml" property="associations.file"/> - <mkdir dir="${basedir}/output/techniques/"/> - <local name="output.dir"/> - <makeurl file="${basedir}/output/techniques/" property="output.dir"/> - <echo message="Outputting Techniques to ${output.dir}"/> - <xslt in="${inputdir.techniques}/techniques.xml" out="output.html" style="xslt/generate-techniques.xslt" force="true"> - <classpath path="${classpath.saxon}"/> - <factory name="${xslt.factory}"/> - <param name="guidelines.version" expression="${guidelines.version}"/> - <param name="techniques.dir" expression="${base.techniques}"/> - <param name="associations.file" expression="${associations.file}"/> - <param name="output.dir" expression="${output.dir}"/> - <param name="loc.guidelines" expression="https://www.w3.org/TR/WCAG${guidelines.version}/" if="publication"/> - <param name="loc.understanding" expression="https://www.w3.org/WAI/WCAG${guidelines.version}/Understanding/" if="publication"/> - <param name="loc.techniques" expression="https://www.w3.org/WAI/WCAG${guidelines.version}/Techniques/" if="publication"/> - <param name="loc.guidelines" expression="https://w3c.github.io/wcag/guidelines/" if="editors"/> - <param name="loc.understanding" expression="https://w3c.github.io/wcag/understanding/" if="editors"/> - <param name="loc.techniques" expression="https://w3c.github.io/wcag/techniques/" if="editors"/> - </xslt> - <copy file="css/base.css" todir="output/techniques/"/> - <copy file="techniques/techniques.css" todir="output/techniques/"/> - <copy file="css/slicenav.css" todir="output/techniques/"/> - <copy todir="output/techniques/"> - <fileset dir="techniques" includes="**/img/*"/> - </copy> - </target> - - <target name="techniques-toc" depends="techniques-list" description="Generate the TOC for Techniques"> - <xslt in="${inputdir.techniques}/techniques.xml" out="techniques/toc.html" style="xslt/generate-techniques-toc.xslt" force="true"> - <classpath path="${classpath.saxon}"/> - <factory name="${xslt.factory}"/> - </xslt> - </target> - - <target name="techniques-index" depends="techniques-toc" description="Flatten the techniques index file"> - <makeurl file="${basedir}/techniques/" property="base.techniques"/> - <mkdir dir="${basedir}/output/techniques/"/> - <xslt in="${inputdir.techniques}/index.html" out="${inputdir.techniques}/index-flat.html" style="xslt/flatten-document.xslt" force="true"> - <classpath path="${classpath.saxon}"/> - <factory name="${xslt.factory}"/> - <param name="base.dir" expression="${base.techniques}"/> - </xslt> - <xslt in="${inputdir.techniques}/index-flat.html" out="${basedir}/output/techniques/index.html" style="xslt/base.xslt" force="true"> - <classpath path="${classpath.saxon}"/> - <factory name="${xslt.factory}"/> - <param name="base.dir" expression="${base.techniques}"/> - <param name="guidelines.version" expression="${guidelines.version}"/> - <param name="loc.guidelines" expression="https://www.w3.org/TR/WCAG${guidelines.version}/" if="publication"/> - <param name="loc.understanding" expression="https://www.w3.org/WAI/WCAG${guidelines.version}/Understanding/" if="publication"/> - <param name="loc.techniques" expression="https://www.w3.org/WAI/WCAG${guidelines.version}/Techniques/" if="publication"/> - <param name="loc.guidelines" expression="https://w3c.github.io/wcag/guidelines/" if="editors"/> - <param name="loc.understanding" expression="https://w3c.github.io/wcag/understanding/" if="editors"/> - <param name="loc.techniques" expression="https://w3c.github.io/wcag/techniques/" if="editors"/> - </xslt> - </target> - - <!-- Understanding --> - <target name="understanding" depends="guidelines-xml, guidelines-versions, techniques-list, understanding-index" description="Generate formatted Understanding docs"> - <makeurl file="${basedir}/understanding/" property="base.understanding"/> - <mkdir dir="${basedir}/output/understanding/"/> - <local name="output.dir"/> - <makeurl file="${basedir}/output/understanding/" property="output.dir"/> - <echo message="Outputting Understanding to ${output.dir}"/> - <xslt in="${inputdir.guidelines}/wcag.xml" out="output.html" style="xslt/generate-understanding.xslt" force="true"> + <!-- JSON --> + <target name="json" depends="init, guidelines-xml, techniques-list, techniques-association"> + <xslt in="${inputdir.guidelines}/wcag.xml" out="${inputdir.guidelines}/wcag.json" style="xslt/xml-to-json.xslt" force="true"> <classpath path="${classpath.saxon}"/> <factory name="${xslt.factory}"/> - <param name="base.dir" expression="${base.understanding}"/> - <param name="output.dir" expression="${output.dir}"/> - <param name="guidelines.version" expression="${guidelines.version}"/> - <param name="loc.guidelines" expression="https://www.w3.org/TR/WCAG${guidelines.version}/" if="publication"/> - <param name="loc.understanding" expression="https://www.w3.org/WAI/WCAG${guidelines.version}/Understanding/" if="publication"/> - <param name="loc.techniques" expression="https://www.w3.org/WAI/WCAG${guidelines.version}/Techniques/" if="publication"/> - <param name="loc.guidelines" expression="https://w3c.github.io/wcag/guidelines/" if="editors"/> - <param name="loc.understanding" expression="https://w3c.github.io/wcag/understanding/" if="editors"/> - <param name="loc.techniques" expression="https://w3c.github.io/wcag/techniques/" if="editors"/> </xslt> - <copy file="css/base.css" todir="output/understanding/"/> - <copy file="understanding/understanding.css" todir="output/understanding/"/> - <copy file="css/slicenav.css" todir="output/understanding/"/> - <copy todir="output/understanding/img/" flatten="true"> - <fileset dir="understanding"> - <patternset includes="*/img/*"/> - </fileset> - </copy> </target> - <target name="understanding-toc" depends="guidelines-xml" description="Generate the TOC for Understanding"> - <xslt in="${inputdir.guidelines}/wcag.xml" out="understanding/toc.html" style="xslt/generate-understanding-toc.xslt" force="true"> + <!-- Generic JSON --> + <target name="generic-json" depends="init, guidelines-xml"> + <xslt in="${inputdir.guidelines}/wcag.xml" out="${inputdir.guidelines}/wcag.json" style="xslt/generic-xml-to-json.xslt" force="true"> <classpath path="${classpath.saxon}"/> <factory name="${xslt.factory}"/> </xslt> </target> - <target name="understanding-index" depends="understanding-toc" description="Flatten the understanding index file"> - <makeurl file="${basedir}/understanding/" property="base.understanding"/> - <mkdir dir="${basedir}/output/understanding/"/> - <xslt in="${inputdir.understanding}/index.html" out="${basedir}/understanding/index-flat.html" style="xslt/flatten-document.xslt" force="true"> - <classpath path="${classpath.saxon}"/> - <factory name="${xslt.factory}"/> - <param name="base.dir" expression="${base.understanding}"/> - </xslt> - <xslt in="${inputdir.understanding}/index-flat.html" out="${basedir}/output/understanding/index.html" style="xslt/base.xslt" force="true"> + <!-- Redirects --> + <target name="redirects"> + <xslt in="xslt/ids.xml" out="output/understanding/.htaccess" style="xslt/ids-to-redirects.xslt" force="true"> <classpath path="${classpath.saxon}"/> <factory name="${xslt.factory}"/> - <param name="base.dir" expression="${base.understanding}"/> - <param name="guidelines.version" expression="${guidelines.version}"/> - <param name="loc.guidelines" expression="https://www.w3.org/TR/WCAG${guidelines.version}/" if="publication"/> - <param name="loc.understanding" expression="https://www.w3.org/WAI/WCAG${guidelines.version}/Understanding/" if="publication"/> - <param name="loc.techniques" expression="https://www.w3.org/WAI/WCAG${guidelines.version}/Techniques/" if="publication"/> - <param name="loc.guidelines" expression="https://w3c.github.io/wcag/guidelines/" if="editors"/> - <param name="loc.understanding" expression="https://w3c.github.io/wcag/understanding/" if="editors"/> - <param name="loc.techniques" expression="https://w3c.github.io/wcag/techniques/" if="editors"/> </xslt> </target> - <!-- Requirements --> - <target name="requirements" depends="init"> - <mkdir dir="output/requirements/${guidelines.version}"/> - <exec executable="curl"> - <arg value=""https://labs.w3.org/spec-generator/?type=respec&url=https://raw.githack.com/w3c/wcag/master/requirements/${guidelines.version}/index.html""/> - <arg value="-o"/> - <arg value="output/requirements/${guidelines.version}/index.html"/> - <arg value="-f"/> - <arg value="--retry"/> - <arg value="3"/> - </exec> - </target> - - <!-- Conformance Challenges --> - <target name="conformance-challenges" depends="init"> - <mkdir dir="output/conformance-challenges"/> - <exec executable="curl"> - <arg value=""https://labs.w3.org/spec-generator/?type=respec&url=https://raw.githack.com/w3c/wcag/master/conformance-challenges/index.html""/> - <arg value="-o"/> - <arg value="output/conformance-challenges/index.html"/> - <arg value="-f"/> - <arg value="--retry"/> - <arg value="3"/> - </exec> - </target> - - <!-- Publish --> - <target name="deploy" depends="init, understanding-toc, techniques-toc" description="Generate content ready to deploy to gh-pages"> - <property name="editors" value="true"/> - <antcall target="guidelines"/> - <antcall target="techniques"/> - <antcall target="understanding"/> - <antcall target="requirements"/> - <antcall target="conformance-challenges"/> - <copy todir="output/working-examples/"> - <fileset dir="working-examples/"/> - </copy> - </target> - - <target name="publish-w3c" depends="init, understanding-toc, techniques-toc" description="Publish resources to w3c"> - <property name="publication" value="true"/> - <antcall target="techniques"/> - <antcall target="understanding"/> - <copy todir="${w3ccvs.location}/WWW/WAI/WCAG${guidelines.version}/"> - <fileset dir="output/"/> - <globmapper from="*index.html" to="*Overview.html"/> - </copy> - <copy todir="${w3ccvs.location}/WWW/WAI/WCAG${guidelines.version}/"> - <fileset dir="output" excludes="index.html **/index.html"/> - </copy> - <copy todir="${w3ccvs.location}/WWW/WAI/WCAG${guidelines.version}/working-examples/"> - <fileset dir="working-examples/"/> - <globmapper from="*index.html" to="*Overview.html"/> - </copy> - <copy todir="${w3ccvs.location}/WWW/WAI/WCAG${guidelines.version}/working-examples/"> - <fileset dir="working-examples/" excludes="index.html **/index.html"/> - </copy> - </target> - - <!-- JSON --> - <target name="json" depends="init, guidelines-xml, techniques-list, techniques-association"> - <xslt in="${inputdir.guidelines}/wcag.xml" out="${inputdir.guidelines}/wcag.json" style="xslt/xml-to-json.xslt" force="true"> + <!-- SQL for CR test tool --> + <target name="cr-sql" depends="guidelines-xml, guidelines-versions, techniques-list, techniques-association"> + <xslt in="${inputdir.guidelines}/wcag.xml" out="${inputdir.guidelines}/test-sql.sql" style="xslt/generate-test-sql.xslt" force="true"> <classpath path="${classpath.saxon}"/> <factory name="${xslt.factory}"/> </xslt> </target> - <!-- Everything --> - <target name="all" depends="init, understanding, techniques" description="Generate entire suite"/> - <!-- === Sanity check === --> <target name="sanity" depends="init" description="Identifies inconsistencies in documents"></target> -</project> \ No newline at end of file +</project> diff --git a/conformance-challenges/index.html b/conformance-challenges/index.html index 67a2118a15..8f43476527 100644 --- a/conformance-challenges/index.html +++ b/conformance-challenges/index.html @@ -1,17 +1,30 @@ <!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> <head> - <meta charset="UTF-8" /> + <meta charset="UTF-8"/> <title>Challenges with Accessibility Guidelines Conformance and Testing, and Approaches for Mitigating Them - - - - + + + + +
    - + - -

    This document explores how the page-based conformance verification of the WCAG 2.0 and 2.1 accessibility guidelines are challenging to apply to certain websites and web applications. - This document also explores ideas on how future versions of guidelines might address these challenges. + +

    This document explores the page-based conformance verification approach used by WCAG 2.0 and 2.1 accessibility guidelines. It explains how this approach is challenging to apply to certain websites and web applications. + It also explores ideas on how future versions of guidelines might address these challenges. This document focuses primarily on challenges to large, highly complex, dynamic sites. - Other efforts in WAI are looking at different aspects of conformance for different types of sites.

    - -

    The challenges covered broadly fall into four main areas:

    + Other efforts in WAI are looking at different aspects of conformance for other types of sites.

    + +

    The challenges covered broadly fall into five main areas:

      -
    1. Numerous provisions need human involvement to test and verify conformance, which is especially challenging to scale for large websites and for dynamic websites;
    2. -
    3. Large and dynamic sites with their changing permutations may be difficult to validate;
    4. -
    5. Third parties frequently add and change content on large and dynamic sites;
    6. +
    7. Numerous provisions need human involvement to test and verify conformance, which is especially challenging to scale for large websites and for dynamic websites;
    8. +
    9. Large and dynamic sites with their changing permutations may be difficult to validate;
    10. +
    11. Third parties frequently add and change content on large and dynamic sites;
    12. Applying a web-based, and page-based conformance model can be challenging to do for non-web Information and Communications Technologies (ICT).
    13. +
    14. The centrality of Accessibility Supported in the many provisions tied to use with assistive technologies and platform accessibility features, combined with the lack of definition of what constitutes Accessibility Supported, further exacerbates the need for expert human judgement (#1 above), as well as potential different and non-overlapping sets of these features used when including 3rd party content (#3 above).
    -

    The purpose of this document is to help understand those challenges more holistically, and explore approaches to mitigating those challenges so that we can address the - challenges more fully in future accessibility guidelines such as WCAG 3.0 (now in early development) where the W3C Working Group Charter expressly anticipates a new conformance model.

    +

    The purpose of this document is to help understand those challenges more holistically, and explore approaches for mitigating them so that we can address such + challenges more fully in future accessibility guidelines including the forthcoming W3C Accessibility Guidelines (WCAG 3.0) (now in early development) where the W3C Working Group Charter expressly anticipates a new conformance model.

    -

    To comment, file an issue in the W3C WCAG GitHub repository. Please indicate your issue is for this document by using the word Challenges: as the first word of your issue's title. Although the proposed Success Criteria in this document reference issues tracking discussion, the Working Group requests that public comments be filed as new issues, one issue per discrete comment. It is free to create a GitHub account to file issues. If filing issues in GitHub is not feasible, send email to public-agwg-comments@w3.org (comment archive).

    +

    To comment, file an issue in the W3C WCAG GitHub repository. Please indicate your issue is for this document by using the word Challenges: as the first word of your issue's title. Although the proposed Success Criteria in this document reference issues tracking discussion, the Working Group requests that public comments be filed as new issues, one issue per discrete comment. It is free to create a GitHub account to file issues. If filing issues in GitHub is not feasible, send email to public-agwg-comments@w3.org (comment archive).

    Introduction

    @@ -45,9 +59,9 @@

    Introduction

    Problem Statement

    Assessing the accessibility of a website is of critical importance. -Website authors want to have website accessibility assessments so they can +Website authors want to have website accessibility assessments in order to understand the places where visitors with disabilities may be unable to use -that site so that they can address them as much as possible. External +a site in order to alleviate those difficulties. External parties who have an interest in the accessibility of a website likewise want to have website assessments so they can understand whether the site meets their accessibility fitness criteria. To aid in this assessment, the @@ -56,16 +70,15 @@

    Problem Statement

    (W3C) developed the Web Content Accessibility Guidelines (WCAG), containing both a rich set of success criteria to meet the needs of people with -disabilities, as well as conformance requirements for same. Assessing +disabilities and conformance requirements for the same. Assessing conformance of a website to all of the success criteria is how accessibility assessments have been done to date, either through assessing every individual page, or through a page sampling approach.

    -

    While the challenges discussed in this document apply to websites and web applications broadly, this early version of the document focuses particularly on situations involving large, dynamic, and complex websites. -There are valid reasons WCAG 2 and related resources have the conformance -model they do; failures to conform to the current model are likely to present a barrier for people with disabilities. +

    While the challenges discussed in this document apply to websites and web applications broadly, this document focuses particularly on situations involving large, dynamic, and complex websites. +There are important reasons WCAG 2 and related resources have the guidelines and success criteria they do. Failure to conform to these is likely to erect a barrier for people with disabilities. The issues raised in this document do not mean sites should -not strive to conform to WCAG 2. It is also vital to consider aspects beyond the conformance model that lead to accessibility issues found during late stage testing, such as the lack of accessibility prioritization, training, and integration throughout the design, development, and maintenance processes. A new version of accessibility guidelines, W3C Accessibility Guidelines 3.0 (WCAG 3.0), rethinks all aspects of the accessibility guidance and is expressly chartered to develop a new conformance model that will help to address these challenges. +not strive to conform to WCAG 2. But it is also vital to consider aspects that commonly lead to accessibility challenges found during late stage testing, such as a lack of accessibility prioritization, training, and integration throughout the design, development, and maintenance process. A new version of accessibility guidelines, W3C Accessibility Guidelines 3.0 (WCAG 3.0), rethinks all aspects of accessibility guidance. It is also expressly chartered to develop a new conformance model which should help address the challenges explored in this document.

    Large websites are often highly complex, with substantial dynamic content, @@ -85,11 +98,11 @@

    Problem Statement

    Assessing conformance of such large, highly complex, dynamic sites to the Web Content Accessibility Guidelines (WCAG) 2.0 [[wcag20]] or 2.1 [[wcag21]] has proved difficult. The Web Content Accessibility Guidelines 2.0 include a set of normative requirements in order for a web page to conform to WCAG 2.0, including that conformance is for full Web page(s) only, and cannot be achieved if part of a Web page is excluded, along with a Note that states If a page cannot conform (for example, a conformance test page or an example page), it cannot be included in the scope of conformance or in a conformance claim. The conformance requirements also state what is allowed in any optional Conformance Claims, starting with: 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. For the purposes of this document, we use the term WCAG 2.x conformance model to refer to the normative text in the Conformance section of WCAG 2.0 and WCAG 2.1.

    -

    This WCAG 2.x conformance model contains a mitigation related to partial conformance for 3rd party content (see Sec. 3.1: Treatment of 3rd party content and Statements of Partial Conformance below). Further in recognition of these challenges, the W3C Note Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0 [[wcag-em]] was published in 2014 to provide guidance on evaluating how well websites conform to the Web Content Accessibility Guidelines. This W3C document describes a procedure to evaluate websites and includes considerations to guide evaluators and to promote good practice, which can help organizations to make a conformance claim, while acknowledging that there may be errors on pages not in the sample set or that were not picked up by automated evaluation tools on pages that were not in the human evaluation sample. While WCAG-EM provides a practical method for claiming conformance for a website, it doesn't fully address the challenges in making every part of every page in a large, dynamic website conform to every success criterion. +

    This WCAG 2.x conformance model contains a mitigation related to partial conformance for 3rd party content (see Sec. 3.1: Treatment of 3rd party content and Statements of Partial Conformance below). Further in recognition of these challenges, the W3C Note Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0 [[wcag-em]] was published in 2014 to provide guidance on evaluating how well websites conform to the Web Content Accessibility Guidelines. This W3C document describes a procedure to evaluate websites and includes considerations to guide evaluators and to promote good practice, which can help organizations to make a conformance claim, while acknowledging that there may be errors on pages not in the sample set or that were not picked up by automated evaluation tools on pages that were not in the human evaluation sample. While WCAG-EM provides a practical method for claiming conformance for a website, it doesn't fully address the challenges in making every part of every page in a large, dynamic website conform to every success criterion.

    -Also, the Authoring Tool Accessibility Guidelines 2.0 (ATAG) [[atag20]] provides guidelines for designing web content authoring tools that are both more accessible to authors with disabilities as well as is designed to enable, support, and promote the production of more accessible web content by all authors. Leveraging ATAG-conformant authoring tools can significantly help with preventing accessibility issues from occurring on a website. A number of the challenges with conformance could be addressed with authoring tools, and in future versions of this document we hope to describe those in more detail. +Also, the Authoring Tool Accessibility Guidelines 2.0 (ATAG) [[atag20]] provides guidelines for designing web content authoring tools that are both more accessible to authors with disabilities as well as is designed to enable, support, and promote the production of more accessible web content by all authors. Leveraging ATAG-conformant authoring tools can significantly help with preventing accessibility issues from occurring on a website. Moreover, several challenges with conformance could better be addressed by authoring tools or user agents, both of which are scoped for nonnormative WCAG 3.0 guidance.

    @@ -105,7 +118,7 @@

    Problem Statement

    time it takes for a site visitor to conduct a task, as alternative measures that could complement conformance-based metrics. Unfortunately, this research report was last updated in May 2014, and has not progressed to being a - published W3C Note. The Research and Development Working Group was not renewed by W3C Membership in 2015, though a Research Questions Task Force, under the Accessible Platform Architecture (APA) Working Group, is able to look at similar types of issues. + published W3C Note. The Research and Development Working Group was not renewed by W3C Membership in 2015, though a Research Questions Task Force, under the Accessible Platform Architecture (APA) Working Group, is able to look at similar issues.

    Finally, the Problem Statement

    -
    -

    Approaches for Mitigating Challenges with Accessibility Guidelines Conformance and Testing

    +
    +

    Silver Research Findings

    + +

    Now known as W3C Accessibility Guidelines (WCAG 3.0), this next iteration of W3C + accessibility guidance was conceived and designed to be research-based, coming out of the Silver Research effort. A summary of the conformance related findings from Silver research contributed to this document, and is provided in its entirety as Appendix C below. Findings that expand on the four main challenges enumerated in this document are integrated throughout. Additional enumerated challenges identified by Silver research are also articulated as independent, specific challenges.

    + + + +

    Working +over many years, the Silver Task Force of the Accessibility Guidelines Working +Group (AGWG) and the Silver Community Group collaborated with researchers on +questions that the Silver Groups identified. This research was used to develop +11 problem statements that needed to be solved for Silver. The conformance-related Silver generated Problem Statements are included as originally submitted for this document below in Appendix C.

    + + +
    + +
    +

    Mitigation Approaches

    In addition to describing in detail the challenges of assessing conformance, this document also explores some approaches to mitigating those challenges. Each of the main challenges sections below describes one or more significant mitigation approaches.

    +

    While some approaches may be more applicable to a particular website design than others; and not all approaches may be appropriate or practical for a particular website, it is likely that many websites can -utilize at least some of these approaches. These approaches are proposed as ways through which these conformance challenges -might be able to be mitigated, while maximizing the likelihood that all website visitors will be able to use the site effectively. +utilize at least some of these approaches. They are proposed as ways by which these conformance challenges +may be mitigated, while maximizing the likelihood that all website visitors will be able to use the site effectively. Though the challenges described in this document illustrate that it is difficult for large, complex, and/or dynamic websites to ensure a site has no defects, -mitigation strategies may be able to create a website that people with disabilities can use even though some conformance issues exist. +mitigation strategies may be able to help create a website that people with disabilities can use even though some conformance issues may persist.

    -
    +

    Goals

    This document has two key goals:

    -
      -
    1. To develop, catalog, and characterize the challenges with accessibility guidelines conformance, and conformance verification that have arisen both through the multi-year research process preceding work on the next major revision of W3C accessibility guidelines to be known as the W3C Accessibility Guidelines (WCAG 3.0) which have been in development under the name Silver, as well as through active discussion of conformance taking place in the Silver Task force subgroup of the W3C Accessibility Guidelines Working Group (AGWG).
    2. -
    3. To develop, catalog, and characterize mitigation approaches to these challenges, so that websites can be as accessible as possible, and are better able assess how well their sites are accessible to visitors with disabilities.
    4. -
    +
      +
    1. To develop, catalog, and characterize the challenges with accessibility guidelines conformance, and conformance verification that have arisen both through the multi-year research process preceding work on W3C Accessibility Guidelines (WCAG 3.0) which have been in development under the name Silver, as well as through active discussion in the Silver Conformance Options Subgroup.
    2. +
    3. To develop, catalog, and characterize mitigation approaches to these challenges, so that websites can be as accessible as possible and better assessed for accessibility to visitors with disabilities.
    4. +

    A better understanding of the situations in which the WCAG 2.x conformance model may be difficult to apply could lead to more effective conformance models and testing approaches in the future.

    It is important to recognize that success criteria in WCAG 2.x are quite distinct from the conformance model. These criteria describe approaches to content accessibility that are thoughtfully designed to enable people with a broad range of disabilities to effectively consume and interact with web content. Challenges with the conformance model do not in any way invalidate the criteria. For example, while requiring human judgment to validate a page limits testing to sampling of templates, flows, and top tasks, etc. (see Challenge #1 below), without that human judgement it may not be possible to deliver a page that makes sense to someone with a disability. Similarly, while it may not be possible to know that all third party content is fully accessible (see Challenge #3 below), without review of that content by someone sufficiently versed in accessibility it may not be possible to be sure that pages containing third party content fully conform to WCAG 2.x. Human judgement is a core part of much of WCAG 2.x for good reasons, and the challenges that arise from it are important to successfully grapple with.

    -
    -
    +
    +

    Additional Background

    -

    One of the reasons for publishing this draft document is to seek additional contributions from the wider web community:

    -
      -
    • Any additional challenges, or further illustration of challenges in the existing identified areas below;
    • -
    • Contributions to the mitigation approaches, and questions or concerns about the mitigation approaches;
    • -
    -

    We seek to gain a thorough understanding of the challenges faced by large, complex, and dynamic websites who are attempting to provide accessible services to their web site users. It is expected that a more thorough understanding of these challenges can lead to either a new conformance model, or an alternative model that is more appropriate for large, complex, and/or dynamic websites (in WCAG 3.0).

    - -

    This document also includes previously published research from the Silver Task Force and Community Group that was related to Challenges with Accessibility Guidelines Conformance and Testing. There is some - overlap between the challenges captured in this published research, and the challenges enumerated in the first 4 sections of this document. The research findings will be folded into the other sections as appropriate in - future versions of this document.

    -

    Present in this current draft of this document is an initial discussion of approaches to mitigate the impact of the challenges cited. Previous drafts emphasized collecting a comprehensive inventory of challenges, we believe our collection is now sufficiently mature to begin enumerating and considering the various mitigating approaches that have been suggested by various stakeholders. We are publishing this document now to seek wide review to further catalogue and characterize the challenges and mitigation approaches, so that this work can become input into the next major revision of W3C accessibility guidelines (now chartered by W3C for eventual release as WCAG 3.0). +

    This document is published to seek additional contributions from the wider web community on:

    +
      +
    • Any additional challenges, or further illustration of challenges in the existing identified areas below;
    • +
    • Contributions to the mitigation approaches, and questions or concerns about the mitigation approaches;
    • +
    +

    We seek to gain a thorough understanding of the challenges faced by large, complex, and dynamic websites who are attempting to provide accessible services to their web site users. It is expected that a more thorough understanding of these challenges can lead to either a new conformance model, or an alternative model that is more appropriate for large, complex, and/or dynamic websites (in WCAG 3.0).

    + +

    This document also includes previously published research from the Silver Task Force and Community Group that is related to Challenges with Accessibility Guidelines Conformance and Testing. There is some overlap between the challenges captured in this published research and the challenges enumerated in the first 4 sections of this document. The research findings have been folded into other sections of this document as appropriate.

    + +

    Also present in this document is an introductory discussion of approaches to mitigate the impact of the challenges cited that have been suggested by various stakeholders. We are publishing this updated draft now to continue seeking wide review to further catalogue and characterize the challenges and mitigation approaches, so that this work can become input into W3C accessibility guidelines (WCAG 3.0).

    -
    -

    Key Terms

    -

    The following terms are used in this document:

    -
    -
    large websites
    -
    Websites with thousands of pages, let alone hundreds of thousands or more.
    -
    dynamic websites
    -
    Websites that are constantly being updated with new content, possibly hundreds of times an hour, or even thousands of times per second.
    -
    complex websites
    -
    Web apps that are similar in scope to complex desktop applications (e.g. a full-fledged spreadsheet or word processor web application). Or websites with a large portion of pages that are generated upon demand, pulling from dozens or more different content sources.
    -
    -
    +
    +

    Key Terms

    +

    The following terms are used in this document:

    +
    +
    large websites
    +
    Websites with thousands of pages, let alone hundreds of thousands or more.
    +
    dynamic websites
    +
    Websites that are constantly being updated with new content, possibly hundreds of times an hour, or even thousands of times per second.
    +
    complex websites
    +
    Web apps that are similar in scope to complex desktop applications (e.g. a full-fledged spreadsheet or word processor web application). Or websites with a large portion of pages that are generated upon demand, pulling from dozens (or more) different content sources.
    +
    +

    Challenge #1: Scaling Conformance Verification

    A challenge common to many success criteria is the inability for automatic testing to fully validate conformance and the subsequent time, cost, and expertise needed to perform the necessary manual test to cover the full range of the requirements. HTML markup can be automatically validated to confirm that it is used according to specification, but a human is required to verify whether the HTML elements used correctly reflect the meaning of the content. For example, text on a web page marked as contained in a paragraph element may not trigger any failure in an automated test, nor would an image with alternative text equal to red, white, and blue bird, but a human will identify that the text needs to be enclosed in a heading element to reflect the actual use on the page, and also that the proper alternative text for the image is American Airlines logo. Many existing accessibility success criteria require an informed human evaluation to ensure that the human end-users benefit from conformance. The same can be said of very large web-based applications that are developed in an agile manner with updates delivered in rapid succession, often on an hourly basis.

    We can think of this as the distinction between quantitative and qualitative analysis. We know how to automatically test for and count the occurrences of relevant markup. However, we do not yet know how to automatically verify the quality of what that markup conveys to the user. In the case of adjudging appropriate quality, informed human review is still required.

    -

    There are a number of approaches for mitigating scaling + +

    Appendix A describes challenges with applying the WCAG 2.x conformance model to specific Guidelines and Success Criteria, primarily based on required human involvement in evaluation of conformance to them. The list is not exhaustive, but it covers the preponderance of known challenges with all A and AA Success Criteria.

    +
    +

    Silver Research Findings

    +

    Silver research identified two further challenges related to scaling conformance verification:

    + +
      +
    1. In Constraints on What is Strictly Testable Silver finds that The requirement for valid and reliable testability for WCAG success criteria presents a structural barrier to including the needs of people with disabilities whose needs are not strictly testable. User needs such as thos articulated by the W3C's Cognitive and Learning Disabilities (COGA) Task Force in their extensive W3C Note publication Making content usable for people with cognitive and learning disabilities [[coga-usable]] only expand and exacerbate the need for expert human testing. As silver also notes: The entire principle of understandable is critical for people with cognitive disabilities, yet success criteria intended to support the principle are not easy to test for or clear on how to measure.
    2. +
    3. Silver also finds that Human evaluation does not yield consistent conclusions: Regardless of proficiency, there is a significant gap in how any two human auditors will identify a success or fail of criteria. … Ultimately, there is variance between: any two auditors; … Because there's so much room for human error, an individual may believe they've met a specific conformance model when, in reality, that's not the case. … There isn't a standardized approach to how the conformance model applies to success criteria at the organizational level and in specific test case scenarios.
    4. +
    +
    + +
    +

    Mitigations

    +

    There are a number of approaches for mitigating scaling challenges. For example, if pages can be built using a small number of page templates that are fully vetted for conformance to criteria relating to structure, heading use, and layout, then pages generated with those templates @@ -213,15 +263,19 @@

    Challenge #1: Scaling Conformance Verification

    some situations is to encode website content in a higher-level abstraction from HTML (e.g. a wiki-based website, when content authors can specify that a particular piece of text is to be emphasized strongly [which would be rendered -within a block], but they cannot specify that a -particular piece of text is to be made boldface [so that is never part of the website]). While none of these approaches can mitigate every challenge in conformance and testing with every success criterion, they are powerful approaches where applicable to help minimize accessibility issues in websites. +within a <strong> </strong> block], but they cannot specify that a +particular piece of text is to be made boldface [so that <b> </b> markup is never part of the website]). While none of these approaches can mitigate every challenge in conformance and testing with every success criterion, they are powerful approaches where applicable to help minimize accessibility issues in websites.

    -

    Appendix A describes challenges with applying the WCAG 2.x conformance model to specific Guidelines and Success Criteria, primarily based on required human involvement in evaluation of conformance to them. In this draft, the list is not exhaustive, but we intend it to cover all known challenges with all A and AA Success Criteria, by the time this Note is completed.

    +
    +

    Challenge #2: Large, complex, and dynamic websites may have too many changing permutations to validate effectively

    -

    Large websites often have complex content publishing pipelines, which may render content dynamically depending upon a large number of variables (such as what is known about the logged in user and her content preferences, the geographical location that the user is visiting the site from, and the capabilities of the web rendering agent being used). It is difficult, and may not be feasible, to validate every possible publishing permutation with a page-level test, each of which can have an impact on whether that particular rendering of the content at that particular moment conforms.

    -

    Approaches used in quality assurance and quality engineering of software code +

    Large websites often have complex content publishing pipelines, which may render content dynamically depending upon a large number of variables (such as what is known about logged in users and their content preferences, the geographical location that the users are visiting the site from, and the capabilities of the web rendering agent being used). It is difficult, and may not be feasible, to validate every possible publishing permutation with a page-level test, each of which can have an impact on whether that particular rendering of the content at that particular moment conforms.

    + +
    +

    Mitigations

    +

    Approaches used in quality assurance and quality engineering of software code can be used with software that generates dynamic web content. One of these is Unit Testing (or Component Testing), where each individual step in the content publishing pipeline is tested independent of the other, with a broad range of @@ -233,10 +287,11 @@

    Challenge #2: Large, complex, and dynamic websites may have too many changin there is no guarantee of finding all potential bugs, or assuring a software system is bug-free.

    +

    Challenge #3: 3rd party content

    -

    Very large, highly dynamic web sites generally aggregate content provided by multiple entities. Many of these are third parties with the ability to add content directly to the website — including potentially every website visitor. The relationship to the 3rd party can be that of a user, a customer, or a professional provider of content such as an advertiser. While the website can provide guidance on how to post content so that it meets accessibility guidance, it is ultimately up to those third parties to understand and correctly implement that guidance. Constraints on page templates and editing facilities can greatly help minimize accessibility issues but, even with automated checks prior to accepting the post, some Success Criteria require human assessment.

    +

    Very large, highly dynamic web sites generally aggregate content provided by multiple entities. Many of these are third parties with the ability to add content directly to the website—including potentially every website visitor. The relationship to the 3rd party can be that of a user, a customer, or a professional provider of content such as an advertiser. While the website can provide guidance on how to post content so that it meets accessibility guidance, it is ultimately up to those third parties to understand and correctly implement that guidance. Constraints on page templates and editing facilities can greatly help minimize accessibility issues but, even with automated checks prior to accepting the post, some Success Criteria require human assessment.

    Copyright, commercial agreements, and similar constraints that restrict the ability to modify or impose requirements on third party content can also make full conformance claims infeasible.

    Treatment of 3rd party content and Statements of Partial Conformance

    @@ -245,34 +300,42 @@

    Treatment of 3rd party content and Statements of Partial Conformance

    Partial Conformance. [[wcag21]] It provides two options for such content — that pages with 3rd party content may:

      -
    1. Make a determination of conformance based on best knowledge, for example -by monitoring and repairing non-conforming content within 2 business days; +
    2. Make a determination of conformance based on best knowledge, for example by monitoring and repairing non-conforming content within 2 business days; or
    3. -
    4. Make a statement of partial conformance if the page could conform if the -3rd party content were removed.
    5. +
    6. Make a statement of partial conformance if the page could conform if the 3rd party content were removed.

    The provision of monitoring and required repair within a 2 business day -window doesn't address the underlying challenge of pages with (3rd party) +window doesn't address the underlying challenge of pages with (3rd party) content that may be updating tens or hundreds of times within that 2 day window. For large websites with hundreds of thousands of pages or more with a significant amount of 3rd party content, the necessity for human involvement in the evaluation of 3rd -party content doesn't scale.

    -

    A statement of partial conformance doesn't address the underlying challenge of improving the usability of 3rd party content. While it might allow a web page/website visitor to be forewarned in advance that they should +party content doesn't scale.

    +

    A statement of partial conformance doesn't address the underlying challenge of improving the usability of 3rd party content. While it might allow a web page/website visitor to be forewarned in advance that they should anticipate encountering inaccessible content, it does little to practically enable large sites to address such concerns.

    +
    + +
    +

    Silver Research Findings

    -

    There are several approaches to the challenge of 3rd +

    Silver cited Third parties documents, applications and services among its list of conformance related problem statements. See the reference in Appendix C below. +

    + +
    +
    +

    Mitigations

    +

    There are several approaches to the challenge of 3rd party content accessibility. Where that content is provided as part of a commercial contract, the terms of the contract may include requirements around accessibility. Where the content comes from potentially any website visitor or -user, those visitors can be constrained in the types of contributions they can +user, those visitors could be constrained in the types of contributions they can make (e.g. prevented from using non-semantic text attributes like boldface), or prompted to add accessibility metadata (e.g. so that images are uploaded along with ALT text), or reminded about good accessibility practices (e.g. told not to refer to sensory characteristics in their text). Such approaches may add -substantial friction, especially to individual website visitors and users, to -the point that they may be disinclined to make contributions. Further, they -aren't a guarantee of perfection in those contributions (Is the ALT text +substantial friction, especially to individual website visitors and users, however, to +the point that they might be dissuaded from making contributions at all. Further, they +aren't a guarantee of perfection in those contributions (Is the ALT text thoughtfully authored, or just filler text to make the upload happen? Did the text truly avoid reference to sensory characteristics?). Nonetheless, these are some approaches to consider to help minimize the amount of 3rd party @@ -281,12 +344,28 @@

    Treatment of 3rd party content and Statements of Partial Conformance

    help make accessibility practices more ubiquitous.

    -
    +

    Challenge #4: Non-Web Information and Communications Technologies

    The core principles, and many of the guidelines, contained in WCAG 2.x, are broadly applicable outside of the web context. For example, no matter the technology, information presented to humans needs to be perceivable by them in order for them to access and use it. At the same time, some of the specific guidelines and especially some of the individual success criteria of WCAG 2.x are specifically scoped to web content and web technologies, and may be difficult to apply to non-web information and communications technologies (as set forth in the W3C Note Guidance on Applying WCAG to non-web Information and Communication Technologies (WCAG2ICT)). [[wcag2ict]] Furthermore, the state of programmatic test tools for assessing whether non-web information and communications technologies meet various WCAG 2.x success criteria varies widely with the type of non-web document, the operating system, and the user interface toolkits used to create the non-web software. Therefore, it is potentially the case that for some documents or software, it will not be possible to use any programmatic accessibility evaluation tools for some success criterion — conformance to each and every success criterion will need human expertise and judgment.

    -

    There are various approaches to the challenges of accessibility guidelines + +

    Appendix B contains Detailed Challenges with Conformance Verification and Testing for non-web ICT. It covers 12 success criteria out of the 38 A and AA criteria in WCAG 2.0 which can be applied to non-web ICT after replacing specific terms or phrases.

    + +
    +

    Silver Research Findings

    + +

    Silver research identified the need to expand the scope beyond web to include apps, + documents, authoring, user agents, wearables, kiosks, IoT, VR, etc. + and be inclusive of more disabilities. (UX Professionals Use of + WCAG: Analysis) * Accessibility Supported allows inadequate + assistive technologies to be claimed for conformance, particularly + in non-native English speaking countries.

    +
    + +
    +

    Mitigations

    +

    There are various approaches to the challenges of accessibility guidelines conformance and testing of non-web information and communications technologies, depending upon the nature of non-web document technology or non-web software in question. For example, there is a rich set of techniques @@ -295,7 +374,7 @@

    Challenge #4: Non-Web Information and Communications Technologies

    mitigate accessibility failings found by the tool as part of Adobe Acrobat. Both Microsoft Word and OpenOffice include accessibility test and validation tools, and both are capable of saving exporting their content into accessible -PDF documents. Operating systems like MacOS, iOS, Windows, Android, and Fire +file formats. Operating systems like MacOS, iOS, Windows, Android, and Fire OS all have rich accessibility frameworks which can be used to make accessible software applications, which are accessible through the use of built-in assistive technologies like screen readers and screen magnifiers, as well as @@ -303,134 +382,122 @@

    Challenge #4: Non-Web Information and Communications Technologies

    of accessibility test tools and support systems to help software developers make accessible software applications for these operating systems. While none of these tools and frameworks can find all accessibility issues or otherwise -guarantee a document or application will be free of all accessibility defects +guarantee +e a document or application will be free of all accessibility defects – whether those are tied to a specific WCAG success criterion or not – they are nonetheless important tools that can lead to highly accessible documents and software.

    -

    Appendix B contains Detailed Challenges with Conformance Verification and Testing for non-web ICT. It covers 12 success criteria out of the 38 A and AA criteria in WCAG 2.0 which can be applied to non-web ICT after replacing specific terms or phrases. In - future versions of the document we plan to address success criteria introduced in WCAG 2.1 that may pose specific challenges for conformance verification and testing in the non-web ICT context.

    -
    -
    -

    Challenges of Conformance as identified from Silver Research

    -

    Now known as W3C Accessibility Guidelines (WCAG 3.0), this iteration of W3C accessibility guidance was conceived and designed to be research-based. Working over many years, the Silver Task Force of the Accessibility Guidelines Working Group (AGWG) and the Silver Community Group collaborated with researchers on questions that the Silver Groups identified. This research was used to develop 11 problem statements that needed to be solved for Silver. The detailed problem statements include the specific problem, the result of the problem, the situation and priority, and the opportunity presented by the problem. The problem statements were organized into three main areas: Usability, Conformance, and Maintenance. The section following is taken from the Conformance sections of the Silver Design Sprint Final Report and the Silver Problem Statements. Details of the research questions and the individual reports are in Research Archive of Silver wiki.

    -

    The following items are shown as they were originally presented by the Silver task force, in future versions of this document they will be integrated into the challenges.

    -
    -

    Silver Research Problem Statements

    -

    Originally published as the Silver Design Sprint Final Report (2018). These problem statements were presented to the Silver Design Sprint participants.

    -
      -
    • Constraints on What is Strictly Testable provides an obstacle to including guidance that meets the needs of people with disabilities but is not conducive to a pass/fail test.
    • -
    • Human Testable (related to Ambiguity) also relates to differences in knowledge and priorities of different testers achieve different results.
    • -
    • Accessibility Supported is a conformance requirement of WCAG 2 that is poorly understood and incompletely implemented.
    • -
    • Evolving Technology of the rapidly changing web must constantly be evaluated against the capabilities of assistive technology and evolving assistive technology must be evaluated against the backward compatibility of existing web sites.
    • -
    -
    -
    -

    Details of Problem Statements

    -

    Originally published as Silver Problem Statements, this was a detailed analysis of the research results behind the above list.

    -
    -

    Definition of Conformance

    -

    Conformance to a standard means that you meet or satisfy the requirements of the standard. In WCAG 2.0 the requirements are the Success Criteria. To conform to WCAG 2.0, you need to satisfy the Success Criteria, that is, there is no content which violates the Success Criteria.

    -

    WCAG 2.0 Conformance Requirements:

    -
      -
    1. Conformance Level (A to AAA)
    2. -
    3. Conformance Scope (For full web pages only, not partial)
    4. -
    5. Complete Process
    6. -
    7. Only "Accessibility-supported" ways of using technologies
    8. -
    9. Non-Interference: Technologies that are not accessibility supported can be used, as long as all the information is also available using technologies that are accessibility supported and as long as the non-accessibility-supported material does not interfere.
    10. -
    -
    -
    -

    Themes from Research

    -
      -
    • No monitoring process to test the accuracy of WCAG compliance claims (Keith et al., 2012)
    • -
    • Difficulties for conformance (Keith et al., 2012) -
        -
      • Third parties documents, applications and services
      • -
      • Know-how of IT personnel
      • -
      • Tension between accessibility and design
      • -
      -
    • -
    • Specific success criteria for failure - 1.1.1 , 2.2., 4.1.2 (Keith et al., 2012)
    • -
    • Reliably Human Testable, not reliably testable (Brajnick et al., 2012) average agreement was at the 70-75% mark, while the error rate was around 29%. -
        -
      • Expertise appears to improve (by 19%) the ability to avoid false positives. Finally, pooling the results of two independent experienced evaluators would be the best option, capturing at most 76% of the true problems and producing only 24% of false positives. Any other independent combination of audits would achieve worse results.
      • -
      • This means that an 80% target for agreement, when audits are conducted without communication between evaluators, is not attainable, even with experienced evaluators.
      • -
      -
    • -
    • Challenges and Recommendations (Alonso et al., 2010) -
        -
      • accessibility supported ways of using technologies
      • -
      • Testability of Success Criteria
      • -
      • Openness of Techniques and Failures
      • -
      • Aggregation of Partial Results
      • -
      -
    • -
    • Silver needs to expand the scope beyond web to include apps, documents, authoring, user agents, wearables, kiosks, IoT, VR, etc. and be inclusive of more disabilities. (UX Professionals Use of WCAG: Analysis)
    • -
    • Accessibility Supported allows inadequate assistive technologies to be claimed for conformance, particularly in non-native English speaking countries. (Interviews on Conformance)
    • -
    -
    -
    -

    Constraints on What is Strictly Testable

    -

    Specific problem: Certain success criteria are quite clear and measurable, like color contrast. Others, far less so. The entire principle of understandable is critical for people with cognitive disabilities, yet success criteria intended to support the principle are not easy to test for or clear on how to measure. As a simple example, there is no clear, recent or consistent definition – within any locale or language – on what lower secondary education level means in regard to web content. Language and text content is also not the only challenge among those with cognitive and learning disabilities. Compounding this, most of the existing criteria in support of understanding are designated as AAA, which relatively few organizations attempt to conform with.

    -

    Result of problem: The requirement for valid and reliable testability for WCAG success criteria presents a structural barrier to including the needs of people with disabilities whose needs are not strictly testable. Guidance that WCAG working group members would like to include cannot be included. The needs of people with disabilities – especially intellectual and cognitive disabilities – are not being met.

    -

    Situation and Priority: Of the 70 new success criteria proposed by the Cognitive Accessibility Task Force to support the needs of people with cognitive and intellectual disabilities, only four to six (depending on interpretation) were added to WCAG 2.1 and only one is in level AA. The remainder are in level AAA, which is rarely implemented. This means user needs are not met.

    -

    Opportunity: Multiple research projects and audience feedback have concluded that simpler language is desired and needed for audiences of the guidelines. Clear but flexible criteria with considerations for a wider spectrum of disabilities helps ensure more needs are met.

    -
    -
    -

    Human Testable

    -

    Specific problem: Regardless of proficiency, there is a significant gap in how any two human auditors will identify a success or fail of criteria. Various audiences have competing priorities when assessing the success criteria of any given digital property. Knowledge varies for accessibility standards and how people with disabilities use assistive technology tools. Ultimately, there is variance between: any two auditors; any two authors of test cases; and human bias. Some needs of people of disabilities are difficult to measure in a quantifiable way.

    -

    Result of problem: Success criteria are measured by different standards and by people who often make subjective observations. Because there's so much room for human error, an individual may believe they've met a specific conformance model when, in reality, that’s not the case. The ultimate impact is on an end user with a disability who cannot complete a given task, because the success criteria wasn’t properly identified, tested and understood.

    -

    Situation and Priority: There isn't a standardized approach to how the conformance model applies to success criteria at the organizational level and in specific test case scenarios.

    -

    Opportunity: There's an opportunity to improve the success criteria such that human auditors and testers find the success criteria more understandable. Educating business leaders on how the varying levels of conformance apply to their organization may be useful as well. We can educate about the ways that people with disabilities use their assistive technology.

    -
    -
    -

    Accessibility Supported

    -

    Specific problem: Accessibility supported was implemented in a way that did not facilitate consistent adoption by developers and testers. It also requires a harmonious relationship and persistent interoperability between content technologies and requesting technologies that must be continuously evaluated as either is updated. Further, the WG defers the judgment of how much, how many, or which AT must support a technology to the community. It is poorly understood, even by experts.

    -

    Result of problem: Among the results are: difficulty understanding what qualifies as a content technology or an assistive technology; difficulty quantifying assistive technologies or features of user agents; claiming conformance with inadequate assistive technology; and difficulty claiming conformance.

    -

    Situation and Priority: Any claim or assertion that a web page conforms to the guidelines may require an explicit statement defining which assistive technology and user agent(s) the contained technologies rely upon, and presumably inclusive of specific versions and or release dates of each. One could infer then that a conformance claim is dependent upon a software compatibility claim naming browsers and assistive technology and their respective versions. This would create a burden to author and govern such claims. Additionally, no one can predict and anticipate new technologies and their rates of adoption by people with disabilities.

    -

    Opportunity: As the technologies in this equation evolve, the interoperability may be affected by any number of factors outside of the control of the author and publisher of a web page. Either accessibility supported should not be a - component of conformance requirements, or it should clearly, concisely, and explicitly define and quantify the technologies or classes of technologies, AND set any resulting update or expiry criteria for governance.

    -
    -
    -

    Evolving Technology

    -

    Specific problem: Evolving Technology: As content technology evolves, it must be re-evaluated against assistive technology for compatibility. Likewise, as assistive technology evolves or emerges, it must be evaluated against the backward compatibility of various content technology.

    -

    Result of problem: There is no versioning consideration for updates to user agents and assistive technology. Strict conformance then typically has an expiry.

    -

    Situation and Priority: There is no clear and universal understanding of the conformance model or its longevity. Some will infer that there is always a conformance debt when any technology changes.

    -

    Opportunity: Consider conformance statements to include an explicit qualifier of time of release or versions of technology. OR consider a more general approach that is not explicit and is flexible to the differences in technologies as they evolve, identifying the feature of the assistive tech rather than the version of the assistive tech. OR consider a model that quantifies conformance as a degree of criteria met.

    -
    -
    +
    + +
    +

    Challenge #5: Accessibility Supported

    + +

    The Conformance + section of WCAG 2.1 states that only + accessibility-supported ways of using technologies can be + relied upon for conformance. However, the definition of + Accessibility Supported, together with the relevant section of Understanding + WCAG leaves this conformance requirement under-specified by providing insufficient guidance on how it is to be realized.

    + +

    The + + first Note under the definition of Accessibility Supported states that: The WCAG 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 to be classified as accessibility supported. +This is further expanded upon in the section + + Level of Assistive Technology Support Needed for Accessibility Support: +This topic raises the question of how many +or which assistive technologies must support a Web technology in order +for that Web technology to be considered accessibility supported. The +WCAG Working group and the W3C do not specify which or how many +assistive technologies must support a Web technology in order for it to +be classified as accessibility supported. This is a complex topic and +one that varies both by environment and by language.

    + +

    The centrality of +Accessibility Supported in the many WCAG 2 success criteria that are +tied to use with assistive technologies and platform accessibility +features, combined with the lack of definition of what constitutes +Accessibility Supported, means that expert human judgement is required +to evaluate whether there is sufficient accessibility support for +specific technical implementations of accessibility implemented to meet +WCAG 2 success criteria. The lack of a broad base of +accessibility expertise in the web development field, combined with the challenges mentioned above +related to Challenge #1: Scaling Conformance Verification, (when human evaluation is + required) make the Accessibility Supported requirement a further + challenge unto itself. Understanding Conformance 2.0 further notes that: There is a need for an external and international dialogue on this topic. +Meanwhile, the nonnormative WCAG evaluation methodology (WCAG-EM) advises approaching this conformance requirement by determining: the minimum set of combinations of operating systems, web browsers, assistive technologies, and other user agents that the website is expected to work with, and that is in-line with the + WCAG 2.0 guidance on accessibility support.

    + +

    Not only does this conformance requirement of WCAG 2.x ask the content +provider to check their content markup with commonly used browsers, it also +asks that they further check usability with an undefined range of assistive +technologies on those same commonly used operating environments in order to +make a conformance claim. This requirement greatly exacerbates Challenge #2: Large, complex, and dynamic websites may have +too many changing permutations to validate effectively. It also exacerbates +Challenge #3: 3rd party content, where third party +content may have been shown to be Accessibility Supported with a set of +browsers, access features, and assistive technologies that has no overlap with +the set of browsers, access features, and assistive technologies that +constitute Accessibility Support for the site hosting that third party +content.

    + +
    +

    Silver Research Findings

    + +

    Silver concluded that Accessibility Supported is a conformance requirement +of WCAG 2 that is poorly understood and incompletely implemented, … i.e. the role +of AT in assessing conformance. See additional details in Appendix C below. +

    + +
    + +
    +

    Mitigations

    + +

    We know of no useable mitigations to achieve the Accessibility Supported conformance requirement for public facing web sites. WCAG-EM's Second Note suggests that: For some websites in closed networks, such as an intranet website, where both the users and the computers used to access the website are known, this baseline may be limited to the operating systems, web browsers and assistive +technologies used within this closed network. It continues saying: However, in most cases this baseline is ideally broader to cover the majority of current user agents used by people with disabilities in any applicable particular geographic region and +language community. Beyond placing the responsibility on the evaluator to establish this baseline, Note 5 in Understanding Conformance 2.0 suggests that: 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. … Authors, companies, technology vendors, or others may document accessibility-supported ways of using Web content technologies. Unfortunately, we know of no such public repository. +

    +
    +
    +

    Detailed Challenges with Scaling Conformance Verification for the Success Criteria in WCAG 2.1 A and AA

    This appendix describes challenges with applying the WCAG 2.x conformance model to specific Guidelines and Success Criteria, primarily based on required -human involvement in evaluation of conformance to them. In this draft, the -list is not exhaustive, but we intend it to cover all known challenges with -all A and AA Success Criteria, by the time this Note is completed. The purpose -of this is not to critique WCAG 2 nor to imply that sites and policies should +human involvement in evaluation of conformance to them. The +list is not exhaustive, but it covers the preponderance of known challenges with all A and AA Success Criteria. The purpose +of this list is not to critique WCAG 2 nor to imply that sites and policies should not do their best, and strive to conform to it, but rather to indicate known areas for which it may not be possible to conform, and which a new conformance model would hopefully address.

    -

    We have seen the market respond to the increased demand for accessibility professionals in part due to the amount of required human involvement in the valuation of conformance, with many international efforts such as the International Association of Accessibility Professionals (IAAP) which train and/or certify accessibility professionals. While this is resulting in downward pressure on costs of testing and remediation with more accessibility professionals becoming available to meet the need, it doesn't in and of itself eliminate the challenges noted below. Furthermore, for the near term, it appears the demand will be greater than the supply of this type of specialized expertise.

    -

    Also, the Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0 [[wcag-em]] lays out a strategy to combine human testing and automated testing. In the model, automation is used for a large number of pages (or all pages) and sampling is used for human testing. The WCAG-EM suggests that the human evaluation sample might include templates pages, component libraries, key flows (such as choosing a product and purchasing it, or signing up for a newsletter, etc.), and random pages. While WCAG-EM provides a practical method for claiming conformance for a website, it doesn't fully address the challenges in making every part of every page in a large, dynamic website conform to every success criterion.

    -
    +

    We have seen the market respond to the increased demand for accessibility professionals in part due to the amount of required human involvement in the valuation of conformance, with many international efforts such as the International Association of Accessibility Professionals (IAAP) which train and/or certify accessibility professionals. While this is resulting in downward pressure on costs of testing and remediation with more accessibility professionals becoming available to meet the need, it doesn't in and of itself eliminate the challenges noted below. Furthermore, for the near term, it appears the demand will be greater than the supply of this type of specialized expertise.

    +

    Also, the Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0 [[wcag-em]] lays out a strategy to combine human testing and automated testing. In the model, automation is used for a large number of pages (or all pages) and sampling is used for human testing. The WCAG-EM suggests that the human evaluation sample might include templates pages, component libraries, key flows (such as choosing a product and purchasing it, or signing up for a newsletter, etc.), and random pages. While WCAG-EM provides a practical method for claiming conformance for a website, it doesn't fully address the challenges in making every part of every page in a large, dynamic website conform to every success criterion.

    +

    Text Alternatives for Non-Text Content

    Text alternatives for images are an early, and still widely used, accessibility enhancement to HTML. Yet text alternatives remain one of the more intractable accessibility guidelines to assess with automated accessibility checking. While testing for the presence of alternative text is straightforward, and a collection of specific errors (such as labeling a graphic spacer.gif) can be identified by automated testing, human judgment remains necessary to evaluate whether or not any particular text alternative for a graphic is correct and conveys the true meaning of the image. Image recognition techniques are not mature enough to fully discern the underlying meaning of an image and the intent of the author in its inclusion. As a simple example, an image or icon of a paper clip would likely be identified by image recognition simply as a paper clip. However, when a paper clip appears in content often its meaning is to show there is an attachment. In this specific example, the alternative text should be attachment, not paper clip. Similarly, the image of a globe (or any graphical object representing planet Earth) can be used for a multiplicity of reasons, and the appropriate alternative text should indicate the reason for that use and not descriptive wording such as globe or Planet Earth. One not uncommon use of a globe today expands to allow users to select their preferred language, but there may be many other reasonable uses of such an icon.

    -
    +

    Time-Based Media

    Practices for creating alternatives to spoken dialog, and to describe visual content, were established in motion picture and TV content well before the world wide web came into existence. These practices formed the basis of the Media Accessibility User Requirements (MAUR) [[media-accessibility-reqs]] for time-based streaming media on the web in HTML5, which now supports both captioning and descriptions of video.

    -

    Yet, just as with text alternatives, automated techniques and testing aren't sufficient for creating and validating accessible alternatives to time-based media. For example, Automatic Speech Recognition (ASR) often fails when the speech portion of the audio is low quality, isn’t clear, or has background noise or sound-effects. In addition, current automated transcript creation software doesn't perform speaker identification, meaningful sound identification, or correct punctuation that all are necessary for accurate captioning. Work on automatically generated descriptions of video are in their infancy, and like image recognition techniques, don’t provide usable alternatives to video.

    -

    Similarly, while there is well articulated guidance on how to create text transcripts or captions for audio-only media (such as radio programs and audio books), automated techniques and testing again aren't sufficient for creating and validating these accessible alternatives. Knowing what is important in an audio program to describe to someone who cannot hear is beyond the state of the art. There are several success criteria under this Guideline that all share these challenges of manual testing being required to ensure alternatives accurately reflect the content in the media. These include:

    +

    Yet, just as with text alternatives, automated techniques and testing aren't sufficient for creating and validating accessible alternatives to time-based media. For example, Automatic Speech Recognition (ASR) often fails when the speech portion of the audio is low quality, isn’t clear, or has background noise or sound-effects. In addition, current automated transcript creation software doesn't perform speaker identification, meaningful sound identification, or correct punctuation that all are necessary for accurate captioning. Work on automatically generated descriptions of video are in their infancy, and like image recognition techniques, don’t provide usable alternatives to video.

    +

    Similarly, while there is well articulated guidance on how to create text transcripts or captions for audio-only media (such as radio programs and audio books), automated techniques and testing again aren't sufficient for creating and validating these accessible alternatives. Knowing what is important in an audio program to describe to someone who cannot hear is beyond the state of the art. There are several success criteria under this Guideline that all share these challenges of manual testing being required to ensure alternatives accurately reflect the content in the media. These include:

    -
    +

    Info and Relationships

    Info and Relationships

    Whether in print or online, the presentation of content is often structured in a manner intended to aid comprehension. Sighted users perceive structure and relationships through various visual cues. Beyond simple sentences and paragraphs, the sighted user may see headings with nested subheadings. There may be sidebars and inset boxes of related content. Tables may be used to show data relationships. Comprehending how content is organized is a critical component of understanding the content.

    As with media above, automated testing can determine the presence of structural markup, and can flag certain visual presentations as likely needing that structural markup. But such automated techniques remain unable to decipher if that markup usefully organizes the page content in a way that a user relying on assistive technology can examine the page systematically and readily understand its content.

    -
    +

    Meaningful Sequence

    Meaningful Sequence

    Often the sequence in which content is presented affects its meaning. In some content there may be even more than one meaningful way of ordering that content. However, as with Info and Relationships above, automated techniques are unable to determine whether content will be presented to screen reader users in a meaningful sequence ordering. For example, the placement of a button used to add something to a virtual shopping cart is very important for screen reader users, as improper placement can lead to confusion about which item is being added.

    -
    +

    Sensory Characteristics

    -

    Ensuring that no instructions rely on references to sensory characteristics presents similar challenges to ensuring that color isn't the sole indicator of meaning (Success Criterion 1.4.1) – it is testing for a negative, and requires a deep understanding of meaning conveyed by the text to discern a failure programmatically. For example, while instructions such as select the red button reference a sensory characteristic, select the red button which is also the first button on the screen may provide sufficient non-sensory context to not cause a problem (and multi-modal, multi-sensory guidance is often better for users with cognitive impairments or non-typical learning styles).

    +

    Ensuring that no instructions rely on references to sensory characteristics presents similar challenges to ensuring that color isn't the sole indicator of meaning (Success Criterion 1.4.1) – it is testing for a negative, and requires a deep understanding of meaning conveyed by the text to discern a failure programmatically. For example, while instructions such as select the red button reference a sensory characteristic, select the red button which is also the first button on the screen may provide sufficient non-sensory context to not cause a problem (and multi-modal, multi-sensory guidance is often better for users with cognitive impairments or non-typical learning styles).

    -
    +

    Orientation

    Orientation

    While an automated test can determine that the orientation is locked, full evaluation of conformance to this criterion is tied to whether it is essential for the content to be locked to one specific orientation (e.g. portrait or landscape views of an interface rendered to a cell phone). This requires human judgment to ensure that, any time the orientation is locked, the orientation is essential to that content to determine conformance. As of yet, this requires human judgement and is not fully automatable.

    -
    +

    Identify Input Purpose

    Identify Input Purpose

    An automated test can easily determine that input fields use HTML markup to indicate the input purpose, however, manual verification is needed to determine that the correct markup was used to match the intent for the field. For example, for a name input field, there are 10 variations of HTML name purpose attributes with different meaning and using the incorrect markup would be confusing to the user.

    -
    +

    Use of Color

    Use of Color

    This poses the same challenges as Sensory Characteristics (Success Criterion 1.3.3). To discern whether a page fails this criterion programmatically requires understanding the full meaning of the related content on the page and whether any meaning conveyed by color is somehow also conveyed in another fashion (e.g. whether the meaning of the colors in a bar chart is conveyed in the body of associated text or with a striping/stippling pattern as well on the bars, or perhaps some other fashion).

    -
    +

    Audio Control

    Audio Control

    An automated test tool would be able to identify media/audio content in a website, identify whether auto-play is turned on in the code, and also determine the duration. However, an automated test tool cannot determine whether there is a mechanism to pause, stop the audio, or adjust the volume of the audio independent of the overall system volume level. This still requires manual validation.

    -
    +

    Contrast (Minimum)

    -

    Automated tools can check the color of text against the background in most cases. However, there are several challenges with using current state of the art automated tools for this success criterion, including (1) when background images are used, automated tests aren't reliably able to check for minimum contrast of text against the image—especially if the image is a photograph or drawing where the text is placed over the image, and (2) situations in which depending upon context such as text becoming incidental because it is part of an inactive user interface component or is purely decorative or part of a logo. These would take human intervention to sample the text and its background to determine if the contrast meets the minimum requirement.

    +

    Automated tools can check the color of text against the background in most cases. However, there are several challenges with using current state of the art automated tools for this success criterion, including (1) when background images are used, automated tests aren't reliably able to check for minimum contrast of text against the image—especially if the image is a photograph or drawing where the text is placed over the image, and (2) situations in which depending upon context such as text becoming incidental because it is part of an inactive user interface component or is purely decorative or part of a logo. These would take human intervention to sample the text and its background to determine if the contrast meets the minimum requirement.

    -
    +

    Resize Text

    Resize Text

    While automated tools can test whether it is possible to resize text on a webpage, it takes human evaluation to determine whether there has been a loss of content or functionality as a result of the text resizing.

    -
    +

    Images of Text

    Images of Text

    This poses the same challenge as Orientation (Success Criterion 1.3.4) - it is tied to whether it is essential for text to be part of an image. This requires human judgment, making this criterion not readily automatable. Additionally, methods of employing OCR on images will not accurately discern text of different fonts that overlap each other, or be able to recognize unusual characters or text with poor contrast with the background of the image.

    -
    +

    Reflow

    Reflow

    While automated tests can detect the presence of vertical and horizontal scroll bars, there are currently no reliable tests to automate validating that there has been no loss in content or functionality. Human evaluation is also still needed to determine when two-dimensional scrolling is needed for content that requires two-dimensional layout for usage or meaning.

    -
    +

    Non-text Contrast

    Non-text Contrast to utilize the exception which requires human intervention.

    -
    +

    Text Spacing

    Text Spacing

    This success criterion involves using a tool or method to modify text spacing and then checking to ensure no content is truncated or overlapping. There is currently no way to reliably automate validating that no loss of content of functionality has occurred when text spacing has been modified.

    -
    +

    Content on Hover or Focus

    Content on Hover or Focus

    -
    +

    Keyboard Operable

    Keyboard Operable

    While an automated test can evaluate whether a page can be tabbed through in its entirety, ensuring keyboard operability of all functionality currently requires a human to manually navigate through content to ensure all interactive elements are not only in the tab order, but can be fully operated using keyboard controls.

    -
    +

    Character Key Shortcuts

    Character Key Shortcuts

    Character key shortcuts can be applied to content via scripting but whether and what these shortcut key presses trigger can only be determined by additional human evaluation.

    -
    +

    Timing Adjustable

    Timing Adjustable

    There is currently no easy way to automate checking whether timing is adjustable. Ways of controlling differ in naming, position, and approach (including dialogs/popups before the time-out). This can also be affected by how the server registers user interactions (e.g. for automatically extending the time-out).

    -
    +

    Pause, Stop, Hide

    Pause, Stop, Hide

    Typically the requirement to control moving content is provided by interactive controls placed in the vicinity of moving content, or occasionally at the beginning of content. Since position and naming vary, this assessment cannot currently be automated (this involves checking that the function works as expected).

    -
    +

    Three Flashes or Below Threshold

    Three Flashes or Below Threshold

    There are currently no known automated tests that are accurately able to assess areas of flashing on a webpage to ensure that the flashing happens less than three times per second.

    -
    +

    Bypass Blocks

    Bypass Blocks

    While it can be determined that native elements or landmark roles are used, there is currently no automated way to determine whether they are used to adequately structure content (are they missing out on sections that should be included). The same assessment would be needed when other Techniques are used (structure by headings, skip links).

    -
    +

    Page titled

    Page titled

    Automating a check for whether the page has a title is simple; ensuring that the title is meaningful and provides adequate context as to the purpose of the page is not currently possible.

    -
    +

    Focus Order

    Focus Order

    There is currently no known way to automate ensuring that focus handling with dynamic content (e.g. moving focus to a custom dialog, keep focus in dialog, return to trigger) follows a logical order.

    -
    +

    Link Purpose (In Context)

    Link Purpose (In Context)

    Automated tests can check for the existence of links with the same name, as well as check whether links are qualified programmatically, but checking whether the link text adequately describes the link purpose still involves human judgment.

    -
    +

    Multiple ways

    Multiple ways

    Automated tests can validate whether pages can be reached with multiple ways (e.g. nav and search), but will miss cases where exceptions hold (all pages can be reached from anywhere) and still require human validation.

    -
    +

    Headings and Labels

    Headings and Labels

    Automated tests can detect the existence of headings and labels, however, there is currently no way to automate determining whether the heading or label provides adequate context for the content that follows.

    -
    +

    Pointer Gestures

    Pointer Gestures

    There are currently no known automated checks that would accurately detect complex gestures - even when a script indicates the presence of particular events like touch-start, the event called would need to be checked in human evaluation.

    -
    +

    Pointer Cancellation

    Pointer Cancellation

    -
    +

    Motion Actuation

    Motion Actuation

    Motion activated events may be detected automatically but whether there are equivalents for achieving the same thing with user interface components currently requires human evaluation.

    -
    +

    On Focus

    On Focus

    There is currently no reliable way to accurately automate checking whether a change caused by moving focus should be considered a change of content or context.

    -
    +

    On Input

    On Input

    There is currently no reliable way to accurately automate checking whether changing the setting of any user interface component should be considered a change of content or context, or to automatically detect whether relevant advice exists before using the component in question.

    -
    +

    Error Identification

    Error Identification

    Insuring whether an error message correctly identifies and describes the error accurately and in a way that provides adequate context currently requires human evaluation.

    -
    +

    Labels or Instructions

    Labels or Instructions

    A.35 Edge cases (labels close enough to a component to be perceived as a visible label) will require a human check. Some labels may be programmatically linked but hidden or visually separated from the element to which they are linked. Whether instructions are necessary and need to be provided will hinge on the content. Human check needed.

    -
    +

    Error Suggestion

    Error Suggestion

    Whether an error suggestion is helpful or correct currently requires human evaluation.

    -
    +

    Name, Role, Value

    Detailed Challenges with Conformance Verification and Testing for Non-Web IC entire software application. The remaining 10 were more straightforward to apply to non-web ICT, but still required some text changes.

    -

    Since publication of WCAG2ICT, [[wcag2ict]] WCAG 2.1 was published introducing a number of additional success criteria at the A and AA levels. Some of these may also pose specific challenges for conformation verification and testing in the non-web ICT context. A future version of this document will address those -new success criteria in the non-Web ICT Context. +

    Since publication of WCAG2ICT, [[wcag2ict]] WCAG 2.1 was published introducing a number of additional success criteria at the A and AA levels. Some of these may also pose specific challenges for conformation verification and testing in the non-web ICT context.

    The 18 success criteria noted in WCAG2ICT are discussed below in four sections, -the last of which address the 14 of the 38 A and AA criteria in WCAG 2.0 which relate to an accessibility supported interface, which may not be possible for software running in a closed environment (e.g. an airplane ticket kiosk). +the last of which address the 14 of the 38 A and AA criteria in WCAG 2.0 which relate to an Accessibility Supported interface, which may not be possible for software running in a closed environment (e.g. an airplane ticket kiosk).

    @@ -800,21 +866,21 @@

    Set of Web Pages Success Criteria

    These four success criteria, include either the term set of pages or multiple pages, which in the non-web ICT context becomes either a Set of Documents or a Set of Software Programs. In either case (document or software), whether the criterion applies is dependent upon whether such a set exists, which may require human judgment. Where that set is determined to exist, it may be difficult to employ programmatic testing techniques to verify compliance with the specific criterion.

    -
    +

    Bypass Blocks

    -

    To ensure this criterion is met for non-web documents, once the set of documents is defined, every document in the set must be searched for blocks of content that are repeated across all of those documents, and a mechanism to skip those repeated blocks. Since the blocks aren't necessarily completely identical (e.g. a repeated listing of all other documents in a set might not include the document containing that list), a tool to do this may not be straightforward, and in any case, no such tool is known to exist today to do this with non-web documents. +

    To ensure this criterion is met for non-web documents, once the set of documents is defined, every document in the set must be searched for blocks of content that are repeated across all of those documents, and a mechanism to skip those repeated blocks. Since the blocks aren't necessarily completely identical (e.g. a repeated listing of all other documents in a set might not include the document containing that list), a tool to do this may not be straightforward, and in any case, no such tool is known to exist today to do this with non-web documents.

    -

    Similarly, to ensure this criterion is met for non-web software, once the set of software is defined, every software application in the set must be searched for blocks of content that are repeated across all of those applications, and a mechanism to skip those repeated blocks. Since the blocks aren't necessarily completely identical (e.g. a repeated listing of all other software in a set might not include the software application containing that list), a tool to do this may not be straightforward, and in any case, no such tool is known to exist today to do this with non-web software. +

    Similarly, to ensure this criterion is met for non-web software, once the set of software is defined, every software application in the set must be searched for blocks of content that are repeated across all of those applications, and a mechanism to skip those repeated blocks. Since the blocks aren't necessarily completely identical (e.g. a repeated listing of all other software in a set might not include the software application containing that list), a tool to do this may not be straightforward, and in any case, no such tool is known to exist today to do this with non-web software.

    -
    +

    Multiple Ways

    Multiple Ways

    Similarly, to ensure this criterion is met for non-web software, once the set of software is defined, every software application in the set must provide multiple mechanisms for locating every other application in the set. As noted by WCAG2ICT, if the software applications are on a file system, it may be possible to browse through the files or programs that make up a set, or search within members of the set for the names of other members. A file directory would be the equivalent of a site map for documents in a set, and a search function in a file system would be equivalent to a web search function for web pages. However, if this is not the case, then the set of software applications must expose at least 2 ways of locating every other application in the set. Determining if this is the case is not possible today with any testing tool we are aware of, and so would require human inspection.

    -
    +

    Consistent Navigation

    Consistent Navigation

    -
    +

    Consistent Identification

    Consistent Identification

    Non-Interference Success Criteria

    The non-interference success criteria are things that apply to all areas of the page. As explained in WCAG2ICT in the section Comments on - Conformance, it wasn't possible to unambiguously carve up software into + Conformance, it wasn't possible to unambiguously carve up software into discrete pieces, and so the unit of evaluation for non-web software is the whole software program. As with any software testing this can be a very large unit of evaluation, and methods similar to standard software testing might be @@ -871,7 +937,7 @@

    Non-Interference Success Criteria

    would normally be part of the software testing strategy to verify compliance with these four criteria.

    -
    +

    Audio Control

    Audio Control

    Where non-web software contains audio, especially audio that automatically plays in certain circumstances (e.g. making a ringing sound to indicate an -incoming call) ...

    -

    EDITOR'S NOTE
    Section content yet to be written.

    +incoming call) …

    +

    EDITOR'S NOTE
    Section content yet to be written.

    -
    +

    No Keyboard Trap

    No Keyboard Trap

    -
    +

    Pause, Stop, Hide

    Pause, Stop, Hide

    -
    +

    Three Flashes or Below Threshold

    Three Flashes or Below Threshold

    Remaining WCAG 2.0 A/AA success criterion mentioned in WCAG2ICT as needing additional text changes

    -
    +

    Reflow

    -

    EDITOR'S NOTE
    Section content yet to be written.

    +

    EDITOR'S NOTE
    Section content yet to be written.

    -
    +

    Timing Adjustable

    -

    EDITOR'S NOTE
    Section content yet to be written.

    +

    EDITOR'S NOTE
    Section content yet to be written.

    -
    +

    Pointer Gestures

    -

    EDITOR'S NOTE
    Section content yet to be written.

    +

    EDITOR'S NOTE
    Section content yet to be written.

    -
    +

    Pointer Cancellation

    -

    EDITOR'S NOTE
    Section content yet to be written.

    +

    EDITOR'S NOTE
    Section content yet to be written.

    -
    +

    Language of Page

    -

    EDITOR'S NOTE
    Section content yet to be written.

    +

    EDITOR'S NOTE
    Section content yet to be written.

    -
    +

    Language of Parts

    Language of Parts

    -
    +

    Error Prevention

    -

    EDITOR'S NOTE
    Section content yet to be written.

    +

    EDITOR'S NOTE
    Section content yet to be written.

    -
    +

    Parsing

    -

    EDITOR'S NOTE
    Section content yet to be written.

    +

    EDITOR'S NOTE
    Section content yet to be written.

    -
    +

    Name, Role, Value

    -

    EDITOR'S NOTE
    Section content yet to be written.

    +

    EDITOR'S NOTE
    Section content yet to be written.

    New A/AA Success Criteria in WCAG 2.1

    -
    +

    Text Spacing

    -

    EDITOR'S NOTE
    Section content yet to be written.

    +

    EDITOR'S NOTE
    Section content yet to be written.

    @@ -1059,10 +1125,10 @@

    Success Criteria Needing Special Treatment in Non-Accessibility Supported En

    15 of the 38 A and AA criteria in WCAG 2.0 relate to an accessibility supported interface — they are designed with interoperability with assistive technologies in mind. Such interaction may not be possible for many types of software (e.g. software running in a closed environment like an airplane ticket kiosk). Thus, in those environments, the only way to address the needs articulated in these criteria may be for the software to be self-voicing for blind users who can hear, and otherwise self-accessible to the needs of people with other disabilities which are commonly supported via assistive technologies. It may not be feasible to support all disability user needs (e.g. including a refreshable - braille display in the device to support deaf-blind users, and then maintaining those braille displays to ensure their mechanisms don't get damaged). + braille display in the device to support deaf-blind users, and then maintaining those braille displays to ensure their mechanisms don't get damaged).

    -
      +
    +

    -
    + +
    +

    Challenges of Conformance as identified from Silver Research

    +

    Now known as W3C Accessibility Guidelines (WCAG 3.0), this iteration of W3C accessibility guidance was conceived and designed to be research-based. Working over many years, the Silver Task Force of the Accessibility Guidelines Working Group (AGWG) and the Silver Community Group collaborated with researchers on questions that the Silver Groups identified. This research was used to develop 11 problem statements that needed to be solved for Silver. The detailed problem statements include the specific problem, the result of the problem, the situation and priority, and the opportunity presented by the problem. The problem statements were organized into three main areas: Usability, Conformance, and Maintenance. The section following is taken from the Conformance sections of the Silver Design Sprint Final Report and the Silver Problem Statements. Details of the research questions and the individual reports are in Research Archive of Silver wiki.

    +

    The following is shown as originally presented by the Silver task force, Key conclusions have been folded into specific enumerated challenges as appropriate.

    +
    +

    Silver Research Problem Statements

    +

    Originally published as the Silver Design Sprint Final Report (2018). These problem statements were presented to the Silver Design Sprint participants.

    +
      +
    • Constraints on What is Strictly Testable provides an obstacle to including guidance that meets the needs of people with disabilities but is not conducive to a pass/fail test.
    • +
    • Human Testable (related to Ambiguity) also relates to differences in knowledge and priorities of different testers achieve different results.
    • +
    • Accessibility Supported is a conformance requirement of WCAG 2 that is poorly understood and incompletely implemented.
    • +
    • Evolving Technology of the rapidly changing web must constantly be evaluated against the capabilities of assistive technology and evolving assistive technology must be evaluated against the backward compatibility of existing web sites.
    • +
    +
    +
    +

    Details of Problem Statements

    +

    Originally published as Silver Problem Statements, this was a detailed analysis of the research results behind the above list.

    +
    +

    Definition of Conformance

    +

    Conformance to a standard means that you meet or satisfy the requirements of the standard. In WCAG 2.0 the requirements are the Success Criteria. To conform to WCAG 2.0, you need to satisfy the Success Criteria, that is, there is no content which violates the Success Criteria.

    +

    WCAG 2.0 Conformance Requirements:

    +
      +
    1. Conformance Level (A to AAA)
    2. +
    3. Conformance Scope (For full web pages only, not partial)
    4. +
    5. Complete Process
    6. +
    7. Only "Accessibility-supported" ways of using technologies
    8. +
    9. Non-Interference: Technologies that are not accessibility supported can be used, as long as all the information is also available using technologies that are accessibility supported and as long as the non-accessibility-supported material does not interfere.
    10. +
    +
    +
    +

    Themes from Research

    +
      +
    • No monitoring process to test the accuracy of WCAG compliance claims (Keith et al., 2012)
    • +
    • Difficulties for conformance (Keith et al., 2012) +
        +
      • Third parties documents, applications and services
      • +
      • Know-how of IT personnel
      • +
      • Tension between accessibility and design
      • +
      +
    • + +
    • Specific success criteria for failure - 1.1.1 , 2.2., 4.1.2 (Keith et al., 2012)
    • +
    • Reliably Human Testable, not reliably testable Is Accessibility Conformance an Elusive Property? (Brajnik et al. 2012), found the average agreement was at the 70-75% mark, while the error rate was around 29%. +
        +
      • Expertise appears to improve (by 19%) the ability to avoid false positives. Finally, pooling the results of two independent experienced evaluators would be the best option, capturing at most 76% of the true problems and producing only 24% of false positives. Any other independent combination of audits would achieve worse results.
      • +
      • This means that an 80% target for agreement, when audits are conducted without communication between evaluators, is not attainable, even with experienced evaluators.
      • +
      +
    • +
    • Challenges and Recommendations (Alonso et al., 2010) +
        +
      • accessibility supported ways of using technologies
      • +
      • Testability of Success Criteria
      • +
      • Openness of Techniques and Failures
      • +
      • Aggregation of Partial Results
      • +
      +
    • +
    • Silver needs to expand the scope beyond web to include apps, documents, authoring, user agents, wearables, kiosks, IoT, VR, etc. and be inclusive of more disabilities. (UX Professionals Use of WCAG: Analysis)
    • +
    • Accessibility Supported allows inadequate assistive technologies to be claimed for conformance, particularly in non-native English speaking countries. (Interviews on Conformance)
    • +
    +
    +
    +

    Constraints on What is Strictly Testable

    +

    Specific problem: Certain success criteria are quite clear and measurable, like color contrast. Others, far less so. The entire principle of understandable is critical for people with cognitive disabilities, yet success criteria intended to support the principle are not easy to test for or clear on how to measure. As a simple example, there is no clear, recent or consistent definition – within any locale or language – on what lower secondary education level means in regard to web content. Language and text content is also not the only challenge among those with cognitive and learning disabilities. Compounding this, most of the existing criteria in support of understanding are designated as AAA, which relatively few organizations attempt to conform with.

    +

    Result of problem: The requirement for valid and reliable testability for WCAG success criteria presents a structural barrier to including the needs of people with disabilities whose needs are not strictly testable. Guidance that WCAG working group members would like to include cannot be included. The needs of people with disabilities – especially intellectual and cognitive disabilities – are not being met.

    +

    Situation and Priority: Of the 70 new success criteria proposed by the Cognitive Accessibility Task Force to support the needs of people with cognitive and intellectual disabilities, only four to six (depending on interpretation) were added to WCAG 2.1 and only one is in level AA. The remainder are in level AAA, which is rarely implemented. This means user needs are not met.

    +

    Opportunity: Multiple research projects and audience feedback have concluded that simpler language is desired and needed for audiences of the guidelines. Clear but flexible criteria with considerations for a wider spectrum of disabilities helps ensure more needs are met.

    +
    +
    +

    Human Testable

    +

    Specific problem: Regardless of proficiency, there is a significant gap in how any two human auditors will identify a success or fail of criteria. Various audiences have competing priorities when assessing the success criteria of any given digital property. Knowledge varies for accessibility standards and how people with disabilities use assistive technology tools. Ultimately, there is variance between: any two auditors; any two authors of test cases; and human bias. Some needs of people of disabilities are difficult to measure in a quantifiable way.

    +

    Result of problem: Success criteria are measured by different standards and by people who often make subjective observations. Because there's so much room for human error, an individual may believe they've met a specific conformance model when, in reality, that’s not the case. The ultimate impact is on an end user with a disability who cannot complete a given task, because the success criteria wasn’t properly identified, tested and understood.

    +

    Situation and Priority: There isn't a standardized approach to how the conformance model applies to success criteria at the organizational level and in specific test case scenarios.

    +

    Opportunity: There's an opportunity to improve the success criteria such that human auditors and testers find the success criteria more understandable. Educating business leaders on how the varying levels of conformance apply to their organization may be useful as well. We can educate about the ways that people with disabilities use their assistive technology.

    +
    +
    +

    Accessibility Supported

    +

    Specific problem: Accessibility supported was implemented in a way that did not facilitate consistent adoption by developers and testers. It also requires a harmonious relationship and persistent interoperability between content technologies and requesting technologies that must be continuously evaluated as either is updated. Further, the WG defers the judgment of how much, how many, or which AT must support a technology to the community. It is poorly understood, even by experts.

    +

    Result of problem: Among the results are: difficulty understanding what qualifies as a content technology or an assistive technology; difficulty quantifying assistive technologies or features of user agents; claiming conformance with inadequate assistive technology; and difficulty claiming conformance.

    +

    Situation and Priority: Any claim or assertion that a web page conforms to the guidelines may require an explicit statement defining which assistive technology and user agent(s) the contained technologies rely upon, and presumably inclusive of specific versions and or release dates of each. One could infer then that a conformance claim is dependent upon a software compatibility claim naming browsers and assistive technology and their respective versions. This would create a burden to author and govern such claims. Additionally, no one can predict and anticipate new technologies and their rates of adoption by people with disabilities.

    +

    Opportunity: As the technologies in this equation evolve, the interoperability may be affected by any number of factors outside of the control of the author and publisher of a web page. Either accessibility supported should not be a + component of conformance requirements, or it should clearly, concisely, and explicitly define and quantify the technologies or classes of technologies, AND set any resulting update or expiry criteria for governance.

    +
    +
    +

    Evolving Technology

    +

    Specific problem: Evolving Technology: As content technology evolves, it must be re-evaluated against assistive technology for compatibility. Likewise, as assistive technology evolves or emerges, it must be evaluated against the backward compatibility of various content technology.

    +

    Result of problem: There is no versioning consideration for updates to user agents and assistive technology. Strict conformance then typically has an expiry.

    +

    Situation and Priority: There is no clear and universal understanding of the conformance model or its longevity. Some will infer that there is always a conformance debt when any technology changes.

    +

    Opportunity: Consider conformance statements to include an explicit qualifier of time of release or versions of technology. OR consider a more general approach that is not explicit and is flexible to the differences in technologies as they evolve, identifying the feature of the assistive tech rather than the version of the assistive tech. OR consider a model that quantifies conformance as a degree of criteria met.

    +
    +
    +
    + +

    Acknowledgments

    -
    -

    Participants of the AG WG who contributed to the development of this document:

    -
      -
    • Charles Adams (Oracle)
    • -
    • Alastair Campbell (Nomensa)
    • -
    • Michael Cooper (W3C)
    • -
    • Joe Cronin (Amazon)
    • -
    • Detlev Fischer (Invited Expert)
    • -
    • Charles Hall (Invited Expert)
    • -
    • Andrew Kirkpatrick (Adobe)
    • -
    • Peter Korn (Amazon)
    • -
    • Shawn Lauriat (Google)
    • -
    • Mary Jo Mueller (IBM)
    • -
    • Janina Sajka (Amazon)
    • -
    • Jeanne Spellman (TetraLogical)
    • -
    • Jason White (ETS)
    • -
    -
    - -
    -

    Enabling funders

    -

    This publication has been funded in part with U.S. Federal funds from the Health and Human Services, National Institute on Disability, Independent Living, and Rehabilitation Research (NIDILRR) under contract number HHSP23301500054C. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Health and Human Services, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.

    -
    +
    +

    Participants of the AG WG who contributed to the development of this document:

    +
      +
    • Charles Adams (Oracle)
    • +
    • Alastair Campbell (Nomensa)
    • +
    • Michael Cooper (W3C)
    • +
    • Joe Cronin (Amazon)
    • +
    • Detlev Fischer (Invited Expert)
    • +
    • Charles Hall (Invited Expert)
    • +
    • Andrew Kirkpatrick (Adobe)
    • +
    • Peter Korn (Amazon)
    • +
    • Shawn Lauriat (Google)
    • +
    • Mary Jo Mueller (IBM)
    • +
    • Janina Sajka (Invited Expert; Was Amazon until 14 November 2021)
    • +
    • Jeanne Spellman (TetraLogical)
    • +
    • Jason White (ETS)
    • +
    +
    +
    diff --git a/conformance-challenges/respec-config.js b/conformance-challenges/respec-config.js index 83cacbfe19..ece8d4ac34 100644 --- a/conformance-challenges/respec-config.js +++ b/conformance-challenges/respec-config.js @@ -42,10 +42,9 @@ var respecConfig = { editors: [ { name: "Janina Sajka", - company: "Amazon", - companyURL: "https://www.amazon.com/", - mailto: "sajkaj@amazon.com", - w3cid: 108617 + URL: "https://linkedin.com/in/jsajka", + mailto: "janina@rednote.net", + w3cid: 33688 }, { name: "Michael Cooper", @@ -65,10 +64,9 @@ var respecConfig = { // company: "Your Company", companyURI: "http://example.com/" }, { name: "Janina Sajka", - company: "Amazon", - companyURL: "https://www.amazon.com/", - mailto: "sajkaj@amazon.com", - w3cid: 108617 + URL: "https://linkedin.com/in/jsajka", + mailto: "janina@rednote.net", + w3cid: 33688 }, { name: "Peter Korn", diff --git a/css/a11y-light.css b/css/a11y-light.css new file mode 100644 index 0000000000..f1bf8f3f8f --- /dev/null +++ b/css/a11y-light.css @@ -0,0 +1,99 @@ +/* a11y-light theme */ +/* Based on the Tomorrow Night Eighties theme: https://github.com/isagalaev/highlight.js/blob/master/src/styles/tomorrow-night-eighties.css */ +/* @author: ericwbailey */ + +/* Comment */ +.hljs-comment, +.hljs-quote { + color: #696969; +} + +/* Red */ +.hljs-variable, +.hljs-template-variable, +.hljs-tag, +.hljs-name, +.hljs-selector-id, +.hljs-selector-class, +.hljs-regexp, +.hljs-deletion { + color: #d91e18; +} + +/* Orange */ +.hljs-number, +.hljs-built_in, +.hljs-builtin-name, +.hljs-literal, +.hljs-type, +.hljs-params, +.hljs-meta, +.hljs-link { + color: #aa5d00; +} + +/* Yellow */ +.hljs-attribute { + color: #aa5d00; +} + +/* Green */ +.hljs-string, +.hljs-symbol, +.hljs-bullet, +.hljs-addition { + color: #008000; +} + +/* Blue */ +.hljs-title, +.hljs-section { + color: #007faa; +} + +/* Purple */ +.hljs-keyword, +.hljs-selector-tag { + color: #7928a1; +} + +.hljs { + display: block; + overflow-x: auto; + background: #fefefe; + color: #545454; + padding: 0.5em; +} + +.hljs-emphasis { + font-style: italic; +} + +.hljs-strong { + font-weight: bold; +} + +@media screen and (-ms-high-contrast: active) { + .hljs-addition, + .hljs-attribute, + .hljs-built_in, + .hljs-builtin-name, + .hljs-bullet, + .hljs-comment, + .hljs-link, + .hljs-literal, + .hljs-meta, + .hljs-number, + .hljs-params, + .hljs-string, + .hljs-symbol, + .hljs-type, + .hljs-quote { + color: highlight; + } + + .hljs-keyword, + .hljs-selector-tag { + font-weight: bold; + } +} diff --git a/css/base.css b/css/base.css index b028c7b059..25a82c2c1f 100644 --- a/css/base.css +++ b/css/base.css @@ -1,17 +1,473 @@ -.wcag21, .wcag22 { - background-color: #E9FBE9; - border-left: solid .5em #52E052; +main { + display: block; } -span.wcag21, span.wcag22 { - margin-left: .25em; - padding-left: .25em; + +.nav-container { } -div.wcag21, div.wcag22 { - margin: 1em auto; - padding: .5em; - page-break-inside: avoid; + +.nav { + overflow: inherit; } -.new-version { - font-size: smaller; + +.nav__item a { + display: inline-block; + white-space: inherit; +} + +.nav__item a svg { + vertical-align: middle; + height: 1em; +} + +.nav__item a + button { + margin-left: -0.75em; + margin-right: 1em; + ; +} + +.minimal-header { + -ms-grid-column: 2; + -ms-grid-column-span: 8; + -ms-grid-row: 1; + grid-column: 2/10; +} + +.minimal-header-name a { + text-decoration: none; +} +.minimal-header-name a:hover, .minimal-header-name a:focus { + text-decoration: underline; +} + +.main-content { + -ms-grid-column: 2; + -ms-grid-column-span: 6; + grid-column: 2/span 6; + -ms-grid-row: 2; + -ms-grid-row-span: 2; + grid-row-start: 2; +} + +.sidebar ul { + padding: 0; +} + +.sidebar dd { + margin-left: 0 !important; +} + +h1 { + padding-top: 33px; +} + +h1 span { + display: block; + font-size: .5em; + margin-bottom: 0.25em; +} + +h2 { + position: relative; +} + +h2 .permalink { + position: absolute; + left: -1em; +} + +h2 .permalink a { + color: var(--grey); + text-decoration: none; +} + +h2 .fragmentlink { + margin-left: -1em; + position: relative; + float: left; +} + +h2 .fragmentlink svg { + visibility: hidden; +} + +h2:hover .fragmentlink svg { + visibility: visible; +} + +#success-criterion h2, #guideline h2, #technique h2 { + margin: 0; +} + +.navtoc ul { + margin: 0.5em 0; +} + +dt div { + font-weight: normal; +} + +.toc-wcag-docs { + padding-left: 1em; +} + +.main-content > .toc-understanding-guideline > li > a { font-weight: bold; -} \ No newline at end of file + margin-top: 2em; + margin-bottom: -.5em; + display: block; + text-decoration: none; +} + +.scquote { + margin: 0; + border: 1px solid var(--line-grey); + padding: 1em; + font-style: normal; +} +.scquote > :first-child { + margin-top: 0; + padding-top: 0; +} + +.minimal-header-container { + background-color: #005a9c; + background-color: var(--w3c-classic); + color: #fff; + color: var(--pure-white); +} +.minimal-header-logo > a { + display: flex; +} +.minimal-header-name > a { + color: inherit; +} + +.note { + padding: 0em 1em; + margin-bottom: 1em; +} +.note-title { + font-weight: bold; + margin: 0; +} + +.note p { + margin-top: 0; +} + +:is(aside, div).example .example-title { + font-weight: bold; + margin: 0; +} +:is(aside, div).example { + padding: 1em 1em 0.5em 1em; + margin-bottom: 1em; + border-left-width: .5em; + border-left-style: solid; + border-color: #e0cb52; + background: #fcfaee +} + +.obsolete { + border-left: solid 5px var(--faded-red); +} + +.obsolete-message { + background-color: var(--red-subtle); + border-color: var(--faded-red); +} + +.obsolete-message h2 { + color: #fff; + background-color: var(--faded-red); + margin: 0; +} + +/* import inline styles from https://www.w3.org/WAI/drafts/WCAG-understanding-redesign-hack.html */ +.nav a:link { +text-decoration: none; +} +#site-header.minimal-header.with-subtitle { +padding: 1.75em 0 0 0; +} + +.minimal-header-logo img { +margin: 1px 0 1px 0; +} +.minimal-header-logo svg { +margin: 0.75em 0 0.75em 0.5em; +} + +#site-header.minimal-header { +margin: 1.2em 0; +align-items: stretch; +} + +#site-header.minimal-header .minimal-header-name, +#site-header.minimal-header .minimal-header-subtitle, +#site-header.minimal-header .minimal-header-link +{ +display: flex; +flex-direction: column; +justify-content: center; +} + +.minimal-header-name { +flex: width 0 0; +} + +.minimal-header-subtitle, +.minimal-header-link { +border-left: 1px solid var(--gold); +padding-left: 8px; +margin-left: 18px; +display: block; +font-size: 80%; +flex: 1 0 0; +} + +.minimal-header-subtitle { +font-style: italic; +} + +.minimal-header-link { +text-decoration: underline !important; +font-weight: normal; +margin-right: 16px; +} + +.nav-container { +margin-bottom: 0; +} + +.nav { +background: none; +} + +.nav-related-info { /* blue bar with the "About:" links */ +background: #005a9c; +color: #fff; +} + +.nav-related-info a { +color: #fff !important; +} + +.nav-page-specific { /* light blue bar with page/section specific navigation/pager */ +margin-bottom: 1.25em; +} + +.nav a:link, .nav a:visited { +color: #036; +color: var(--w3c-blue); +} + +.nav a:hover, .nav a:active { +color: var(--dk-blue); +} + +.nav-hack.sidebar a:hover, +.nav-hack.sidebar a:active +{ +color: var(--dk-blue); +text-decoration: underline; +} + +.standalone-resource-about, .standalone-resource-pager { +margin: 0; +} + +nav.standalone-resource-about { +padding: .5em 0 1.5em 0; +font-style: italic; +} + +.standalone-resource-about dl, .standalone-resource-about dt, .standalone-resource-about dd { +display: inline; +margin: 0; +padding: 0; +} + +.standalone-resource-about dt{ +font-weight: normal; +} + +.standalone-resource-about dl a { +margin: 0; +padding: 0 1em 0 1em; +} + +.standalone-resource-about dd { +border-right: 1px var(--gold) solid; +} + +.standalone-resource-about dd:last-of-type { +border-right: 0; +} + +.standalone-resource-about dd svg { +margin-left: 0.25rem; +vertical-align: middle; +} + +.nav .standalone-resource-pager ul { +align-items: center; +} + +.nav .standalone-resource-pager a, +.nav .standalone-resource-pager span { +margin-left: 0; +margin-right: 0; +} + +.pager-icon { +vertical-align: middle; +padding: 0 0.15em 0.15em 0.15em; +width: 1em; +height: 2em; +fill: #005A6A; /* when these are used as actual SVGs */ +} + +.category-icon { +vertical-align: middle; +padding: 0 0.25em 0.25em 0.25em; +width: 2em; +height: 2em; +} + +.standalone-resource-pager ul { +display: block; +} + +.standalone-resource-pager ul li { +display: inline; +} + +.nav-hack { +font-size: .85em; +/*justify-self: end;*/ +align-self: start; +} +.nav-hack ul { +list-style: none; +padding-left: 0 +} +.nav-hack li:not(:first-child){ +padding-top: 0.4em; +line-height: 1.2; +border-top: 1px solid #BCBCBC; +} +.nav-hack li a { +text-decoration: none; +} +.nav-hack h3 { +margin: 0; +font-size: 1rem; +} + +.nav-hack p { +margin: 0; +} + + +/* skip link */ +.button--skip-link { +background-color: var(--gold) !important; +border-color: var(--gold) !important; +outline-color: currentColor !important; +color: var(--off-black) !important; +font-weight: 600; +font-size: larger; +margin: 0 auto; +position: absolute; +z-index: 20; +left: 0; +right: 0; +top: 0.5em; +width: 10em; +opacity: 1; +transition: transform 0.1875s ease-out, opacity 0.1875s ease-out; +} + +.button--skip-link:not(:focus):not(:hover) { +transform: translateY(-4em); +opacity: 0; +} + +.standalone-resource-navrule { +border:none; +border-top: 1px solid grey +} + +.standalone-resource-about ul, +.standalone-resource-pager ul { +list-style: none; +} + +.nav { +font-size: 95%; +} + +.standalone-resource-about a, +.standalone-resource-pager a, +.standalone-resource-about span, +.standalone-resource-pager span +{ +margin-left:.8em; +margin-right:.8em; +} + +.example video, +#examples video +{ + max-width: 100%; +} + +#brief { + margin-bottom: 3em; +} +#brief dl { + margin-left: 2em; +} + +@media (max-width: 35em) { + .nav-container { + padding: 0; + } + .nav a { + display: inline-block; + width: calc(100% - 2em); + } + @supports (display:gred) { + #site-header { + padding-left: 0; + } + } + .minimal-header { + display: block; + } + #site-header.minimal-header .minimal-header-name, #site-header.minimal-header .minimal-header-subtitle, #site-header.minimal-header .minimal-header-link { + display: block; + } + #site-header.minimal-header .minimal-header-subtitle { + display: none; + } + .minimal-header-name { + font-size: 160%; + margin-bottom: 0.5em; + } + .minimal-header-link { + margin-left: 0; + padding-left: 0; + border: none; + } + .minimal-header-logo { + display: block; + } + .minimal-header-logo > a { + display: inline-block; + } + .minimal-header-logo svg { + margin: 1em 0 0 0; + } +} diff --git a/eleventy.config.ts b/eleventy.config.ts new file mode 100644 index 0000000000..fc9fe5ff69 --- /dev/null +++ b/eleventy.config.ts @@ -0,0 +1,299 @@ +import compact from "lodash-es/compact"; +import { rimraf } from "rimraf"; + +import { copyFile } from "fs/promises"; + +import { CustomLiquid } from "11ty/CustomLiquid"; +import { + actRules, + assertIsWcagVersion, + getFlatGuidelines, + getPrinciples, + type Guideline, + type Principle, + type SuccessCriterion, +} from "11ty/guidelines"; +import { + getFlatTechniques, + getTechniqueAssociations, + getTechniquesByTechnology, + technologies, + technologyTitles, + type Technique, + type Technology, +} from "11ty/techniques"; +import { generateUnderstandingNavMap, getUnderstandingDocs } from "11ty/understanding"; +import type { EleventyContext, EleventyData, EleventyEvent } from "11ty/types"; + +/** Version of WCAG to build */ +const version = process.env.WCAG_VERSION || "22"; +assertIsWcagVersion(version); + +/** + * Returns boolean indicating whether a technique is obsolete for the given version. + * Tolerates undefined for use with hash lookups. + */ +const isTechniqueObsolete = (technique: Technique | undefined) => + !!technique?.obsoleteSince && technique.obsoleteSince <= version; + +/** + * Returns boolean indicating whether an SC is obsolete for the given version. + * Tolerates other types for use with hash lookups. + */ +const isGuidelineObsolete = (guideline: Principle | Guideline | SuccessCriterion | undefined) => + guideline?.type === "SC" && guideline.level === ""; + +const principles = await getPrinciples(); +const flatGuidelines = getFlatGuidelines(principles); +const techniques = await getTechniquesByTechnology(); +const flatTechniques = getFlatTechniques(techniques); + +for (const [technology, list] of Object.entries(techniques)) { + // Prune obsolete techniques from ToC + techniques[technology as Technology] = list.filter( + (technique) => !technique.obsoleteSince || technique.obsoleteSince > version + ); +} + +const techniqueAssociations = await getTechniqueAssociations(flatGuidelines); +for (const [id, associations] of Object.entries(techniqueAssociations)) { + // Prune associations from non-obsolete techniques to obsolete SCs + techniqueAssociations[id] = associations.filter( + ({ criterion }) => criterion.level !== "" || isTechniqueObsolete(flatTechniques[id]) + ); +} + +const understandingDocs = await getUnderstandingDocs(version); +const understandingNav = await generateUnderstandingNavMap(principles, understandingDocs); + +// Declare static global data up-front so we can build typings from it +const globalData = { + version, + versionDecimal: version.split("").join("."), + techniques, // Used for techniques/index.html + technologies, // Used for techniques/index.html + technologyTitles, // Used for techniques/index.html + principles, // Used for understanding/index.html + understandingDocs, // Used for understanding/index.html +}; + +export type GlobalData = EleventyData & + typeof globalData & { + // Expected data cascade properties from *.11tydata.js + headerLabel?: string; // akin to documentset.name in build.xml + headerUrl?: string; + isTechniques?: boolean; + isUnderstanding?: boolean; + }; + +const [GH_ORG, GH_REPO] = (process.env.GITHUB_REPOSITORY || "w3c/wcag").split("/"); + +const baseUrls = { + guidelines: `https://www.w3.org/TR/WCAG${version}/`, + techniques: "/techniques/", + understanding: "/understanding/", +}; + +if (process.env.WCAG_MODE === "editors") { + // For pushing to gh-pages + baseUrls.guidelines = `https://${GH_ORG}.github.io/${GH_REPO}/guidelines/${ + version === "21" ? "" : `${version}/` + }`; + baseUrls.techniques = `https://${GH_ORG}.github.io/${GH_REPO}/techniques/`; + baseUrls.understanding = `https://${GH_ORG}.github.io/${GH_REPO}/understanding/`; +} else if (process.env.WCAG_MODE === "publication") { + // For pushing to W3C site + baseUrls.guidelines = `https://www.w3.org/TR/WCAG${version}/`; + baseUrls.techniques = `https://www.w3.org/WAI/WCAG${version}/Techniques/`; + baseUrls.understanding = `https://www.w3.org/WAI/WCAG${version}/Understanding/`; +} + +export default function (eleventyConfig: any) { + for (const [name, value] of Object.entries(globalData)) eleventyConfig.addGlobalData(name, value); + + // Make baseUrls available to templates + for (const [name, value] of Object.entries(baseUrls)) + eleventyConfig.addGlobalData(`${name}Url`, value); + + // Use git modified time if building for gh-pages or W3C site; + // otherwise use local mtime to cut build time (~4s difference). + // See https://www.11ty.dev/docs/dates/#setting-a-content-date-in-front-matter + eleventyConfig.addGlobalData("date", `${process.env.WCAG_MODE ? "git " : ""}Last Modified`); + + // eleventyComputed data is assigned here rather than in 11tydata files; + // we have access to typings here, and can keep the latter fully static. + eleventyConfig.addGlobalData("eleventyComputed", { + // permalink determines output structure; see https://www.11ty.dev/docs/permalinks/ + permalink: ({ page, isUnderstanding }: GlobalData) => { + if (page.inputPath === "./index.html" && process.env.WCAG_MODE) return false; + if (isUnderstanding) { + // understanding-metadata.html exists in 2 places; top-level wins in XSLT process + if (/\/20\/understanding-metadata/.test(page.inputPath)) return false; + // Flatten pages into top-level directory, out of version subdirectories + return page.inputPath.replace(/\/2\d\//, "/"); + } + // Preserve existing structure: write to x.html instead of x/index.html + return page.inputPath; + }, + + nav: ({ page, isUnderstanding }: GlobalData) => + isUnderstanding ? understandingNav[page.fileSlug] : null, + testRules: ({ page, isTechniques, isUnderstanding }: GlobalData) => { + if (isTechniques) + return actRules.filter(({ wcagTechniques }) => wcagTechniques.includes(page.fileSlug)); + if (isUnderstanding) + return actRules.filter(({ successCriteria }) => successCriteria.includes(page.fileSlug)); + }, + + // Data for individual technique pages + technique: ({ page, isTechniques }: GlobalData) => + isTechniques ? flatTechniques[page.fileSlug] : null, + techniqueAssociations: ({ page, isTechniques }: GlobalData) => + isTechniques ? techniqueAssociations[page.fileSlug] : null, + + // Data for individual understanding pages + guideline: ({ page, isUnderstanding }: GlobalData) => + isUnderstanding ? flatGuidelines[page.fileSlug] : null, + }); + + // See https://www.11ty.dev/docs/copy/#emulate-passthrough-copy-during-serve + eleventyConfig.setServerPassthroughCopyBehavior("passthrough"); + + eleventyConfig.addPassthroughCopy("techniques/*.css"); + eleventyConfig.addPassthroughCopy("techniques/*/img/*"); + eleventyConfig.addPassthroughCopy({ + "css/base.css": "techniques/base.css", + "css/a11y-light.css": "techniques/a11y-light.css", + "script/highlight.min.js": "techniques/highlight.min.js", + }); + + eleventyConfig.addPassthroughCopy("understanding/*.css"); + eleventyConfig.addPassthroughCopy({ + "guidelines/relative-luminance.html": "understanding/relative-luminance.html", + "understanding/*/img/*": "understanding/img", // Intentionally flatten + }); + + eleventyConfig.addPassthroughCopy("working-examples/**"); + + eleventyConfig.on("eleventy.before", async ({ runMode }: EleventyEvent) => { + // Clear the _site folder before builds intended for the W3C site, + // to avoid inheriting dev-only files from previous runs + if (runMode === "build" && process.env.WCAG_MODE === "publication") await rimraf("_site"); + }); + + eleventyConfig.on("eleventy.after", async ({ dir }: EleventyEvent) => { + // addPassthroughCopy can only map each file once, + // but base.css needs to be copied to a 2nd destination + await copyFile(`${dir.input}/css/base.css`, `${dir.output}/understanding/base.css`); + }); + + eleventyConfig.setLibrary( + "liquid", + new CustomLiquid({ + // See https://www.11ty.dev/docs/languages/liquid/#liquid-options + root: ["_includes", "."], + jsTruthy: true, + strictFilters: true, + }) + ); + + // Filter that transforms a technique ID (or list of them) into links to their pages. + eleventyConfig.addFilter( + "linkTechniques", + function (this: EleventyContext, ids: string | string[]) { + const links = (Array.isArray(ids) ? ids : [ids]).map((id) => { + if (typeof id !== "string") throw new Error(`linkTechniques: invalid id ${id}`); + const technique = flatTechniques[id]; + if (!technique) { + console.warn( + `linkTechniques in ${this.page.inputPath}: ` + + `skipping unresolvable technique id ${id}` + ); + return; + } + + // Omit links to obsolete techniques, when not also linked from one + if ( + isTechniqueObsolete(technique) && + !isTechniqueObsolete(flatTechniques[this.page.fileSlug]) && + !isGuidelineObsolete(flatGuidelines[this.page.fileSlug]) + ) { + if (process.env.WCAG_VERBOSE) { + const since = technique.obsoleteSince!.split("").join("."); + console.warn( + `linkTechniques in ${this.page.inputPath}: ` + + `skipping obsolete technique ${id} (as of ${since})` + ); + } + return; + } + + // Support relative technique links from other techniques or from techniques/index.html, + // otherwise path-absolute when cross-linked from understanding/* + const urlBase = /^\/techniques\/.*\//.test(this.page.filePathStem) + ? "../" + : this.page.filePathStem.startsWith("/techniques") + ? "" + : baseUrls.techniques; + const label = `${id}: ${technique.truncatedTitle}`; + return `${label}`; + }); + return compact(links).join("\nand\n"); + } + ); + + // Filter that transforms a guideline or SC shortname (or list of them) into links to their pages. + eleventyConfig.addFilter( + "linkUnderstanding", + function (this: EleventyContext, ids: string | string[]) { + return (Array.isArray(ids) ? ids : [ids]) + .map((id) => { + if (typeof id !== "string") throw new Error("linkUnderstanding: invalid id passed"); + const guideline = flatGuidelines[id]; + if (!guideline) { + console.warn( + `linkUnderstanding in ${this.page.inputPath}: ` + + `skipping unresolvable guideline shortname ${id}` + ); + return; + } + + // Warn of links to obsolete SCs, when not also linked from one. + // This is intentionally not behind WCAG_VERBOSE, and does not remove, + // as links to Understanding docs are more likely to be in the middle + // of prose requiring manual adjustments + if ( + isGuidelineObsolete(guideline) && + !isGuidelineObsolete(flatGuidelines[this.page.fileSlug]) && + !isTechniqueObsolete(flatTechniques[this.page.fileSlug]) + ) { + console.warn( + `linkUnderstanding in ${this.page.inputPath}: ` + + `reference to obsolete ${guideline.type} ${id}` + ); + } + + const urlBase = this.page.filePathStem.startsWith("/understanding/") + ? "" + : baseUrls.understanding; + const label = `${guideline.num}: ${guideline.name}`; + return `${label}`; + }) + .join("\nand\n"); + } + ); + + // Renders a section box (used for About this Technique and Guideline / SC) + eleventyConfig.addPairedShortcode( + "sectionbox", + (content: string, id: string, title: string) => ` +
    +

    ${title}

    +
    ${content}
    +
    + ` + ); + + // Suppress default build output that prints every path, to make our own output clearly visible + eleventyConfig.setQuietMode(true); +} diff --git a/guidelines/act-mapping.json b/guidelines/act-mapping.json new file mode 100644 index 0000000000..d8790249d7 --- /dev/null +++ b/guidelines/act-mapping.json @@ -0,0 +1,1032 @@ +{ + "act-rules": [ + { + "title": "ARIA attribute is defined in WAI-ARIA", + "permalink": "/standards-guidelines/act/rules/5f99a7/", + "successCriteria": [ + "info-and-relationships", + "name-role-value" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": false + }, + { + "title": "ARIA state or property has valid value", + "permalink": "/standards-guidelines/act/rules/6a7281/", + "successCriteria": [ + "info-and-relationships", + "name-role-value" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": false + }, + { + "title": "Autocomplete attribute has valid value", + "permalink": "/standards-guidelines/act/rules/73f2c2/", + "successCriteria": [ + "identify-input-purpose" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": false + }, + { + "title": "Button has non-empty accessible name", + "permalink": "/standards-guidelines/act/rules/97a4e1/", + "successCriteria": [ + "name-role-value" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": false + }, + { + "title": "Element in sequential focus order has visible focus", + "permalink": "/standards-guidelines/act/rules/oj04fd/", + "successCriteria": [ + "focus-visible" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": false + }, + { + "title": "Element marked as decorative is not exposed", + "permalink": "/standards-guidelines/act/rules/46ca7f/", + "successCriteria": [], + "wcagTechniques": [], + "deprecated": false, + "proposed": false + }, + { + "title": "Element with aria-hidden has no content in sequential focus navigation", + "permalink": "/standards-guidelines/act/rules/6cfa84/", + "successCriteria": [ + "name-role-value" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": false + }, + { + "title": "Element with lang attribute has valid language tag", + "permalink": "/standards-guidelines/act/rules/de46e4/", + "successCriteria": [ + "language-of-parts" + ], + "wcagTechniques": [ + "H58" + ], + "deprecated": false, + "proposed": false + }, + { + "title": "Element with presentational children has no focusable content", + "permalink": "/standards-guidelines/act/rules/307n5z/", + "successCriteria": [ + "name-role-value" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": false + }, + { + "title": "Form field has non-empty accessible name", + "permalink": "/standards-guidelines/act/rules/e086e5/", + "successCriteria": [ + "name-role-value" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": false + }, + { + "title": "Headers attribute specified on a cell refers to cells in the same table element", + "permalink": "/standards-guidelines/act/rules/a25f45/", + "successCriteria": [ + "info-and-relationships" + ], + "wcagTechniques": [ + "H43" + ], + "deprecated": false, + "proposed": false + }, + { + "title": "HTML images contain no text", + "permalink": "/standards-guidelines/act/rules/0va7u6/", + "successCriteria": [ + "images-of-text", + "images-of-text-no-exception" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": false + }, + { + "title": "HTML page has lang attribute", + "permalink": "/standards-guidelines/act/rules/b5c3f8/", + "successCriteria": [ + "language-of-page" + ], + "wcagTechniques": [ + "H57" + ], + "deprecated": false, + "proposed": false + }, + { + "title": "HTML page has non-empty title", + "permalink": "/standards-guidelines/act/rules/2779a5/", + "successCriteria": [ + "page-titled" + ], + "wcagTechniques": [ + "G88", + "H25" + ], + "deprecated": false, + "proposed": false + }, + { + "title": "HTML page lang attribute has valid language tag", + "permalink": "/standards-guidelines/act/rules/bf051a/", + "successCriteria": [ + "language-of-page" + ], + "wcagTechniques": [ + "H57" + ], + "deprecated": false, + "proposed": false + }, + { + "title": "HTML page title is descriptive", + "permalink": "/standards-guidelines/act/rules/c4a8a4/", + "successCriteria": [ + "page-titled" + ], + "wcagTechniques": [ + "G88", + "H25" + ], + "deprecated": false, + "proposed": false + }, + { + "title": "Iframe with interactive elements is not excluded from tab-order", + "permalink": "/standards-guidelines/act/rules/akn7bn/", + "successCriteria": [ + "keyboard" + ], + "wcagTechniques": [ + "G202" + ], + "deprecated": false, + "proposed": false + }, + { + "title": "Image accessible name is descriptive", + "permalink": "/standards-guidelines/act/rules/qt1vmo/", + "successCriteria": [ + "non-text-content" + ], + "wcagTechniques": [ + "G94", + "G95" + ], + "deprecated": false, + "proposed": false + }, + { + "title": "Image button has non-empty accessible name", + "permalink": "/standards-guidelines/act/rules/59796f/", + "successCriteria": [ + "non-text-content", + "name-role-value" + ], + "wcagTechniques": [ + "G94", + "G95" + ], + "deprecated": false, + "proposed": false + }, + { + "title": "Image has non-empty accessible name", + "permalink": "/standards-guidelines/act/rules/23a2a8/", + "successCriteria": [ + "non-text-content" + ], + "wcagTechniques": [ + "G94", + "G95" + ], + "deprecated": false, + "proposed": false + }, + { + "title": "Important letter spacing in style attributes is wide enough", + "permalink": "/standards-guidelines/act/rules/24afc2/", + "successCriteria": [ + "text-spacing" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": false + }, + { + "title": "Important line height in style attributes is wide enough", + "permalink": "/standards-guidelines/act/rules/78fd32/", + "successCriteria": [ + "text-spacing" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": false + }, + { + "title": "Important word spacing in style attributes is wide enough", + "permalink": "/standards-guidelines/act/rules/9e45ec/", + "successCriteria": [ + "text-spacing" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": false + }, + { + "title": "Link has non-empty accessible name", + "permalink": "/standards-guidelines/act/rules/c487ae/", + "successCriteria": [ + "name-role-value", + "link-purpose-in-context", + "link-purpose-link-only", + "non-text-content" + ], + "wcagTechniques": [ + "G91" + ], + "deprecated": false, + "proposed": false + }, + { + "title": "Menuitem has non-empty accessible name", + "permalink": "/standards-guidelines/act/rules/m6b1q3/", + "successCriteria": [ + "name-role-value" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": false + }, + { + "title": "Meta element has no refresh delay", + "permalink": "/standards-guidelines/act/rules/bc659a/", + "successCriteria": [ + "timing-adjustable", + "interruptions", + "change-on-request" + ], + "wcagTechniques": [ + "G110", + "H76" + ], + "deprecated": false, + "proposed": false + }, + { + "title": "Meta element has no refresh delay (no exception)", + "permalink": "/standards-guidelines/act/rules/bisz58/", + "successCriteria": [ + "interruptions", + "change-on-request", + "timing-adjustable" + ], + "wcagTechniques": [ + "G110", + "H76" + ], + "deprecated": false, + "proposed": false + }, + { + "title": "Meta viewport allows for zoom", + "permalink": "/standards-guidelines/act/rules/b4f0c3/", + "successCriteria": [ + "resize-text", + "reflow" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": false + }, + { + "title": "Object element rendering non-text content has non-empty accessible name", + "permalink": "/standards-guidelines/act/rules/8fc3b6/", + "successCriteria": [ + "non-text-content" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": false + }, + { + "title": "Role attribute has valid value", + "permalink": "/standards-guidelines/act/rules/674b10/", + "successCriteria": [ + "info-and-relationships", + "name-role-value" + ], + "wcagTechniques": [ + "ARIA4", + "G108" + ], + "deprecated": false, + "proposed": false + }, + { + "title": "Scrollable content can be reached with sequential focus navigation", + "permalink": "/standards-guidelines/act/rules/0ssw9k/", + "successCriteria": [ + "keyboard", + "keyboard-no-exception" + ], + "wcagTechniques": [ + "G202" + ], + "deprecated": false, + "proposed": false + }, + { + "title": "SVG element with explicit role has non-empty accessible name", + "permalink": "/standards-guidelines/act/rules/7d6734/", + "successCriteria": [ + "non-text-content" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": false + }, + { + "title": "Text has enhanced contrast", + "permalink": "/standards-guidelines/act/rules/09o5cg/", + "successCriteria": [ + "contrast-enhanced", + "contrast-minimum" + ], + "wcagTechniques": [ + "G17", + "G18" + ], + "deprecated": false, + "proposed": false + }, + { + "title": "Text has minimum contrast", + "permalink": "/standards-guidelines/act/rules/afw4f7/", + "successCriteria": [ + "contrast-minimum", + "contrast-enhanced" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": false + }, + { + "title": "ARIA required context role", + "permalink": "/standards-guidelines/act/rules/ff89c9/proposed/", + "successCriteria": [ + "info-and-relationships" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "ARIA required ID references exist", + "permalink": "/standards-guidelines/act/rules/in6db8/proposed/", + "successCriteria": [ + "info-and-relationships", + "name-role-value" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "ARIA required owned elements", + "permalink": "/standards-guidelines/act/rules/bc4a75/proposed/", + "successCriteria": [ + "info-and-relationships" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "ARIA state or property is permitted", + "permalink": "/standards-guidelines/act/rules/5c01ea/proposed/", + "successCriteria": [ + "info-and-relationships", + "name-role-value" + ], + "wcagTechniques": [ + "ARIA5" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Attribute is not duplicated", + "permalink": "/standards-guidelines/act/rules/e6952f/proposed/", + "successCriteria": [ + "parsing" + ], + "wcagTechniques": [ + "H94" + ], + "deprecated": true, + "proposed": true + }, + { + "title": "Audio and visuals of video element have transcript", + "permalink": "/standards-guidelines/act/rules/1a02b0/proposed/", + "successCriteria": [ + "media-alternative-prerecorded" + ], + "wcagTechniques": [ + "G69" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Audio element content has text alternative", + "permalink": "/standards-guidelines/act/rules/e7aa44/proposed/", + "successCriteria": [ + "audio-only-and-video-only-prerecorded" + ], + "wcagTechniques": [ + "G158" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Audio element content has transcript", + "permalink": "/standards-guidelines/act/rules/2eb176/proposed/", + "successCriteria": [], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Audio element content is media alternative for text", + "permalink": "/standards-guidelines/act/rules/afb423/proposed/", + "successCriteria": [], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Audio or video element avoids automatically playing audio", + "permalink": "/standards-guidelines/act/rules/80f0bf/proposed/", + "successCriteria": [ + "audio-control" + ], + "wcagTechniques": [ + "G60", + "G170", + "G171" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Audio or video element that plays automatically has a control mechanism", + "permalink": "/standards-guidelines/act/rules/4c31df/proposed/", + "successCriteria": [], + "wcagTechniques": [ + "G170" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Audio or video element that plays automatically has no audio that lasts more than 3 seconds", + "permalink": "/standards-guidelines/act/rules/aaa1bf/proposed/", + "successCriteria": [], + "wcagTechniques": [ + "G60" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Block of repeated content is collapsible", + "permalink": "/standards-guidelines/act/rules/3e12e1/proposed/", + "successCriteria": [], + "wcagTechniques": [ + "SCR28" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Bypass Blocks of Repeated Content", + "permalink": "/standards-guidelines/act/rules/cf77f2/proposed/", + "successCriteria": [ + "bypass-blocks" + ], + "wcagTechniques": [ + "G1", + "G123", + "G124", + "H69", + "SCR28" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Content has alternative for visual reference", + "permalink": "/standards-guidelines/act/rules/9bd38c/proposed/", + "successCriteria": [ + "sensory-characteristics" + ], + "wcagTechniques": [ + "G96" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Device motion based changes to the content can also be created from the user interface", + "permalink": "/standards-guidelines/act/rules/7677a9/proposed/", + "successCriteria": [ + "motion-actuation" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Device motion based changes to the content can be disabled", + "permalink": "/standards-guidelines/act/rules/c249d5/proposed/", + "successCriteria": [ + "motion-actuation" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Document has a landmark with non-repeated content", + "permalink": "/standards-guidelines/act/rules/b40fd1/proposed/", + "successCriteria": [], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Document has an instrument to move focus to non-repeated content", + "permalink": "/standards-guidelines/act/rules/ye5d6e/proposed/", + "successCriteria": [], + "wcagTechniques": [ + "G1", + "G123", + "G124" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Document has heading for non-repeated content", + "permalink": "/standards-guidelines/act/rules/047fe0/proposed/", + "successCriteria": [], + "wcagTechniques": [ + "H69" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Element with role attribute has required states and properties", + "permalink": "/standards-guidelines/act/rules/4e8ab6/proposed/", + "successCriteria": [ + "info-and-relationships", + "name-role-value" + ], + "wcagTechniques": [ + "ARIA5" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Error message describes invalid form field value", + "permalink": "/standards-guidelines/act/rules/36b590/proposed/", + "successCriteria": [ + "error-identification" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Focusable element has no keyboard trap", + "permalink": "/standards-guidelines/act/rules/80af7b/proposed/", + "successCriteria": [ + "no-keyboard-trap" + ], + "wcagTechniques": [ + "G21" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Focusable element has no keyboard trap via non-standard navigation", + "permalink": "/standards-guidelines/act/rules/ebe86a/proposed/", + "successCriteria": [], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Focusable element has no keyboard trap via standard navigation", + "permalink": "/standards-guidelines/act/rules/a1b64e/proposed/", + "successCriteria": [], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Form field label is descriptive", + "permalink": "/standards-guidelines/act/rules/cc0f0a/proposed/", + "successCriteria": [ + "headings-and-labels" + ], + "wcagTechniques": [ + "G131" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Heading has non-empty accessible name", + "permalink": "/standards-guidelines/act/rules/ffd0e9/proposed/", + "successCriteria": [], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Heading is descriptive", + "permalink": "/standards-guidelines/act/rules/b49b2e/proposed/", + "successCriteria": [ + "headings-and-labels" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "HTML element language subtag matches language", + "permalink": "/standards-guidelines/act/rules/off6ek/proposed/", + "successCriteria": [ + "language-of-parts" + ], + "wcagTechniques": [ + "H58" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "HTML page lang and xml:lang attributes have matching values", + "permalink": "/standards-guidelines/act/rules/5b7ae0/proposed/", + "successCriteria": [ + "language-of-page" + ], + "wcagTechniques": [], + "deprecated": true, + "proposed": true + }, + { + "title": "HTML page language subtag matches default language", + "permalink": "/standards-guidelines/act/rules/ucwvc8/proposed/", + "successCriteria": [ + "language-of-page" + ], + "wcagTechniques": [ + "H57" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Id attribute value is unique", + "permalink": "/standards-guidelines/act/rules/3ea0c8/proposed/", + "successCriteria": [ + "parsing" + ], + "wcagTechniques": [ + "H93" + ], + "deprecated": true, + "proposed": true + }, + { + "title": "Iframe element has non-empty accessible name", + "permalink": "/standards-guidelines/act/rules/cae760/proposed/", + "successCriteria": [ + "name-role-value" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Iframe elements with identical accessible names have equivalent purpose", + "permalink": "/standards-guidelines/act/rules/4b1c6c/proposed/", + "successCriteria": [ + "name-role-value" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Image filename is accessible name for image", + "permalink": "/standards-guidelines/act/rules/9eb3f6/proposed/", + "successCriteria": [ + "non-text-content" + ], + "wcagTechniques": [ + "G94", + "G95" + ], + "deprecated": true, + "proposed": true + }, + { + "title": "Image not in the accessibility tree is decorative", + "permalink": "/standards-guidelines/act/rules/e88epe/proposed/", + "successCriteria": [ + "non-text-content" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Link in context is descriptive", + "permalink": "/standards-guidelines/act/rules/5effbb/proposed/", + "successCriteria": [ + "link-purpose-in-context", + "link-purpose-link-only" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Link is descriptive", + "permalink": "/standards-guidelines/act/rules/aizyf1/proposed/", + "successCriteria": [ + "link-purpose-link-only" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Links with identical accessible names and same context serve equivalent purpose", + "permalink": "/standards-guidelines/act/rules/fd3a94/proposed/", + "successCriteria": [ + "link-purpose-in-context", + "link-purpose-link-only" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Links with identical accessible names have equivalent purpose", + "permalink": "/standards-guidelines/act/rules/b20e66/proposed/", + "successCriteria": [ + "link-purpose-link-only" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "No keyboard shortcut uses only printable characters", + "permalink": "/standards-guidelines/act/rules/ffbc54/proposed/", + "successCriteria": [ + "character-key-shortcuts" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Orientation of the page is not restricted using CSS transforms", + "permalink": "/standards-guidelines/act/rules/b33eff/proposed/", + "successCriteria": [ + "orientation" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Table header cell has assigned cells", + "permalink": "/standards-guidelines/act/rules/d0f69e/proposed/", + "successCriteria": [ + "info-and-relationships" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Text content that changes automatically can be paused, stopped or hidden", + "permalink": "/standards-guidelines/act/rules/efbfc7/proposed/", + "successCriteria": [ + "pause-stop-hide" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Video element auditory content has accessible alternative", + "permalink": "/standards-guidelines/act/rules/eac66b/proposed/", + "successCriteria": [ + "captions-prerecorded" + ], + "wcagTechniques": [ + "G87", + "G93", + "H95" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Video element auditory content has captions", + "permalink": "/standards-guidelines/act/rules/f51b46/proposed/", + "successCriteria": [ + "audio-only-and-video-only-prerecorded" + ], + "wcagTechniques": [ + "G87", + "G93", + "H95" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Video element content is media alternative for text", + "permalink": "/standards-guidelines/act/rules/ab4d13/proposed/", + "successCriteria": [], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Video element visual content has accessible alternative", + "permalink": "/standards-guidelines/act/rules/c5a4ea/proposed/", + "successCriteria": [ + "audio-description-or-media-alternative-prerecorded", + "audio-description-prerecorded", + "media-alternative-prerecorded" + ], + "wcagTechniques": [ + "G8", + "G69", + "G78", + "G173" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Video element visual content has audio description", + "permalink": "/standards-guidelines/act/rules/1ea59c/proposed/", + "successCriteria": [], + "wcagTechniques": [ + "G8", + "G78", + "G173" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Video element visual content has description track", + "permalink": "/standards-guidelines/act/rules/f196ce/proposed/", + "successCriteria": [], + "wcagTechniques": [ + "G78", + "H96" + ], + "deprecated": true, + "proposed": true + }, + { + "title": "Video element visual content has strict accessible alternative", + "permalink": "/standards-guidelines/act/rules/1ec09b/proposed/", + "successCriteria": [ + "audio-description-prerecorded" + ], + "wcagTechniques": [ + "G8", + "G78", + "G173" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Video element visual-only content has accessible alternative", + "permalink": "/standards-guidelines/act/rules/c3232f/proposed/", + "successCriteria": [ + "audio-only-and-video-only-prerecorded" + ], + "wcagTechniques": [ + "G159", + "G166" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Video element visual-only content has audio track alternative", + "permalink": "/standards-guidelines/act/rules/d7ba54/proposed/", + "successCriteria": [], + "wcagTechniques": [ + "G166" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Video element visual-only content has description track", + "permalink": "/standards-guidelines/act/rules/ac7dc6/proposed/", + "successCriteria": [], + "wcagTechniques": [ + "H96" + ], + "deprecated": true, + "proposed": true + }, + { + "title": "Video element visual-only content has transcript", + "permalink": "/standards-guidelines/act/rules/ee13b5/proposed/", + "successCriteria": [], + "wcagTechniques": [ + "G159" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Video element visual-only content is media alternative for text", + "permalink": "/standards-guidelines/act/rules/fd26cf/proposed/", + "successCriteria": [], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + }, + { + "title": "Visible label is part of accessible name", + "permalink": "/standards-guidelines/act/rules/2ee8b8/proposed/", + "successCriteria": [ + "label-in-name" + ], + "wcagTechniques": [ + "G208" + ], + "deprecated": false, + "proposed": true + }, + { + "title": "Zoomed text node is not clipped with CSS overflow", + "permalink": "/standards-guidelines/act/rules/59br37/proposed/", + "successCriteria": [ + "resize-text" + ], + "wcagTechniques": [], + "deprecated": false, + "proposed": true + } + ] +} \ No newline at end of file diff --git a/guidelines/guidelines.css b/guidelines/guidelines.css index 7a833bd546..8a8864433a 100644 --- a/guidelines/guidelines.css +++ b/guidelines/guidelines.css @@ -40,6 +40,11 @@ dd.new, dd.proposed, dd.changed { display: block; width: 25%; hyphens: none; + padding: 1em; + display: flex; + flex-direction: column; + gap: .5em; + margin-left: 2em; } .sc dt { display: list-item; @@ -56,8 +61,7 @@ dd.new, dd.proposed, dd.changed { div.note-title, div.ednote-title { color: #008400 } -/* make links in W3C masthead bold, since we can't make them underline */ +a.internalDFN[title]:hover, .internalDFN[title]:active, a.internalDFN[title]:focus { + cursor: help; +} span.screenreader {position: absolute; left: -10000px} -.head p:not(.copyright) > a, .head > a:first-child { - font-weight: bold; -} \ No newline at end of file diff --git a/guidelines/index.html b/guidelines/index.html index a2d19623d2..8402db4640 100644 --- a/guidelines/index.html +++ b/guidelines/index.html @@ -1,15 +1,15 @@ - + Web Content Accessibility Guidelines (WCAG) 2.2 - + - - + +
    @@ -18,12 +18,16 @@

    WCAG 2.2 extends Web Content Accessibility Guidelines 2.1 [[WCAG21]], which was published as a W3C Recommendation June 2018. Content that conforms to WCAG 2.2 also conforms to WCAG 2.0 and WCAG 2.1. The WG intends that for policies requiring conformance to WCAG 2.0 or WCAG 2.1, WCAG 2.2 can provide an alternate means of conformance. The publication of WCAG 2.2 does not deprecate or supersede WCAG 2.0 or WCAG 2.1. While WCAG 2.0 and WCAG 2.1 remain W3C Recommendations, the W3C advises the use of WCAG 2.2 to maximize future applicability of accessibility efforts. The W3C also encourages use of the most current version of WCAG when developing or updating Web accessibility policies.

    -

    This is an Editors' Draft of Web Content Accessibility Guidelines (WCAG) 2.2. WCAG 2.1 is a W3C Recommendation.

    -

    To comment, file an issue in the W3C WCAG GitHub repository. Although the proposed Success Criteria in this document reference issues tracking discussion, the Working Group requests that public comments be filed as new issues, one issue per discrete comment. It is free to create a GitHub account to file issues. If filing issues in GitHub is not feasible, send email to public-agwg-comments@w3.org (comment archive).

    +

    To comment, file an issue in the + W3C WCAG GitHub repository. + Although the proposed Success Criteria in this document reference issues tracking + discussion, the Working Group requests that public comments be filed as new issues, + one issue per discrete comment. It is free to create a GitHub account to file issues. + If filing issues in GitHub is not feasible, send email to public-agwg-comments@w3.org (comment archive).

    Introduction

    -
    +

    Background on WCAG 2

    Web Content Accessibility Guidelines (WCAG) 2.2 defines how to make Web content more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees, and combinations of disability. These guidelines also make Web content more usable by older individuals with changing abilities due to aging and often improve usability for users in general.

    WCAG 2.2 is developed through the W3C process in cooperation with individuals and organizations around the world, with a goal of providing a shared standard for Web content accessibility that meets the needs of individuals, organizations, and governments internationally. WCAG 2.2 builds on WCAG 2.0 [[WCAG20]] and WCAG 2.1 [[WCAG21]], which in turn built on WCAG 1.0 [[WAI-WEBCONTENT]] and is designed to apply broadly to different Web technologies now and in the future, and to be testable with a combination of automated testing and human evaluation. For an introduction to WCAG, see the Web Content Accessibility Guidelines (WCAG) Overview.

    @@ -38,82 +42,84 @@

    Background on WCAG 2

    Where this document refers to WCAG 2 it is intended to mean any and all versions of WCAG that start with 2.

    -
    +

    WCAG 2 Layers of Guidance

    The individuals and organizations that use WCAG vary widely and include Web designers and developers, policy makers, purchasing agents, teachers, and students. In order to meet the varying needs of this audience, several layers of guidance are provided including overall principles, general guidelines, testable success criteria and a rich collection of sufficient techniques, advisory techniques, and documented common failures with examples, resource links and code.

    • -

      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.

    • -

      Success Criteria - For each guideline, testable success criteria are provided to allow WCAG 2.2 to be used where requirements and conformance testing are necessary such as in design specification, purchasing, regulation, and contractual agreements. In order to meet the needs of different groups and different situations, three levels of conformance are defined: A (lowest), AA, and AAA (highest). Additional information on WCAG levels can be found in Understanding Levels of Conformance.

      +

      Success Criteria - For each guideline, testable success criteria are provided to allow WCAG 2.2 to be used where requirements and conformance testing are necessary such as in design specification, purchasing, regulation, and contractual agreements. In order to meet the needs of different groups and different situations, three levels of conformance are defined: A (lowest), AA, and AAA (highest). Additional information on WCAG levels can be found in Understanding Levels of Conformance.

    • -

      Sufficient and Advisory Techniques - For each of the guidelines and success criteria in the WCAG 2.2 document itself, the working group has also documented a wide variety of techniques. The techniques are informative and fall into two categories: those that are sufficient for meeting the success criteria and those that are advisory. The advisory techniques go beyond what is required by the individual success criteria and allow authors to better address the guidelines. Some advisory techniques address accessibility barriers that are not covered by the testable success criteria. Where common failures are known, these are also documented. See also Sufficient and Advisory Techniques in Understanding WCAG 2.2.

      +

      Sufficient and Advisory Techniques - For each of the guidelines and success criteria in the WCAG 2.2 document itself, the working group has also documented a wide variety of techniques. The techniques are informative and fall into two categories: those that are sufficient for meeting the success criteria and those that are advisory. The advisory techniques go beyond what is required by the individual success criteria and allow authors to better address the guidelines. Some advisory techniques address accessibility barriers that are not covered by the testable success criteria. Where common failures are known, these are also documented. See also Sufficient and Advisory Techniques in Understanding WCAG 2.2.

    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, as well as to seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community. Metadata may assist users in finding content most suitable for their needs.

    +

    Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive, language, and learning areas. Authors are encouraged to consider the full range of techniques, including the advisory techniques, Making Content Usable for People with Cognitive and Learning Disabilities, as well as to seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community. Metadata may assist users in finding content most suitable for their needs.

    -
    +

    WCAG 2.2 Supporting Documents

    The WCAG 2.2 document is designed to meet the needs of those who need a stable, referenceable technical standard. Other documents, called supporting documents, are based on the WCAG 2.2 document and address other important purposes, including the ability to be updated to describe how WCAG would be applied with new technologies. Supporting documents include:

    1. -

      How to Meet WCAG 2.2 - A customizable quick reference to WCAG 2.2 that includes all of the guidelines, success criteria, and techniques for authors to use as they are developing and evaluating Web content. This includes content from WCAG 2.0, 2.1 2.2 and can be filtered in many ways to help authors focus on relevant content.

      +

      How to Meet WCAG 2.2 - A customizable quick reference to WCAG 2.2 that includes all of the guidelines, success criteria, and techniques for authors to use as they are developing and evaluating Web content. This includes content from WCAG 2.0, 2.1 2.2 and can be filtered in many ways to help authors focus on relevant content.

    2. -

      Understanding WCAG 2.2 - A guide to understanding and implementing WCAG 2.2. There is a short "Understanding" document for each guideline and success criterion in WCAG 2.2 as well as key topics.

      +

      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.

    3. -

      Techniques for WCAG 2.2 - A collection of techniques and common failures, each in a separate document that includes a description, examples, code and tests.

      +

      Techniques for WCAG 2.2 - A collection of techniques and common failures, each in a separate document that includes a description, examples, code and tests.

    4. -

      The WCAG Documents - A diagram and description of how the technical documents are related and linked.

      +

      The WCAG 2 Documents - A brief introduction to the WCAG 2 supporting documents and supplemental guidance.

    5. +
    6. 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.

    -
    +

    Requirements for WCAG 2.2

    WCAG 2.2 meets a set of requirements for WCAG 2.2 which, in turn, inherit requirements from previous WCAG 2 versions. Requirements structure the overall framework of guidelines and ensure backwards compatibility. The Working Group also used a less formal set of acceptance criteria for success criteria, to help ensure success criteria are similar in style and quality to those in WCAG 2.0. These requirements constrained what could be included in WCAG 2.2. This constraint was important to preserve its nature as a dot-release of WCAG 2.

    -
    +

    Comparison with WCAG 2.1

    WCAG 2.2 was initiated with the goal to continue the work of WCAG 2.1: Improving accessibility guidance for three major groups: users with cognitive or learning disabilities, users with low vision, and users with disabilities on mobile devices. Many ways to meet these needs were proposed and evaluated, and a set of these were refined by the Working Group. Structural requirements inherited from WCAG 2.0, clarity and impact of proposals, and timeline led to the final set of success criteria included in this version. The Working Group considers that WCAG 2.2 incrementally advances web content accessibility guidance for all these areas, but underscores that not all user needs are met by these guidelines.

    -

    WCAG 2.2 builds on and is backwards compatible with WCAG 2.1, meaning web pages that conform to WCAG 2.2 also conform to WCAG 2.1, which would also conform to WCAG 2.0. Authors that are required by policy to conform with WCAG 2.0 or 2.1 will be able to update content to WCAG 2.2 without losing conformance with previous versions. Authors following more than one version of the guidelines should be aware of the following differences:

    -
    +

    WCAG 2.2 builds on and is backwards compatible with WCAG 2.1, meaning web pages that conform to WCAG 2.2 are at least as accessible as pages that conform to WCAG 2.1. Requirements have been added that build on 2.1 and 2.0. WCAG 2.2 has removed one success criterion, 4.1.1 Parsing. Authors that are required by policy to conform with WCAG 2.0 or 2.1 will be able to update content to WCAG 2.2, but may need to continue to test and report 4.1.1. Authors following more than one version of the guidelines should be aware of the following additions.

    +

    New Features in WCAG 2.2

    WCAG 2.2 extends WCAG 2.1 by adding new success criteria, definitions to support them, and guidelines to organize the additions. This additive approach helps to make it clear that sites which conform to WCAG 2.2 also conform to WCAG 2.1. The Accessibility Guidelines Working Group recommends that sites adopt WCAG 2.2 as their new conformance target, even if formal obligations mention previous versions, to provide improved accessibility and to anticipate future policy changes.

    -

    The following Success Criteria are new in WCAG 2.2:

    -
    -
    +

    Numbering in WCAG 2.2

    -

    In order to avoid confusion for implementers for whom backwards compatibility to WCAG 2 versions is important, new success criteria in WCAG 2.2 have been appended to the end of the set of success criteria within their guideline. This avoids the need to change the section number of success criteria from WCAG 2, which would be caused by inserting new success criteria between existing success criteria in the guideline, but it means success criteria in each guideline are no longer grouped by conformance level. The order of success criteria within each guideline does not imply information about conformance level; only the conformance level indicator (A / AA / AAA) on the success criterion itself indicates this. The WCAG 2.2 Quick Reference will provide a way to view success criteria grouped by conformance level, along with many other filter and sort options.

    +

    In order to avoid confusion for implementers for whom backwards compatibility to WCAG 2 versions is important, new success criteria in WCAG 2.2 have been appended to the end of the set of success criteria within their guideline. This avoids the need to change the section number of success criteria from WCAG 2, which would be caused by inserting new success criteria between existing success criteria in the guideline, but it means success criteria in each guideline are no longer grouped by conformance level. The order of success criteria within each guideline does not imply information about conformance level; only the conformance level indicator (A / AA / AAA) on the success criterion itself indicates this. The WCAG 2.2 Quick Reference will provide a way to view success criteria grouped by conformance level, along with many other filter and sort options.

    -
    +

    Conformance to WCAG 2.2

    WCAG 2.2 uses the same conformance model as WCAG 2.0. It is intended that sites that conform to WCAG 2.2 also conform to WCAG 2.0 and WCAG 2.1, which means they meet the requirements of any policies that reference WCAG 2.0 or WCAG 2.1, while also better meeting the needs of users on the current Web.

    -
    +

    Later Versions of Accessibility Guidelines

    In parallel with WCAG 2.2, the Accessibility Guidelines Working Group is developing another major version of accessibility guidelines. The result of this work is expected to be a more substantial restructuring of web accessibility guidance than would be realistic for dot-releases of WCAG 2. The work follows a research-focused, user-centered design methodology to produce the most effective and flexible outcome, including the roles of content authoring, user agent support, and authoring tool support. This is a multi-year effort, so WCAG 2.2 is needed as an interim measure to provide updated web accessibility guidance to reflect changes on the web since the publication of WCAG 2.0. The Working Group might also develop additional interim versions, continuing with WCAG 2.2, on a similar short timeline to provide additional support while the major version is completed.

    @@ -122,14 +128,14 @@

    Later Versions of Accessibility Guidelines

    Perceivable

    Information and user interface components must be presentable to users in ways they can perceive.

    -
    +

    Text Alternatives

    Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.

    -
    +

    Time-based Media

    Provide alternatives for time-based media.

    @@ -152,7 +158,7 @@

    Time-based Media

    -
    +

    Adaptable

    Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

    @@ -170,7 +176,7 @@

    Adaptable

    -
    +

    Distinguishable

    Make it easier for users to see and hear content including separating foreground from background.

    @@ -207,7 +213,7 @@

    Distinguishable

    Operable

    User interface components and navigation must be operable.

    -
    +

    Keyboard Accessible

    Make all functionality available from a keyboard.

    @@ -221,7 +227,7 @@

    Keyboard Accessible

    -
    +

    Enough Time

    Provide users enough time to read and use content.

    @@ -239,7 +245,7 @@

    Enough Time

    -
    +

    Seizures and Physical Reactions

    Do not design content in a way that is known to cause seizures or physical reactions.

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

    Seizures and Physical Reactions

    -
    + -
    +

    Input Modalities

    Make it easier for users to operate functionality through various inputs beyond keyboard.

    @@ -295,13 +301,13 @@

    Input Modalities

    -
    +
    -
    +
    -
    +
    @@ -310,7 +316,7 @@

    Input Modalities

    Understandable

    Information and the operation of the user interface must be understandable.

    -
    +

    Readable

    Make text content readable and understandable.

    @@ -328,7 +334,7 @@

    Readable

    -
    +

    Predictable

    Make Web pages appear and operate in predictable ways.

    @@ -342,13 +348,11 @@

    Predictable

    -
    - -
    +
    -
    +

    Input Assistance

    Help users avoid and correct mistakes.

    @@ -363,10 +367,12 @@

    Input Assistance

    - -
    + +
    + +
    @@ -375,7 +381,7 @@

    Input Assistance

    Robust

    Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.

    -
    +

    Compatible

    Maximize compatibility with current and future user agents, including assistive technologies.

    @@ -391,9 +397,9 @@

    Compatible

    Conformance

    -

    This section lists requirements for conformance to WCAG 2.2. It also gives information about how to make conformance claims, which are optional. Finally, it describes what it means to be accessibility supported, since only accessibility-supported ways of using technologies can be relied upon for conformance. Understanding Conformance includes further explanation of the accessibility-supported concept.

    +

    This section lists requirements for conformance to WCAG 2.2. It also gives information about how to make conformance claims, which are optional. Finally, it describes what it means to be accessibility supported, since only accessibility-supported ways of using technologies can be relied upon for conformance. Understanding Conformance includes further explanation of the accessibility-supported concept.

    -
    +

    Interpreting Normative Requirements

    The main content of WCAG 2.2 is normative and defines requirements that impact conformance claims. Introductory material, appendices, sections marked as "non-normative", diagrams, examples, and notes are informative (non-normative). Non-normative material provides advisory information to help interpret the guidelines but does not create requirements that impact a conformance claim.

    @@ -409,10 +415,10 @@

    Conformance Requirements

    Conformance Level

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

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

    Although conformance can only be achieved at the stated levels, authors are encouraged to report (in their claim) any progress toward meeting success criteria from all levels beyond the achieved level of conformance.

    It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content.

    @@ -431,14 +437,14 @@

    Full pages

    Complete processes

    When a Web page is one of a series of Web pages presenting a process (i.e., a sequence of steps that need to be completed in order to accomplish an activity), all Web pages in the process conform at the specified level or better. (Conformance is not possible at a particular level if any page in the process does not conform at that level or better.)

    -

    An online store has a series of pages that are used to select and purchase products. All pages in the series from start to finish (checkout) conform in order for any page that is part of the process to conform.

    +

    Only Accessibility-Supported Ways of Using Technologies

    -

    Only accessibility-supported ways of using technologies are relied upon to satisfy the success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported. (See Understanding accessibility support.)

    +

    Only accessibility-supported ways of using technologies are relied upon to satisfy the success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported. (See Understanding accessibility support.)

    @@ -460,7 +466,7 @@

    Non-Interference

    If a page cannot conform (for example, a conformance test page or an example page), it cannot be included in the scope of conformance or in a conformance claim.

    -

    For more information, including examples, see Understanding Conformance Requirements.

    +

    For more information, including examples, see Understanding Conformance Requirements.

    @@ -501,15 +507,15 @@

    Optional Components of a Conformance Claim

  • A machine-readable metadata version of the conformance claim.
  • -

    Refer to Understanding Conformance Claims for more information and example conformance claims.

    -

    Refer to Understanding Metadata for more information about the use of metadata in conformance claims.

    +

    Refer to Understanding Conformance Claims for more information and example conformance claims.

    +

    Refer to Understanding Metadata for more information about the use of metadata in conformance claims.

    Statement of Partial Conformance - Third Party Content

    -

    Sometimes, Web pages are created that will later have additional content added to them. For example, an email program, a blog, an article that allows users to add comments, or applications supporting user-contributed content. Another example would be a page, such as a portal or news site, composed of content aggregated from multiple contributors, or sites that automatically insert content from other sources over time, such as when advertisements are inserted dynamically.

    +

    Web pages that will later have additional content added can use a 'statement of partial conformance'. For example, an email program, a blog, an article that allows users to add comments, or applications supporting user-contributed content. Another example would be a page, such as a portal or news site, composed of content aggregated from multiple contributors, or sites that automatically insert content from other sources over time, such as when advertisements are inserted dynamically.

    In these cases, it is not possible to know at the time of original posting what the uncontrolled content of the pages will be. It is important to note that the uncontrolled content can affect the accessibility of the controlled content as well. Two options are available:

    1. @@ -531,6 +537,36 @@

      Statement of Partial Conformance - Language

      A "statement of partial conformance due to language" may be made when the page does not conform, but would conform if accessibility support existed for (all of) the language(s) used on the page. The form of that statement would be, "This page does not conform, but would conform to WCAG 2.2 at level X if accessibility support existed for the following language(s):"

    +
    +

    Privacy Considerations

    +

    Success Criteria within this specification which the Working Group has identified possible implications for privacy, either by providing protections for end users or which are important for web site providers to take in to consideration when implementing features designed to protect user privacy, are listed below. This list reflects the current understanding of the Working Group but other Success Criteria may have privacy implications that the Working Group is not aware of at the time of publishing.

    +

    Success Criteria within this specification that may relate to privacy are:

    + + +
    + +
    +

    Security Considerations

    +

    Success Criteria within this specification which the Working Group has identified possible implications for security, either by providing protections for end users or which are important for web site providers to take in to consideration when implementing features designed to protect user security, are listed below. This list reflects the current understanding of the Working Group but other Success Criteria may have security implications that the Working Group is not aware of at the time of publishing.

    +

    Success Criteria within this specification that may relate to security are:

    + +
    +

    Glossary

    @@ -586,15 +622,15 @@

    Glossary

    +
    +
    - -
    -
    +
    @@ -634,6 +670,8 @@

    Glossary

    +
    +
    @@ -646,6 +684,8 @@

    Glossary

    +
    +
    @@ -689,7 +729,7 @@

    Glossary

    - +
    @@ -744,14 +784,23 @@

    Glossary

    Change Log

    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.

    -

    The full commit history to WCAG 2.2 is available.

    +

    The full commit history to WCAG 2.2 is available.

    diff --git a/guidelines/input-purposes.html b/guidelines/input-purposes.html index 17a622dc32..b83e94c842 100644 --- a/guidelines/input-purposes.html +++ b/guidelines/input-purposes.html @@ -2,7 +2,7 @@

    Input Purposes for User Interface Components

    This section contains a listing of common user interface component input purposes. The terms below are not keywords that must be used, but instead represent purposes that must be captured in the taxonomy adopted by a webpage. Where applicable, authors mark up controls with the chosen taxonomy to indicate the semantic purpose. This provides the potential for user agents and assistive technologies to apply personalized presentations that can enable more people to understand and use the content.

    -

    The list of input type purposes is based on the control purposes defined in the HTML 5.2 Autofill field section, but it is important to understand that a different technology may have some or all of the same concepts defined in its specification and only the concepts that are mapped to the meanings below are required.

    +

    The list of input type purposes is based on the control purposes defined in the HTML specification's Autofill section, but it is important to understand that a different technology may have some or all of the same concepts defined in its specification and only the concepts that are mapped to the meanings below are required.

    The following input control purposes are intended to relate to the user of the content and pertain only to information related to that individual.

    @@ -47,7 +47,7 @@

    Input Purposes for User Interface Components

  • bday-day - Day component of birthday
  • bday-month - Month component of birthday
  • bday-year - Year component of birthday
  • -
  • sex - Gender identity (e.g., Female, Fa’afafine)
  • +
  • sex - Gender identity (e.g., Female, Fa’afafine)
  • url - Home page or other Web page corresponding to the company, person, address, or contact information in the other fields associated with this field
  • photo - Photograph, icon, or other image corresponding to the company, person, address, or contact information in the other fields associated with this field
  • tel - Full telephone number, including country code
  • diff --git a/guidelines/relative-luminance.html b/guidelines/relative-luminance.html new file mode 100644 index 0000000000..ed65eb01df --- /dev/null +++ b/guidelines/relative-luminance.html @@ -0,0 +1,361 @@ + + + + + + MathML version of the relative luminance definition + + +

    MathML version of the relative luminance definition

    +

    The following is a MathML version of the WCAG 2.2 definition of relative luminance. Refer to MathML Software - Browsers for information about browsers and plugins that support MathML which you may need in order to correctly display the information on this page.

    +
    +
    relative luminance
    +

    the relative brightness of any point in a colorspace, normalized to 0 for darkest black and 1 for lightest white

    +
    Note
    +

    For the sRGB colorspace, the relative luminance of a color is defined as + + L + = + 0.2126 + × + R + + + 0.7152 + × + G + + + 0.0722 + × + B + + where R, G and B are defined as:

    +
      +
    • +

      If + + + R + + s + R + G + B + + + + 0.04045 + + then + + R + = + + + R + + s + R + G + B + + + 12.92 + + + else + + R + = + + + ( + + + + R + + s + R + G + B + + + + + 0.055 + + 1.055 + + ) + + 2.4 + + + +

      +
    • +
    • +

      If + + + G + + s + R + G + B + + + + 0.04045 + + then + + G + = + + + G + + s + R + G + B + + + 12.92 + + + else + + G + = + + + ( + + + + G + + s + R + G + B + + + + + 0.055 + + 1.055 + + ) + + 2.4 + + + +

      +
    • +
    • +

      If + + + B + + s + R + G + B + + + + 0.04045 + + then + + B + = + + + B + + s + R + G + B + + + 12.92 + + + else + + B + = + + + ( + + + + B + + s + R + G + B + + + + + 0.055 + + 1.055 + + ) + + 2.4 + + + +

      +
    • +

    and + + + R + + s + R + G + B + + + , + + G + + s + R + G + B + + + , + + + and + + + + B + + s + R + G + B + + + + are defined as:

      +
    • + + + R + + s + R + G + B + + + = + + + R + + 8 + b + i + t + + + 255 + + +
    • +
    • + + + G + + s + R + G + B + + + = + + + G + + 8 + b + i + t + + + 255 + + +
    • +
    • + + + B + + s + R + G + B + + + = + + + B + + 8 + b + i + t + + + 255 + + +
    • +

    (Formula taken from [SRGB].)

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

    + +
    Note

    If dithering occurs after delivery, then the source color value is used. For colors + that are dithered at the source, the average values of the colors that are dithered + should be used (average R, average G, and average B). +

    + +
    Note

    Tools are available that automatically do the calculations when testing contrast and + flash. +

    +
    +
    [SRGB]
    +
    Multimedia systems and equipment - Colour measurement and management - Part 2-1: Colour management - Default RGB colour space - sRGB. IEC. URL: https://webstore.iec.ch/publication/6169
    +
    + + diff --git a/guidelines/relative-luminance.xml b/guidelines/relative-luminance.xml deleted file mode 100644 index 4d52defa2e..0000000000 --- a/guidelines/relative-luminance.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - - MathML version of the relative luminance definition - - -

    MathML version of the relative luminance definition

    -

    The following is a MathML version of the WCAG 2.0 definition of relative luminance. Refer to MathML Software - Browsers for information about browsers and plugins that support MathML which you may need in order to correctly display the information on this page.

    -
    -
    - relative luminance
    -
    -

    the relative brightness of any point in a colorspace, normalized to 0 for darkest black and 1 for lightest white

    -
    -

    - Note 1: For the sRGB colorspace, the relative luminance of a color is defined as - - L=0.2126×R+0.7152×G+0.0722×B - - where R, G and B are defined as: -

    -
      -
    • -

      If - - - R - - s - R - G - B - - - - 0.03928 - - then - - R - = - - - R - - s - R - G - B - - - 12.92 - - - - else - - R - = - - - ( - - - - R - - s - R - G - B - - - + - 0.055 - - 1.055 - - ) - - 2.4 - - - -

      -
    • -
    • -

      If - - - G - - s - R - G - B - - - - 0.03928 - - then - - G - = - - - G - - s - R - G - B - - - 12.92 - - - - else - - G - = - - - ( - - - - G - - s - R - G - B - - - + - 0.055 - - 1.055 - - ) - - 2.4 - - - -

      -
    • -
    • -

      If - - - B - - s - R - G - B - - - - 0.03928 - - then - - B - = - - - B - - s - R - G - B - - - 12.92 - - - - else - - B - = - - - ( - - - - B - - s - R - G - B - - - + - 0.055 - - 1.055 - - ) - - 2.4 - - - -

      -
    • -
    -

    and RsRGB,GsRGB,andBsRGB are defined as:

    -
      -
    • RsRGB=R8bit255
    • -
    • GsRGB=G8bit255
    • -
    • BsRGB=B8bit255
    • -
    -
    -

    (Formula taken from [sRGB] and [IEC-4WD].)

    -
    -

    Note 2: 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.

    -

    Note 3: If dithering occurs after delivery, then the source color value is used. For colors that are dithered at the source, the average values of the colors that are dithered should be used (average R, average G, and average B).

    -

    Note 4: Tools are available that automatically do the calculations when testing contrast and flash.

    - -
    -
    -
    - - diff --git a/guidelines/respec-config.js b/guidelines/respec-config.js index 09acebd9b5..a6189081a5 100644 --- a/guidelines/respec-config.js +++ b/guidelines/respec-config.js @@ -11,7 +11,7 @@ var respecConfig = { specStatus: "ED", //crEnd: "2012-04-30", //perEnd: "2013-07-23", - //publishDate: "2013-08-22", + publishDate: "2023-10-05", diffTool: "http://www.aptest.com/standards/htmldiff/htmldiff.pl", // the specifications short name, as in https://www.w3.org/TR/short-name/ @@ -27,7 +27,7 @@ var respecConfig = { // and its maturity status //previousPublishDate: "2014-06-12", //previousMaturity: "WD", - prevRecURI: "https://www.w3.org/TR/WCAG/", + prevRecURI: "https://www.w3.org/TR/WCAG21/", //previousDiffURI: "https://www.w3.org/TR/2014/REC-wai-aria-20140320/", // if there a publicly available Editors Draft, this is the link @@ -39,39 +39,40 @@ var respecConfig = { // editors, add as many as you like // only "name" is required editors: [ - { - name: "Chuck Adams", - url: "https://www.oracle.com/", - mailto: "charles.adams@oracle.com", - company: "Oracle", - companyURI: "https://www.oracle.com/", - w3cid: 104852 - }, { name: "Alastair Campbell", - url: "https://www.nomensa.com/", + //url: "https://www.nomensa.com/", mailto: "acampbell@nomensa.com", company: "Nomensa", companyURI: "https://www.nomensa.com/", w3cid: 44689 }, { - name: "Rachael Montgomery", + name: "Chuck Adams", + //url: "https://www.oracle.com/", + mailto: "charles.adams@oracle.com", + company: "Oracle", + companyURI: "https://www.oracle.com/", + w3cid: 104852 + }, + { + name: "Rachael Bradley Montgomery", mailto: "rachael@accessiblecommunity.org", - company: "Invited Expert", + company: "Library of Congress", + companyURI: "https://loc.gov/", w3cid: 90310 }, { name: "Michael Cooper", - url: 'https://www.w3.org', - mailto: "cooper@w3.org", + url: 'https://www.w3.org/People/cooper', + //mailto: "cooper@w3.org", company: "W3C", companyURI: "https://www.w3.org", w3cid: 34017 }, { name: "Andrew Kirkpatrick", - url: "http://www.adobe.com/", + //url: "http://www.adobe.com/", mailto: "akirkpat@adobe.com", company: "Adobe", companyURI: "http://www.adobe.com/", @@ -135,25 +136,15 @@ var respecConfig = { ], */ - // errata: 'https://www.w3.org/2010/02/rdfa/errata.html', + errata: 'https://www.w3.org/WAI/WCAG22/errata/', + implementationReportURI: 'https://www.w3.org/WAI/WCAG22/implementation-report/', // name of the WG - wg: "Accessibility Guidelines Working Group", - - // URI of the public WG page - wgURI: "https://www.w3.org/WAI/GL/", - - // name (with the @w3c.org) of the public mailing to which comments are due - wgPublicList: "public-agwg-comments", - - // URI of the patent status for this WG, for Rec-track documents - // !!!! IMPORTANT !!!! - // This is important for Rec-track documents, do not copy a patent URI from a random - // document unless you know what you're doing. If in doubt ask your friendly neighbourhood - // Team Contact. - wgPatentURI: "https://www.w3.org/2004/01/pp-impl/35422/status", + group: "ag", + github: "w3c/wcag", + maxTocLevel: 4, - postProcess: [addTextSemantics, swapInDefinitions] + postProcess: [postRespec] }; diff --git a/guidelines/sc/20/abbreviations.html b/guidelines/sc/20/abbreviations.html index 69d85cf406..81f0d0be8b 100644 --- a/guidelines/sc/20/abbreviations.html +++ b/guidelines/sc/20/abbreviations.html @@ -1,4 +1,4 @@ -
    +

    Abbreviations

    @@ -7,4 +7,4 @@

    Abbreviations

    A mechanism for identifying the expanded form or meaning of abbreviations is available.

    -
    \ No newline at end of file +
    diff --git a/guidelines/sc/20/audio-control.html b/guidelines/sc/20/audio-control.html index 7819ff6eef..aaccda2077 100644 --- a/guidelines/sc/20/audio-control.html +++ b/guidelines/sc/20/audio-control.html @@ -1,4 +1,4 @@ -
    +

    Audio Control

    @@ -13,4 +13,4 @@

    Audio Control

    to meet other success criteria) must meet this success criterion. See Conformance Requirement 5: Non-Interference.

    -
    \ No newline at end of file +
    diff --git a/guidelines/sc/20/audio-description-or-media-alternative-prerecorded.html b/guidelines/sc/20/audio-description-or-media-alternative-prerecorded.html index fc1b009b9b..9198805452 100644 --- a/guidelines/sc/20/audio-description-or-media-alternative-prerecorded.html +++ b/guidelines/sc/20/audio-description-or-media-alternative-prerecorded.html @@ -1,4 +1,4 @@ -
    +

    Audio Description or Media Alternative (Prerecorded)

    @@ -8,4 +8,4 @@

    Audio Description or Media Alternative (Prerecorded)

    video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such.

    -
    \ No newline at end of file +
    diff --git a/guidelines/sc/20/audio-description-prerecorded.html b/guidelines/sc/20/audio-description-prerecorded.html index e69ba4569d..d745a2467c 100644 --- a/guidelines/sc/20/audio-description-prerecorded.html +++ b/guidelines/sc/20/audio-description-prerecorded.html @@ -1,4 +1,4 @@ -
    +

    Audio Description (Prerecorded)

    @@ -8,4 +8,4 @@

    Audio Description (Prerecorded)

    video content in synchronized media.

    -
    \ No newline at end of file +
    diff --git a/guidelines/sc/20/audio-only-and-video-only-prerecorded.html b/guidelines/sc/20/audio-only-and-video-only-prerecorded.html index fea1d134f7..1d00f0b00f 100644 --- a/guidelines/sc/20/audio-only-and-video-only-prerecorded.html +++ b/guidelines/sc/20/audio-only-and-video-only-prerecorded.html @@ -1,4 +1,4 @@ -
    +

    Audio-only and Video-only (Prerecorded)

    @@ -31,4 +31,4 @@

    Audio-only and Video-only (Prerecorded)

    -
    \ No newline at end of file +
    diff --git a/guidelines/sc/20/audio-only-live.html b/guidelines/sc/20/audio-only-live.html index 4df1345cb4..f901051281 100644 --- a/guidelines/sc/20/audio-only-live.html +++ b/guidelines/sc/20/audio-only-live.html @@ -1,4 +1,4 @@ -
    +

    Audio-only (Live)

    @@ -8,4 +8,4 @@

    Audio-only (Live)

    audio-only content is provided.

    -
    \ No newline at end of file +
    diff --git a/guidelines/sc/20/bypass-blocks.html b/guidelines/sc/20/bypass-blocks.html index 4bfedd4f72..5e33982b78 100644 --- a/guidelines/sc/20/bypass-blocks.html +++ b/guidelines/sc/20/bypass-blocks.html @@ -1,4 +1,4 @@ -
    +

    Bypass Blocks

    @@ -7,4 +7,4 @@

    Bypass Blocks

    A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

    -
    \ No newline at end of file +
    diff --git a/guidelines/sc/20/captions-live.html b/guidelines/sc/20/captions-live.html index a46694ddc8..402d85f656 100644 --- a/guidelines/sc/20/captions-live.html +++ b/guidelines/sc/20/captions-live.html @@ -1,4 +1,4 @@ -
    +

    Captions (Live)

    @@ -8,4 +8,4 @@

    Captions (Live)

    audio content in synchronized media.

    -
    \ No newline at end of file +
    diff --git a/guidelines/sc/20/captions-prerecorded.html b/guidelines/sc/20/captions-prerecorded.html index eb2f8a4349..0d9206873f 100644 --- a/guidelines/sc/20/captions-prerecorded.html +++ b/guidelines/sc/20/captions-prerecorded.html @@ -1,4 +1,4 @@ -
    +

    Captions (Prerecorded)

    @@ -8,4 +8,4 @@

    Captions (Prerecorded)

    audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such.

    -
    \ No newline at end of file +
    diff --git a/guidelines/sc/20/change-on-request.html b/guidelines/sc/20/change-on-request.html index bfb87593cc..f5d09acf56 100644 --- a/guidelines/sc/20/change-on-request.html +++ b/guidelines/sc/20/change-on-request.html @@ -1,4 +1,4 @@ -
    +

    Change on Request

    @@ -7,4 +7,4 @@

    Change on Request

    Changes of context are initiated only by user request or a mechanism is available to turn off such changes.

    -
    \ No newline at end of file +
    diff --git a/guidelines/sc/20/consistent-identification.html b/guidelines/sc/20/consistent-identification.html index c1a5e5fcce..789b8d23f6 100644 --- a/guidelines/sc/20/consistent-identification.html +++ b/guidelines/sc/20/consistent-identification.html @@ -1,5 +1,5 @@ -
    - +
    +

    Consistent Identification

    AA

    @@ -7,4 +7,4 @@

    Consistent Identification

    Components that have the same functionality within a set of Web pages are identified consistently.

    -
    \ No newline at end of file +
    diff --git a/guidelines/sc/20/consistent-navigation.html b/guidelines/sc/20/consistent-navigation.html index 7a811663da..a1df5d4e8a 100644 --- a/guidelines/sc/20/consistent-navigation.html +++ b/guidelines/sc/20/consistent-navigation.html @@ -1,4 +1,4 @@ -
    +

    Consistent Navigation

    @@ -7,4 +7,4 @@

    Consistent Navigation

    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.

    -
    \ No newline at end of file +
    diff --git a/guidelines/sc/20/contrast-enhanced.html b/guidelines/sc/20/contrast-enhanced.html index d25475c349..ba07a2a4db 100644 --- a/guidelines/sc/20/contrast-enhanced.html +++ b/guidelines/sc/20/contrast-enhanced.html @@ -1,4 +1,4 @@ -
    +

    Contrast (Enhanced)

    @@ -38,4 +38,4 @@

    Contrast (Enhanced)

    -
    \ No newline at end of file +
    diff --git a/guidelines/sc/20/contrast-minimum.html b/guidelines/sc/20/contrast-minimum.html index 5c022a6e29..744d7f328e 100644 --- a/guidelines/sc/20/contrast-minimum.html +++ b/guidelines/sc/20/contrast-minimum.html @@ -1,4 +1,4 @@ -
    +

    Contrast (Minimum)

    @@ -38,4 +38,4 @@

    Contrast (Minimum)

    -
    \ No newline at end of file +
    diff --git a/guidelines/sc/20/error-identification.html b/guidelines/sc/20/error-identification.html index 2f82a6451d..b9549982e5 100644 --- a/guidelines/sc/20/error-identification.html +++ b/guidelines/sc/20/error-identification.html @@ -1,4 +1,4 @@ -
    +

    Error Identification

    @@ -8,4 +8,4 @@

    Error Identification

    is described to the user in text.

    -
    \ No newline at end of file +
    diff --git a/guidelines/sc/20/error-prevention-all.html b/guidelines/sc/20/error-prevention-all.html index 93729b2349..8fb05bb90e 100644 --- a/guidelines/sc/20/error-prevention-all.html +++ b/guidelines/sc/20/error-prevention-all.html @@ -1,4 +1,4 @@ -
    +

    Error Prevention (All)

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

    -

    Here is a working example of this technique implemented using PHP, Javascript, CSS and XHTML: +

    Here is a working example of this technique implemented using PHP, Javascript, CSS and HTML: Color Picker Example.

    diff --git a/techniques/general/G176.html b/techniques/general/G176.html index 30dd527eb7..b77f6f0aab 100644 --- a/techniques/general/G176.html +++ b/techniques/general/G176.html @@ -1,4 +1,4 @@ -Keeping the flashing area small enough

    Keeping the flashing area small enough

    ID: G176

    Technology: general

    Type: Technique

    When to Use

    +Keeping the flashing area small enough

    Keeping the flashing area small enough

    ID: G176

    Technology: general

    Type: Technique

    When to Use

    Appropriate to use for all general Web content including special cases like material that is specifically designed for a display in a foyer.

    Description

    The purpose of this technique is to provide an easy way to pass the success criterion for things that flash, but are small.

    @@ -22,7 +22,7 @@ any single flashing event on a screen (there is no other flashing on screen) that is smaller than a contiguous area of 21,824 sq pixels (any shape), would pass the General and Red Flash Thresholds.

    1024 x 768 was chosen because it represents the most common screen size. It also works with higher resolution screens since the tighter pixel density would result in a smaller and safer image size.

    Users with lower resolution displays or that enlarge or view their screens closely would have a higher risk depending on the viewing distance. To address the needs of this group, - + G19 should be used since it is independent of screen resolution or viewing distance.

    Formula 2: Small Safe Area for Known Displays @@ -79,10 +79,10 @@ Harding FPA Web Site

  • - Trace Center Photosensitive Epilepsy Analysis Tool (PEAT) + Trace Center Photosensitive Epilepsy Analysis Tool (PEAT)
  • - Information about Photosensitive Seizure Disorders + Information about Photosensitive Seizure Disorders
  • Epilepsy Action @@ -90,9 +90,6 @@
  • Epilepsy Foundation
  • -
  • - ITC Guidance Note for Licensees on Flashing Images and Regular Patterns in Television -
  • \ No newline at end of file diff --git a/techniques/general/G177.html b/techniques/general/G177.html index 03608f617f..d067637e71 100644 --- a/techniques/general/G177.html +++ b/techniques/general/G177.html @@ -1,4 +1,4 @@ -Providing suggested correction text

    Providing suggested correction text

    ID: G177

    Technology: general

    Type: Technique

    When to Use

    +Providing suggested correction text

    Providing suggested correction text

    ID: G177

    Technology: general

    Type: Technique

    When to Use

    Content that accepts user data input, with restrictions on the format, value, and/or type of the input.

    Description

    The objective of this technique is to suggest correct text where the information supplied by the user is not accepted and possible correct text is known. The suggestions may include correct spelling or similar text from a known pool of possible text.

    diff --git a/techniques/general/G178.html b/techniques/general/G178.html index d1b97757db..fcb9d888d1 100644 --- a/techniques/general/G178.html +++ b/techniques/general/G178.html @@ -1,25 +1,17 @@ -Providing controls on the Web page that allow users to incrementally change the size of all text on the page up to 200 percent

    Providing controls on the Web page that allow users to incrementally change the size of all text on the page up to 200 percent

    ID: G178

    Technology: general

    Type: Technique

    When to Use

    +Providing controls on the Web page that allow users to incrementally change the size of all text on the page up to 200 percent

    Providing controls on the Web page that allow users to incrementally change the size of all text on the page up to 200 percent

    ID: G178

    Technology: general

    Type: Technique

    When to Use

    All technologies.

    Description

    The purpose of this technique is to provide a mechanism on the Web page to incrementally increase the size of text. Many people with low vision do not use magnifying software, and they may not be familiar with their browser's text size adjustments. This may be particularly true of older people who are learning about computers later in life and who may be experiencing age related vision loss. It may also be true of some people with cognitive disabilities who require increased font size.

    This technique provides a mechanism that some users will find easier to use. The mechanism may include links or buttons that will switch the visual presentation to a different style sheet or use scripts to change the text size dynamically.

    -

    To implement this technique, an author provides controls that allow the user to incrementally increase or decrease the text size of all of the text on the page to a size that is at least 200% of the default text size.

    +

    To implement this technique, an author provides controls that allow the user to incrementally increase or decrease the text size of all of the text on the page to a size up to 200% of the default text size.

    This can be achieved by providing links, buttons or linked images and the controls themselves should be as easy to find (e.g. prominently positioned within the page, presented in a larger text size, high contrast, etc.) as possible.

    This technique can also be used in circumstances where scalable fonts cannot be used, such as legacy code situations.

    -

    This technique can be used in combination with a style switching technique to present a page that is a - conforming alternate version - for non-conforming content. Refer to - C29: Using a style switcher to provide a conforming alternate version - and - Understanding Conforming Alternate Versions - for more information.

    +

    This technique can be used in combination with a style switching technique to present a page that is a conforming alternate version for non-conforming content. Refer to C29: Using a style switcher to provide a conforming alternate version and Understanding Conforming Alternate Versions for more information.

    Examples

      -
    • A newspaper article has two buttons near the top of the page. The "increase text size" button has a big letter "T" with an upward arrow and the "decrease text size" button has a small letter "T" with a down arrow. There is - alt - text on each button.
    • +
    • A newspaper article has two buttons near the top of the page. The "increase text size" button has a big letter "T" with an upward arrow and the "decrease text size" button has a small letter "T" with a down arrow. There is alt text on each button.
    • A site has a number of style sheets with different text size. The user can choose any of the style sheets if their browser provides this functionality. Each page also includes the links "Increase text size" and "Decrease text size" that will change the style sheet currently applied to the appropriate alternate style sheet.
    • A site includes the text "Change text size:" followed by text links "Up" and "Down" on every Web page. The links trigger a Javascript that alters the value of the text-size property accordingly.
    • A site includes a link on every page that reads "Change text size." The resulting page includes a series of links that includes options representing the available sizes. The links read, "Smallest font size," "Small font size," "Default font size," "Large font size," etc. Instructions preceding the list direct users to choose a link to change to the desired font size.
    • diff --git a/techniques/general/G179.html b/techniques/general/G179.html index c83d701fbe..f8e347a65b 100644 --- a/techniques/general/G179.html +++ b/techniques/general/G179.html @@ -1,4 +1,4 @@ -Ensuring that there is no loss of content or functionality when the text resizes and text containers do not change their width

      Ensuring that there is no loss of content or functionality when the text resizes and text containers do not change their width

      ID: G179

      Technology: general

      Type: Technique

      When to Use

      +Ensuring that there is no loss of content or functionality when the text resizes and text containers do not change their width

      Ensuring that there is no loss of content or functionality when the text resizes and text containers do not change their width

      ID: G179

      Technology: general

      Type: Technique

      When to Use

      All technologies that reflow text when windows are resized.

      Description

      Some user agents support changing the size of text without changing other dimensions of the text container. Loss of content or functionality can occur when the text overflows the space that was allocated for it. However, the layout properties may provide a way to continue to display the content effectively. The block sizes may be defined wide enough that the text does not overflow when resized by 200%. Text may wrap when it no longer fits within the block, and the block may be tall enough that all the text continues to fit in the block. The block may provide scrollbars when the resized text no longer fits.

      diff --git a/techniques/general/G18.html b/techniques/general/G18.html index d5d40b8a49..30806b5af4 100644 --- a/techniques/general/G18.html +++ b/techniques/general/G18.html @@ -1,10 +1,10 @@ Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) - and background behind the text

      Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) + and background behind the text

      Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text

      ID: G18

      Technology: general

      Type: Technique

      When to Use

      Any technology that produces visual output.

      Description

      The objective of this technique is to make sure that users can read text - that is presented over a background. For Success Criterion 1.4.3, this technique describes the minimum contrast ratio for text that is less than 18 point (if not bold) and less than 14 point (if bold). For Success Criterion 1.4.5, this technique relaxes the 7:1 contrast ratio requirement for text that is at least 18 point (if not bold) or at least 14 point (if bold).

      + that is presented over a background. For Success Criterion 1.4.3, this technique describes the minimum contrast ratio for text that is less than 18 point (if not bold) and less than 14 point (if bold). For Success Criterion 1.4.6, this technique relaxes the 7:1 contrast ratio requirement for text that is at least 18 point (if not bold) or at least 14 point (if bold).

      When evaluating this success criterion, the font size in points should be obtained from the user agent or calculated on font metrics in the way that user agents do. Point sizes are based on the CSS pt size CSS3 Values. The ratio between sizes in points and CSS pixels is 1pt = 1.333px, therefore 14pt and 18pt are equivalent to approximately 18.5px and 24px.

      @@ -58,7 +58,7 @@
      • if R sRGB - <= 0.03928 then + <= 0.04045 then R = R sRGB @@ -69,7 +69,7 @@ +0.055)/1.055) ^ 2.4
      • if G sRGB - <= 0.03928 then + <= 0.04045 then G = G sRGB @@ -80,7 +80,7 @@ +0.055)/1.055) ^ 2.4
      • if B sRGB - <= 0.03928 then + <= 0.04045 then B = B sRGB @@ -152,20 +152,18 @@
      • #4 is true.
      +

      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.

      Resources

      -
      \ No newline at end of file +
      diff --git a/techniques/general/G180.html b/techniques/general/G180.html index d885dec9fc..8e6db194f2 100644 --- a/techniques/general/G180.html +++ b/techniques/general/G180.html @@ -1,7 +1,7 @@ -Providing the user with a means to set the time limit to 10 times the default time limit

      Providing the user with a means to set the time limit to 10 times the default time limit

      ID: G180

      Technology: general

      Type: Technique

      When to Use

      +Providing the user with a means to set the time limit to 10 times the default time limit

      Providing the user with a means to set the time limit to 10 times the default time limit

      ID: G180

      Technology: general

      Type: Technique

      When to Use

      All technologies.

      Description

      -

      The objective of this technique is to give people with disabilities enough time to complete tasks which may take them longer than someone without those challenges. Some mechanism such as a preference setting or a control on the page lets the user change the time limits to at least 10 times the default time limit. Preferably, the mechanism would have a variable adjustment that lets the user change the time limit to any value in its range, but could also provide ways to change the time limit by discrete increments. The user changes the time limit at the beginning of his session, before any activity that has a time limit.

      +

      The objective of this technique is to give people with disabilities enough time to complete tasks which may take them longer than someone without those challenges. Some mechanism such as a preference setting or a control on the page lets the user change the time limits to at least 10 times the default time limit. Preferably, the mechanism would have a variable adjustment that lets the user change the time limit to any value in its range, but could also provide ways to change the time limit by discrete increments. The user changes the time limit at the beginning of their session, before any activity that has a time limit.

      Examples

      • An airline has an online ticket purchasing application. By default, the application has a 1 minute time limit for each step of the purchase process. At the beginning of the session, a Web page includes information that says, "We expect that each step in the purchasing process will take users one minute to complete. Would you like to adjust the time limit?" followed by several radio buttons "1 minute, 2 minutes, 5 minutes, 10 minutes."
      • diff --git a/techniques/general/G181.html b/techniques/general/G181.html index 699acb094e..333d041e53 100644 --- a/techniques/general/G181.html +++ b/techniques/general/G181.html @@ -1,4 +1,4 @@ -Encoding user data as hidden or encrypted data in a re-authorization page

        Encoding user data as hidden or encrypted data in a re-authorization page

        ID: G181

        Technology: general

        Type: Technique

        When to Use

        +Encoding user data as hidden or encrypted data in a re-authorization page

        Encoding user data as hidden or encrypted data in a re-authorization page

        ID: G181

        Technology: general

        Type: Technique

        When to Use

        Pages that require user authentication where the time available for submitting data is limited.

        Description

        Web servers that require user authentication often terminate the session after a set period of time if there is no activity from the user. If the user is unable to input the data quickly enough and the session times out before they submit, the server will require re-authentication before proceeding. When this happens, the server passes (as hidden data) the information from the form into the page that is used for re-authentication. Then, when the user re-authenticates, the server can use the information passed on from the re-authentication page to submit the form directly or to present a page that includes the data that is to be submitted for review. In this technique, the server does not have to store any user-submitted data on server. This is an important technique for those cases where it is either illegal or a security risk for the server to store information temporarily. It also is useful in that it frees the server from having to maintain the stored information and reconnect it with the newly authenticated session.

        @@ -8,7 +8,7 @@

        Examples

        • A user has logged in to use a wiki and begins editing a page. The time taken to complete the edits exceeds the time allowed by the server for session inactivity. When the user submits the edits, the user is notified that the session has timed out and is redirected to a login page. The script that handles the original form submission passes the edits as a variable to the login page and when the user successfully logs in, passes the users edits back to the script that handles form submissions and the edits are processed as though no session timeout had occurred.
        • -
        • A user had logged in to a secure shopping site and fills out some of the information on an order form. For security reasons, the session times out after 30 mintues, but the user does not submit the form until 45 minutes after loading the page. The user is informed of the time out and is prompted to log-in again. If the user logs in correctly, the order form is presented to the user with all of the data previously entered and the user is able to review their submission and submit the form. If the log-in is not successfully completed, then the form data is discarded by the server.
        • +
        • A user had logged in to a secure shopping site and fills out some of the information on an order form. For security reasons, the session times out after 30 minutes, but the user does not submit the form until 45 minutes after loading the page. The user is informed of the time out and is prompted to log-in again. If the user logs in correctly, the order form is presented to the user with all of the data previously entered and the user is able to review their submission and submit the form. If the log-in is not successfully completed, then the form data is discarded by the server.

        Tests

        Procedure

        @@ -29,4 +29,4 @@
        \ No newline at end of file +
      diff --git a/techniques/general/G182.html b/techniques/general/G182.html index c44abfa655..8fa80302d4 100644 --- a/techniques/general/G182.html +++ b/techniques/general/G182.html @@ -1,4 +1,4 @@ -Ensuring that additional visual cues are available when text color differences are used to convey information

      Ensuring that additional visual cues are available when text color differences are used to convey information

      ID: G182

      Technology: general

      Type: Technique

      When to Use

      +Ensuring that additional visual cues are available when text color differences are used to convey information

      Ensuring that additional visual cues are available when text color differences are used to convey information

      ID: G182

      Technology: general

      Type: Technique

      When to Use

      Colored text when the color is used to convey information such as:

      • Words that are links in a paragraph
      • @@ -9,7 +9,7 @@

        To use this technique, an author incorporates a visual cue in addition to color for each place where color alone is used to convey information. Visual cues can take many forms including changes to the font style, the addition of underlines, bold, or italics, or changes to the font size.

        While this technique is sufficient to meet the visual requirements of Success Criterion 1.4.1, the information conveyed by the color must also be available programmatically to satisfy Success Criterion 1.3.1. See - How to Meet 1.3.1.

        + How to Meet 1.3.1.

      Examples

        diff --git a/techniques/general/G183.html b/techniques/general/G183.html index a55367e8c3..77c8730f5f 100644 --- a/techniques/general/G183.html +++ b/techniques/general/G183.html @@ -1,11 +1,13 @@ -Using a contrast ratio of 3:1 with surrounding text and providing additional visual cues on focus for links or controls where color alone is used to identify them

        Using a contrast ratio of 3:1 with surrounding text and providing additional visual cues on focus for links or controls where color alone is used to identify them

        ID: G183

        Technology: general

        Type: Technique

        When to Use

        + + Using a contrast ratio of 3:1 with surrounding text and providing additional visual cues on hover for links or controls where color alone is used to identify them + + +

        Using a contrast ratio of 3:1 with surrounding text and providing additional visual cues on hover for links or controls where color alone is used to identify them

        ID: G183

        Technology: general

        Type: Technique

        When to Use

        Colored text when color alone is used to convey information such as words that are links in a paragraph

        Description

        -

        The intent of this technique is to provide a redundant visual cue for users who may not be able to discern a difference in text color. Color is commonly used to indicate words that are links within a paragraph or other block of text. For example, scattered words in text may be hypertext links that are identified only by a difference in color with surrounding text. This technique describes a way to provide additional cues on hover and focus so that users who may have difficulty perceiving color differences or have low vision can identify them.

        -

        With this technique, a - relative luminance - (lightness) difference of 3:1 or greater with the text around it can be used if additional visual confirmation is available when a user points or tabs to the link. Visual highlights may, for example, take the form of underline, a change in font style such as bold or italics, or an increase in font size.

        -

        While using this technique is sufficient to meet this success criterion, it is not the preferred technique to differentiate link text. This is because links that use the relative luminance of color alone may not be obvious to people with black/white color blindness. If there are not a large number of links in the block of text, underlines are recommended for links.

        +

        The intent of this technique is to provide a redundant visual cue for users who may not be able to discern a difference in text color. Color (generally defined as a combination of hue, saturation and luminance) is commonly used to indicate words that are links within a paragraph or other block of text. For example, scattered words in text may be hypertext links that are identified only by a difference in color with surrounding text. This technique describes a way to provide a difference in contrast rather than relying on hue.

        +

        To meet success criterion 1.4.1: Use of Color a relative luminance (lightness) difference of 3:1 or greater with the text around can be used. This technique goes beyond the success criterion and asks for visual highlights when the user hovers over each link, such as an underline, a change in font style such as bold or italics, or an increase in font size. Such a hover effect provides confirmation to pointer users that the text is a link, similar to how the link alters its appearance for keyboard users when it receives focus, in order to meet 2.4.7 Focus Visible.

        +

        While using this technique is sufficient to meet this success criterion, it is not the preferred technique to differentiate link text. This is because links that use the relative luminance of color alone may not be obvious to people with low vision. If there are not a large number of links in the block of text, underlines are recommended for links in blocks of text.

        This technique is about the use of color in addition to luminosity. In this technique, the contrast ratio refers to the contrast between a link and the words around it. In Success Criterion 1.4.3 and 1.4.6, contrast ratio refers to the contrast between a word and its background. The difference is that this technique is about the ability for users to tell the difference (a noticeable difference) between different pieces of text whereas the contrast ratio used in success criterion 1.4.3 and 1.4.6 is about the readability of the text with its background for different color and vision disabilities.

        If an author wants to use the color portion of this technique (i.e., using different colors for the words where the colors have sufficient contrast with each other) and the author also wants to conform to SC 1.4.3 (contrast of both words with their backgrounds) the following colors can be used. (e.g., black text in a paragraph on a white background with the links shown as one of the colors in example 1 below.

        @@ -22,23 +24,20 @@

        Colors that would provide 3:1 contrast with black words and 4.5:1 contrast w

        -

        The hypertext links in a document are medium-light blue (#3366CC) and the regular text is black (#000000). Because the blue text is light enough, it has a contrast of 3.9:1 with the surrounding text and can be identified as being different than the surrounding text by people with all types of color blindness, including those individuals who cannot see color at all.

        +

        The hypertext links in a document are medium-light blue (#3366CC) and the regular text is black (#000000). Beyond the difference in color, the links have no other styles differences compared with the regular text. Because the blue text is light enough, it has a contrast of 3.9:1 with the surrounding text and can be identified as being different from the surrounding text by people with all types of color blindness, including those individuals who cannot see color at all. In addition to the contrast difference, the links have :focus and :hover styles that reintroduce the underline when the links receive keyboard focus or when a mouse pointer hovers over them. Hover or focus style changes alone are not sufficient to meet the criterion.

        Tests

        Procedure

        +

        For each instance where color is used to convey information about text:

          -
        1. Locate all instances where color alone is used to convey information about text.
        2. -
        3. Check that the - relative luminance - of the color of the text differs from the relative luminance of the surrounding text by a contrast ratio of at least 3:1.
        4. -
        5. Check that pointing (mouseover) to the link causes a visual enhancement (such as an underline, font change, etc.)
        6. -
        7. Check that moving keyboard focus to the link causes a visual enhancement (such as an underline, font change, etc.)
        8. +
        9. Check that the relative luminance of the color of the text differs from the relative luminance of the surrounding text by a contrast ratio of at least 3:1.
        10. +
        11. Check that hovering over the link causes a visual enhancement (such as an underline, font change, etc.)

        Expected Results

          -
        • Checks #2, #3, and #4 are all true.
        • +
        • Checks #1 and #2 are true.
        \ No newline at end of file +
      diff --git a/techniques/general/G184.html b/techniques/general/G184.html index adbcd676ac..c6b6e02452 100644 --- a/techniques/general/G184.html +++ b/techniques/general/G184.html @@ -1,4 +1,4 @@ -Providing text instructions at the beginning of a form or set of fields that describes the necessary input

      Providing text instructions at the beginning of a form or set of fields that describes the necessary input

      ID: G184

      Technology: general

      Type: Technique

      When to Use

      +Providing text instructions at the beginning of a form or set of fields that describes the necessary input

      Providing text instructions at the beginning of a form or set of fields that describes the necessary input

      ID: G184

      Technology: general

      Type: Technique

      When to Use

      All technologies.

      Description

      The objective of this technique is to help the user avoid input errors by informing them ahead of time about restrictions on the format of data that they must enter. Instructions on such restrictions are provided at the top of forms. This technique works best for forms that have a small number of fields or those where many form fields require data in the same format. In these cases, it is more efficient to describe the format once in instructions at the top of the form rather than repeating the same information for each field that has the same restricted format requirement.

      diff --git a/techniques/general/G185.html b/techniques/general/G185.html index cbe91e00df..340d6cb554 100644 --- a/techniques/general/G185.html +++ b/techniques/general/G185.html @@ -1,10 +1,10 @@ -Linking to all of the pages on the site from the home page

      Linking to all of the pages on the site from the home page

      ID: G185

      Technology: general

      Type: Technique

      When to Use

      +Linking to all of the pages on the site from the home page

      Linking to all of the pages on the site from the home page

      ID: G185

      Technology: general

      Type: Technique

      When to Use

      All technologies that contain links.

      Description

      The objective of this technique is to make it possible for users to locate all the information in a small Web site by providing links to all Web pages from the home page. When the number of pages in the site is small enough, the home page can contain site map information directly. The other pages in the Web site contain links to the home page.

      In this way, the home page serves as two mechanisms in one. It provides the usual navigation to pages. It also is a de facto site map to the site.

      All the Web pages in the site may contain links to all the other pages, and those sets of links satisfy - Success Criterion 3.2.3 (Consistent Navigation).

      + Success Criterion 3.2.3 (Consistent Navigation).

      Examples

      • A small commercial Web site for a consultant contains a home page, a Contacts page for contacting the consultant, a page describing the consultant's background, and a page with examples of the consultant's work. Each page contains a navigation bar that links to all the other pages in the site.
      • diff --git a/techniques/general/G186.html b/techniques/general/G186.html index b61ad08ee1..ee79859e6f 100644 --- a/techniques/general/G186.html +++ b/techniques/general/G186.html @@ -1,4 +1,4 @@ -Using a control in the Web page that stops moving, blinking, or auto-updating content

        Using a control in the Web page that stops moving, blinking, or auto-updating content

        ID: G186

        Technology: general

        Type: Technique

        When to Use

        +Using a control in the Web page that stops moving, blinking, or auto-updating content

        Using a control in the Web page that stops moving, blinking, or auto-updating content

        ID: G186

        Technology: general

        Type: Technique

        When to Use

        All technologies.

        Description

        The objective of this technique is to provide the user a control that allows him to stop moving or blinking content. Since the control is in the web page, the control itself meets the appropriate level of WCAG conformance e.g., it has appropriate contrast, it has a name that identifies it, it is keyboard accessible. The control is either at the top of the page or adjacent to the moving content. A single control may stop all moving or blinking content on the page, or there may be separate controls for separate parts of the content.

        diff --git a/techniques/general/G187.html b/techniques/general/G187.html index 1813bfe6f5..1df33d06fb 100644 --- a/techniques/general/G187.html +++ b/techniques/general/G187.html @@ -1,4 +1,8 @@ -Using a technology to include blinking content that can be turned off via the user agent

        Using a technology to include blinking content that can be turned off via the user agent

        ID: G187

        Technology: general

        Type: Technique

        When to Use

        +--- +obsoleteMessage: Most user agents do not implement a stop animation command as described in this technique. +obsoleteSince: 20 +--- +Using a technology to include blinking content that can be turned off via the user agent

        Using a technology to include blinking content that can be turned off via the user agent

        ID: G187

        Technology: general

        Type: Technique

        When to Use

        All technologies.

        Description

        The objective of this technique is to ensure that blinking content can be turned off using user agent features. User agents allow users to stop animation of content in certain technologies. When the user activates this feature, all animation, including blinking, is stopped. This feature can be provided either through interactive controls that conform to WCAG or through documented keyboard shortcuts.

        @@ -25,4 +29,4 @@
      • Check #3 is true.
      -
      \ No newline at end of file +
      diff --git a/techniques/general/G188.html b/techniques/general/G188.html index 205999c037..bcaa35fc2b 100644 --- a/techniques/general/G188.html +++ b/techniques/general/G188.html @@ -1,49 +1,73 @@ -Providing a button on the page to increase line spaces and paragraph spaces

      Providing a button on the page to increase line spaces and paragraph spaces

      ID: G188

      Technology: general

      Type: Technique

      When to Use

      + + + + Providing a button on the page to increase line spaces and paragraph spaces + + + +

      Providing a button on the page to increase line spaces and paragraph spaces

      +
      +

      ID: G188

      +

      Technology: general

      +

      Type: Technique

      +
      +
      +

      When to Use

      Any technology.

      -

      Description

      +
      +
      +

      Description

      Many people with cognitive disabilities have trouble reading text that is single spaced. A button that increases the line height will help them read the content. In order to retain the separation of paragraphs, the space between paragraphs should also increase so that it is at least 1.5 times as high as the line spacing.

      -
      -

      This technique can be used in combination with a style switching technique to present a page that is a - conforming alternate version - for non-conforming content. Refer to - C29: Using a style switcher to provide a conforming alternate version - and - Understanding Conforming Alternate Versions - for more information.

      -
      -

      Examples

      -
      - -

      Use standard style page switching and have a button or link on the page that switches the stylesheet. The new stylesheet contains a rule to increase the line height and a class to increase the paragraph spacing.

      - -
      -              p {line-height: 150%; margin-bottom: 2em;}
      -            
      +
      +

      This technique can be used in combination with a style switching technique to present a page that is a conforming alternate version for non-conforming content. Refer to C29: Using a style switcher to provide a conforming alternate version and Understanding Conforming Alternate Versions for more information.

      +
      +
      +
      +

      Examples

      +
      +

      Use standard style page switching and have a button or link on the page that switches the stylesheet. The new stylesheet contains a rule to increase the line height and a class to increase the paragraph spacing.

      +
      p {
      +  line-height: 1.5;
      +  margin-bottom: 2em;
      +}
      -

      Tests

      -

      Procedure

      -
        -
      1. Check that there is a button or link on the page that increases the size of the line height and the paragraph spacing, which is labeled as such.
      2. -
      3. Activate the button or link.
      4. -
      5. Check that the button or link increases the line height to at least 1.5 (150%)
      6. -
      7. Check that the button or link increases the paragraph spacing at least 1.5 times greater than the line spacing.
      8. +
      +
      +

      Tests

      +
      +

      Procedure

      +
        +
      1. Check that there is a button or link on the page that increases the size of the line height and the paragraph spacing, which is labeled as such.
      2. +
      3. Activate the button or link.
      4. +
      5. Check that the button or link increases the line height to at least 1.5 (150%)
      6. +
      7. Check that the button or link increases the paragraph spacing at least 1.5 times greater than the line spacing.
      -
      -

      Expected Results

      -
        -
      • Checks #1, #3 and #4 are true.
      • +
      +
      +

      Expected Results

      +
        +
      • Checks #1, #3 and #4 are true.
      -
      +

      Resources

      - - - -
      \ No newline at end of file +
    +
    +
    +

    Resources

    + +
    + + \ No newline at end of file diff --git a/techniques/general/G189.html b/techniques/general/G189.html index 37f8e0e7e9..8253ada80b 100644 --- a/techniques/general/G189.html +++ b/techniques/general/G189.html @@ -1,76 +1,88 @@ -Providing a control near the beginning of the Web page that changes the link text

    Providing a control near the beginning of the Web page that changes the link text

    ID: G189

    Technology: general

    Type: Technique

    When to Use

    + + + + Providing a control near the beginning of the Web page that changes the link text + + + +

    Providing a control near the beginning of the Web page that changes the link text

    +
    +

    ID: G189

    +

    Technology: general

    +

    Type: Technique

    +
    +
    +

    When to Use

    All technologies that contain links.

    -

    Description

    +
    +
    +

    Description

    The objective of this technique is to provide the user with a control near the beginning of the page that takes the user to a conforming alternate version of the Web page where the link text alone of each link is sufficient to determine its purpose out of context.

    Some users prefer to have links that are self-contained, where there is no need to explore the context of the link. Other users find including the context information in each link to be repetitive and to reduce their ability to use a site. Among users of assistive technology, the feedback to the working group on which is preferable has been divided. This technique allows users to pick the approach that works best for them. Users who need or prefer potentially longer but complete link text use this version.

    If the control for switching to the alternate version is a link, it must always be possible to understand the purpose of the control directly from its link text.

    This technique provides the alternate version for the current page view. It is also possible, and in some cases would be advisable, to save this preference in a cookie or server-side user profile, so that users would only have to make the selection once per site and would automatically be taken to their preferred version.

    -

    This technique can be used in combination with a style switching technique to present a page that is a - conforming alternate version - for non-conforming content. Refer to - C29: Using a style switcher to provide a conforming alternate version - and - Understanding Conforming Alternate Versions - for more information.

    +

    This technique can be used in combination with a style switching technique to present a page that is a conforming alternate version for non-conforming content. Refer to C29: Using a style switcher to provide a conforming alternate version and Understanding Conforming Alternate Versions for more information.

    -

    Examples

    -
    -

    Providing a Link to another Version

    +
    +
    +

    Examples

    +
    +

    Providing a Link to another Version

    +

    A Web page lists books for download in different formats. Alternate versions of the Web page use just the book format as the link text or the book title and format type.

    +

    Version with short link text:

    +
    <h1>Books for download</h1>
    +<p><a href="books-full-links.html">Full link Version</a></p>
    +<ul>
    +  <li>The History of the Web: 
    +    <a href="history.docx">Word</a>, 
    +    <a href="history.pdf">PDF</a>, 
    +    <a href="history.html">HTML</a>
    +  </li>
    +</ul>
    -

    A Web page lists books for download in different formats. Alternate versions of the Web page use just the book format as the link text or the book title and format type.

    -

    Version with short link text:

    - -
    -              ...
    -                <h1>Books for download</h1>
    -                <p><a href="books-full-links.html" >Full link Version</a></p>
    -                <ul>
    -                <li>The History of the Web: 
    -                <a href="history.docx" class="hist">Word</a>, 
    -                <a href="history.pdf" class="hist">PDF</a>, 
    -                <a href="history.html" class="hist">HTML</a>
    -                </li>
    -                ...
    -                </ul>
    -            
    - -

    Version with full link text:

    - -
    -              ...
    -                <h1>Books for download</h1>
    -                <p><a href="books-short-links.html" >Short link Version</a></p>
    -                <ul>
    -                <li>The History of the Web: 
    -                <a href="history.docx" class="hist">The History of the Web(Word)</a>, 
    -                <a href="history.pdf" class="hist">The History of the Web(PDF)>/a>, 
    -                <a href="history.html" class="hist">The History of the Web(HTML)</a>
    -                </li>
    -                ...
    -                </ul>
    -            
    -
    -

    Tests

    -

    Procedure

    -
      -
    1. Check that there is a control near the beginning of the Web page to change link text.
    2. -
    3. Activate the control.
    4. -
    5. Check that all links in the resulting Web page have link text that describes their purpose.
    6. -
    -
    -

    Expected Results

    -
      -
    • Checks #1 and #3 are true.
    • -
    +
    +

    Version with full link text:

    +
    <h1>Books for download</h1>
    +<p><a href="books-short-links.html">Short link Version</a></p>
    +<ul>
    +  <li>The History of the Web: 
    +    <a href="history.docx" class="hist">The History of the Web (Word)</a>, 
    +    <a href="history.pdf" class="hist">The History of the Web (PDF)</a>, 
    +    <a href="history.html" class="hist">The History of the Web (HTML)</a>
    +  </li>
    +</ul>
    +
    +
    +
    +
    +

    Tests

    +
    +

    Procedure

    +
      +
    1. Check that there is a control near the beginning of the Web page to change link text.
    2. +
    3. Activate the control.
    4. +
    5. Check that all links in the resulting Web page have link text that describes their purpose.
    6. +
    -
    \ No newline at end of file +
    +

    Expected Results

    +
      +
    • Checks #1 and #3 are true.
    • +
    +
    +
    + + + \ No newline at end of file diff --git a/techniques/general/G19.html b/techniques/general/G19.html index 987f8e3506..42397557db 100644 --- a/techniques/general/G19.html +++ b/techniques/general/G19.html @@ -1,4 +1,4 @@ -Ensuring that no component of the content flashes more than three times in any 1-second period

    Ensuring that no component of the content flashes more than three times in any 1-second period

    ID: G19

    Technology: general

    Type: Technique

    When to Use

    +Ensuring that no component of the content flashes more than three times in any 1-second period

    Ensuring that no component of the content flashes more than three times in any 1-second period

    ID: G19

    Technology: general

    Type: Technique

    When to Use

    Applies to any technology

    Description

    The objective of this technique is to avoid flashing at rates that are known to cause seizures if the flashes are bright and large enough. Since some users may be using screen enlargers, this technique limits the flashing of any size content to no more than three flashes in any 1-second period.

    @@ -26,7 +26,7 @@

    Expected Results

      -
    • Both Step 1 and Step 2 are true.
    • +
    • Both checks #1 and #2 are true.
    diff --git a/techniques/general/G191.html b/techniques/general/G191.html index 5aa870cbcd..0b4214da7b 100644 --- a/techniques/general/G191.html +++ b/techniques/general/G191.html @@ -1,8 +1,8 @@ -Providing a link, button, or other mechanism that reloads the page without any blinking content

    Providing a link, button, or other mechanism that reloads the page without any blinking content

    ID: G191

    Technology: general

    Type: Technique

    When to Use

    +Providing a link, button, or other mechanism that reloads the page without any blinking content

    Providing a link, button, or other mechanism that reloads the page without any blinking content

    ID: G191

    Technology: general

    Type: Technique

    When to Use

    This technique relates to all technologies.

    Description

    This is a general technique for allowing people who cannot use a page with blinking content to turn the blinking content off. - Conformance Requirement 1 + Conformance Requirement 1 allows for conforming alternate pages to be used to meet conformance. This technique is an example of that approach applied to success criteria 2.2.2.

    It is important that the page without blinking content contain all of the information that was on the page with blinking content.

    @@ -10,9 +10,8 @@

    This technique can be used in combination with a style switching technique to present a page that is a conforming alternate version for non-conforming content. Refer to - - and - Understanding Conforming Alternate Versions + Using a style switcher to provide a conforming alternate version + and Understanding Conforming Alternate Versions for more information.

    Examples

    @@ -37,7 +36,6 @@
  • G11
  • G152
  • G186
  • -
  • G187
  • SCR22
  • SCR33
  • \ No newline at end of file diff --git a/techniques/general/G192.html b/techniques/general/G192.html index cdc0f0f265..5c8670065c 100644 --- a/techniques/general/G192.html +++ b/techniques/general/G192.html @@ -1,4 +1,9 @@ -Fully conforming to specifications

    Fully conforming to specifications

    ID: G192

    Technology: general

    Type: Technique

    When to Use

    +--- +obsoleteMessage: | + This technique relates to 4.1.1: Parsing, which was removed as of WCAG 2.2. +obsoleteSince: 22 +--- +Fully conforming to specifications

    Fully conforming to specifications

    ID: G192

    Technology: general

    Type: Technique

    When to Use

    This technique relates to all markup languages with specifications.

    Description

    When markup languages are used in a way that fully conforms to their specifications, all of the requirements in 4.1.1 are met. Therefore, while fully conforming to specifications is not required to conform to WCAG 2.0, it is a best practice and is sufficient to meet Success Criterion 4.1.1.

    @@ -25,4 +30,4 @@
  • H74
  • H75
  • H88
  • -
    \ No newline at end of file +
    diff --git a/techniques/general/G193.html b/techniques/general/G193.html index d90c41b595..24c77d6e55 100644 --- a/techniques/general/G193.html +++ b/techniques/general/G193.html @@ -1,10 +1,10 @@ -Providing help by an assistant in the Web page

    Providing help by an assistant in the Web page

    ID: G193

    Technology: general

    Type: Technique

    When to Use

    +Providing help by an assistant in the Web page

    Providing help by an assistant in the Web page

    ID: G193

    Technology: general

    Type: Technique

    When to Use

    All technologies.

    Description

    The purpose of this technique is to provide help using a multimedia avatar that provides assistance in using the Web page. An avatar can be particularly helpful to people with cognitive disabilities who may have trouble reading text. The use of visuals will help some people to focus on the material presented.

    The multimedia avatar must also satisfy relevant Success Criterion in - Guideline 1.2.

    + Guideline 1.2.

    Examples

      diff --git a/techniques/general/G194.html b/techniques/general/G194.html index e9ecd7beae..bfdfd02400 100644 --- a/techniques/general/G194.html +++ b/techniques/general/G194.html @@ -1,4 +1,4 @@ -Providing spell checking and suggestions for text input

      Providing spell checking and suggestions for text input

      ID: G194

      Technology: general

      Type: Technique

      When to Use

      +Providing spell checking and suggestions for text input

      Providing spell checking and suggestions for text input

      ID: G194

      Technology: general

      Type: Technique

      When to Use

      This technique relates to all technologies.

      Description

      In this technique spell checking and suggestions for text are provided. Often people with cognitive disabilities have trouble spelling a word, but may be able to get the spelling approximately correct. A spell checking program will save them time-consuming research on how to spell the word. This may also be true for blind and low vision users who might make a mistake when typing. It will also help people with dexterity disabilities who may be using a head pointer, or who may have scanning software which makes it very slow and difficult to type. A spell-checking solution that provides word suggestion(s) and a simple mechanism to select one and input it into the text input field provides important help for these users and others.

      diff --git a/techniques/general/G195.html b/techniques/general/G195.html index 6aedf9e9e9..e2746fd30e 100644 --- a/techniques/general/G195.html +++ b/techniques/general/G195.html @@ -1,8 +1,8 @@ -Using an author-supplied, highly visible focus indicator

      Using an author-supplied, highly visible focus indicator

      ID: G195

      Technology: general

      Type: Technique

      When to Use

      +Using an author-supplied, visible focus indicator

      Using an author-supplied, visible focus indicator

      ID: G195

      Technology: general

      Type: Technique

      When to Use

      Generally applicable.

      Description

      -

      The objective of this technique is enhance the focus indicator in the browser, by creating a highly visible one in the content. The default focus indicator in many browsers is a thin, dotted, black line. It can be difficult to see the line when it is around a form element which already has an outline, when the focused element is inside a table cell, when the focused element is very small, or when the background of the page is a dark color. Some browsers use a pale blue outline, which can be difficult to see on some backgrounds.

      -

      In this technique, when the user places focus on an element, using the mouse, tab key, arrow keys, keyboard shortcuts, or any other method, the application makes that focus more visible, using a combination of a highly contrasting color, a thick line, and other visual indicators such as a glow.

      +

      The objective of this technique is enhance the focus indicator in the browser, by creating a visible one in the content. The default focus indicator in some browsers is a thin, dotted, black line. It can be difficult to see the line when it is around a form element which already has an outline, when the focused element is inside a table cell, when the focused element is very small, or when the background of the page is a dark color. Some browsers use a pale blue outline, which can be difficult to see on some backgrounds.

      +

      In this technique, when the user places focus on an element using the keyboard, the application makes that focus more visible, using a combination of a highly contrasting color, a thick line, and other visual indicators such as a glow.

      Examples

      @@ -13,34 +13,36 @@

      Links

      Form Elements

      -

      A Web page includes a form inside a table. The borders of both the table and the form elements are thin, black lines. When focus lands on a form element, the element is outlined with a 5 pixel red line that is partially transparent.

      +

      A Web page includes a form inside a table. The borders of both the table and the form elements are thin, black lines. When focus lands on a form element, the element is outlined with a 5 pixel red line that is partially transparent. The red is equivalent to a hex color of #FF3838, providing a 3.6:1 contrast ratio with the white background.

      Menus

      -

      A Web page includes an interactive menu with sub-menus. A user can move focus in the menu using the arrow keys. As focus moves, the currently focused menu item changes its background to a different color, which has a 3:1 contrast ratio with the surrouding items and a 4.5:1 contrast ratio with its own text.

      +

      A Web page includes an interactive menu with sub-menus. A user can move focus in the menu using the arrow keys. As focus moves, the currently focused menu item changes its background to a different color, which has a 3:1 contrast ratio with the surrounding items and a 4.5:1 contrast ratio with its own text.

      Tests

      Procedure

      +

      For each user interface component on the page that should receive keyboard focus:

        -
      1. Place focus on each focusable user interface element on the page using the mouse.
      2. -
      3. Check that there is a highly visible focus indicator.
      4. -
      5. Place focus on each focusable user interface element on the page using the keyboard.
      6. +
      7. Navigate to the component and check that it has a visible focus indicator.
      8. Check that the focus indicator area is at least the size of a 1 CSS px border around the component.
      9. -
      10. Check that the change of contrast of the indicator between focused and unfocused states has a ratio of 3:1 for the minimum focus indicator area.
      11. +
      12. If the focus indicator area is not at least equal to the area of a 1 CSS pixel border, check that it has an area of at least 4 CSS pixels along the shortest side of the component.
      13. +
      14. Check that the change of contrast of the indicator between focused and unfocused states has a ratio of 3:1 or more for the minimum focus indicator area.
      15. If the focus indicator does not have 3:1 contrast ratio with its adjacent colors, check that it is at least 2px thick.

      Expected Results

        -
      • Checks #2, #4, #5 and #6 are true.
      • +
      • Checks #2, #4, and #5 are true.
      \ No newline at end of file +
    • C40
    • +
    • C45
    • +
    diff --git a/techniques/general/G196.html b/techniques/general/G196.html index b3606ff56e..3ac8132433 100644 --- a/techniques/general/G196.html +++ b/techniques/general/G196.html @@ -1,39 +1,61 @@ -Using a text alternative on one item within a group of images that describes all items in the group

    Using a text alternative on one item within a group of images that describes all items in the group

    ID: G196

    Technology: general

    Type: Technique

    When to Use

    + + + + Using a text alternative on one item within a group of images that describes all items in the group + + + +

    Using a text alternative on one item within a group of images that describes all items in the group

    +
    +

    ID: G196

    +

    Technology: general

    +

    Type: Technique

    +
    +
    +

    When to Use

    Any technology where a grouping of non-text content is used to present information or functionality.

    -

    Description

    +
    +
    +

    Description

    The objective of this technique is to avoid unnecessary duplication that occurs when a grouping of adjacent non-text content is used to present information or functionality.

    In some cases, pages will present a group of images to convey information. When presented together or in a specific combination these groupings can convey different types of information. For example, two images of a star where one is presented in black and white and the other is colored can be used in combination to represent a user rating. For example, three filled stars followed by two unfilled stars might represent a rating of three out of five stars.

    To use this technique, an author provides a text alternative that serves the equivalent purpose for the entire group and associates it with one item in the group. The other items in the group are then marked in a way that can be ignored by assistive technologies. In this way, the user is able to more efficiently identify the purpose of the group and can avoid duplication or confusion that may result had a text alternative been provided for each item in the group.

    -

    Examples

    -
    -

    A rating system in HTML

    - -

    In the following example, a rating is shown as three filled stars and two empty stars. While a text alternative could have been provided for each of the five images, the author has instead provided the rating in the form "3 out of 5 stars" for the first image and has marked the others using null alt text.

    - -
    -              <p>Rating: 
    -                <img src="star1" alt="3 out of 5 stars">
    -                <img src="star1" alt="">
    -                <img src="star1" alt="">
    -                <img src="star2" alt="">
    -                <img src="star2" alt="">
    -                </p>
    -            
    +
    +
    +

    Examples

    +
    +

    A rating system in HTML

    +

    In the following example, a rating is shown as three filled stars and two empty stars. While a text alternative could have been provided for each of the five images, the author has instead provided the rating in the form "3 out of 5 stars" for the first image and has marked the others using null alt text.

    +
    <p>Rating: 
    +  <img src="star-filled" alt="3 out of 5 stars">
    +  <img src="star-filled" alt="">
    +  <img src="star-filled" alt="">
    +  <img src="star-empty" alt="">
    +  <img src="star-empty" alt="">
    +</p>
    -

    A button created from a group of images in XHTML

    - -

    In this example, each button has a set of images to indicate the level of conformance to WCAG being claimed. This approach makes it possible for assistive technologies to avoid announcing things like, "Image A, Image A, Image A" etc.

    - -
    -              <p>Conformance Level:</p>
    -                <button name="A"><img src="a.png" alt="A" /></button> <br />
    -                <button name="AA"><img src="a.png" alt="AA" /><img src="a.png" alt="" /></button> <br />
    -                <button name="AAA"><img src="a.png" alt="AAA" /><img src="a.png" alt="" /><img src="a.png" alt="" /></button>
    -            
    +

    Buttons created with groups of images in HTML

    +

    In this example, each button has a set of images to indicate the level of conformance to WCAG being claimed. This approach makes it possible for assistive technologies to avoid announcing things like, "Image A, Image A, Image A" etc.

    +
    <p>Conformance Level:</p>
    +<button name="A" type="button">
    +  <img src="a.png" alt="A">
    +</button>
    +<button name="AA" type="button">
    +  <img src="a.png" alt="AA">
    +  <img src="a.png" alt="">
    +</button>
    +<button name="AAA" type="button">
    +  <img src="a.png" alt="AAA">
    +  <img src="a.png" alt="">
    +  <img src="a.png" alt="">
    +</button>
    -

    Tests

    -

    Procedure

    +
    +
    +

    Tests

    +
    +

    Procedure

    1. Check that one item in the group includes a text alternative that serves the equivalent purpose for the entire group.
    2. Check that the other items in the group are marked in a way that can be ignored by assistive technologies.
    3. @@ -45,8 +67,14 @@

      A button created from a group of images in XHTML

    4. All of the above checks are true.
    -
    + \ No newline at end of file + +
    + + \ No newline at end of file diff --git a/techniques/general/G197.html b/techniques/general/G197.html index b219f50269..49d094146f 100644 --- a/techniques/general/G197.html +++ b/techniques/general/G197.html @@ -1,4 +1,4 @@ -Using labels, names, and text alternatives consistently for content that has the same functionality

    Using labels, names, and text alternatives consistently for content that has the same functionality

    ID: G197

    Technology: general

    Type: Technique

    When to Use

    +Using labels, names, and text alternatives consistently for content that has the same functionality

    Using labels, names, and text alternatives consistently for content that has the same functionality

    ID: G197

    Technology: general

    Type: Technique

    When to Use

    All content.

    Description

    The purpose of this technique is to help users with cognitive disabilities, blindness and vision loss to understand what will happen when they interact with a function on a Web page. If there are different labels on user interface components (i.e., elements, links, JavaScript objects, etc.) that have the same function, the user will not know that they have encountered a component with the same function and will not know what to expect. This could lead to many unnecessary errors. It is also recommended that this approach to consistent labelling be applied across the Web site.

    diff --git a/techniques/general/G198.html b/techniques/general/G198.html index e309474521..cb9d974033 100644 --- a/techniques/general/G198.html +++ b/techniques/general/G198.html @@ -1,4 +1,4 @@ -Providing a way for the user to turn the time limit off

    Providing a way for the user to turn the time limit off

    ID: G198

    Technology: general

    Type: Technique

    When to Use

    +Providing a way for the user to turn the time limit off

    Providing a way for the user to turn the time limit off

    ID: G198

    Technology: general

    Type: Technique

    When to Use

    This technique relates to all technologies.

    Description

    The objective of this technique is to provide a mechanism for people who cannot complete tasks within a specified time limit to turn off the time limit.

    diff --git a/techniques/general/G199.html b/techniques/general/G199.html index d7ec2f6642..5aa48b18dd 100644 --- a/techniques/general/G199.html +++ b/techniques/general/G199.html @@ -1,4 +1,4 @@ -Providing success feedback when data is submitted successfully

    Providing success feedback when data is submitted successfully

    ID: G199

    Technology: general

    Type: Technique

    When to Use

    +Providing success feedback when data is submitted successfully

    Providing success feedback when data is submitted successfully

    ID: G199

    Technology: general

    Type: Technique

    When to Use

    Content that accepts user data input.

    Description

    The objective of this technique is to reduce the effort required for users to confirm that an action, such as submitting a Web form, was completed successfully. This can be accomplished by providing consistently presented feedback that explicitly indicates success of an action, rather than requiring a user to navigate through content to discover if the action was successful.

    diff --git a/techniques/general/G200.html b/techniques/general/G200.html index 5d31cc2e78..09abe57f3d 100644 --- a/techniques/general/G200.html +++ b/techniques/general/G200.html @@ -1,4 +1,4 @@ -Opening new windows and tabs from a link only when necessary

    Opening new windows and tabs from a link only when necessary

    ID: G200

    Technology: general

    Type: Technique

    When to Use

    +Opening new windows and tabs from a link only when necessary

    Opening new windows and tabs from a link only when necessary

    ID: G200

    Technology: general

    Type: Technique

    When to Use

    Pages that open new windows

    Description

    The objective of this technique is to limit the use of links or buttons that open new windows or tabs within Web content. In general, it is better not to open new windows and tabs since they can be disorienting for people, especially people who have difficulty perceiving visual content. However there are some situations where it is preferable from an accessibility perspective to open a new window or tab. Here are two such situations:

    @@ -31,9 +31,6 @@

    Date Picker

  • SCR24
  • Resources

    -

    - Beware of opening links in a new window -

    diff --git a/techniques/general/G201.html b/techniques/general/G201.html index fd0406f37a..beeef742fd 100644 --- a/techniques/general/G201.html +++ b/techniques/general/G201.html @@ -1,7 +1,23 @@ -Giving users advanced warning when opening a new window

    Giving users advanced warning when opening a new window

    ID: G201

    Technology: general

    Type: Technique

    When to Use

    + + + + Giving users advanced warning when opening a new window + + + +

    Giving users advanced warning when opening a new window

    +
    +

    ID: G201

    +

    Technology: general

    +

    Type: Technique

    +
    +
    +

    When to Use

    Pages that open new windows

    -

    Description

    -

    The objective of this technique is to provide a warning before automatically +

    +
    +

    Description

    +

    The objective of this technique is to provide a warning before automatically opening a new window or tab. Opening new windows automatically when a link is activated can be disorienting for people who have difficulty perceiving visual content, and for some people with cognitive disabilities, @@ -11,17 +27,16 @@ to go to the new window. It will help them understand that the "back" button will not work and that they have to return to the last window they had open, in order to find their previous location.

    -

    Examples

    -
    -

    Including the warning in the text describing a control

    - -

    The name or label that describes a control can include the warning +

    +
    +

    Examples

    +
    +

    Including the warning in the text describing a control

    +

    The name or label that describes a control can include the warning about opening in a new window.

    - -
    -              <a href="knitting.html" target="_blank">All about Knitting 
    -                (opens in new window)</a>
    -            
    +
    <a href="knitting.html" rel="noopener" target="_blank">
    +  All about Knitting (opens in new window)
    +</a>

    Using CSS to provide a warning before opening a new window

    @@ -29,82 +44,75 @@

    Using CSS to provide a warning before opening a new window

    The code below uses CSS to provide a warning before opening a new window.

    -
    -              <html>
    -                <head>
    -                <title>Pop-Up Warning</title>
    -                <style type="text/css">
    -                body {
    -                margin-left:2em;
    -                margin-right:2em;
    -                }
    -                :focus { outline: 0; }
    -                a.info {
    -                position:relative;
    -                z-index:24;
    -                background-color:#ccc;
    -                color:#000;
    -                text-decoration:none
    -                }
    -                a.info:hover, a.info:focus, a.info:active {
    -                z-index:25;
    -                background-color:#ff0
    -                }
    -                a.info span {
    -                position: absolute;
    -                left: -9000px;
    -                width: 0;
    -                overflow: hidden;
    -                }
    -                a.info:hover span, a.info:focus span, a.info:active span {
    -                display:block;
    -                position:absolute;
    -                top:1em; left:1em; width:12em;
    -                border:1px solid #0cf;
    -                background-color:#cff;
    -                color:#000;
    -                text-align: center
    -                }
    -                div.example {
    -                margin-left: 5em;
    -                }
    -                </style>
    -                </head>
    -                <body>
    -                <h1>Pop-Up Warning</h1>
    -                <p> This is an example of an <a class="info"
    -                href="popup_advisory_technique.html" target="_blank">
    -                <strong>External link</strong><span>Opens a new
    -                window</span></a>
    -                </p>
    -                </body>
    -                </html>
    -            
    +
    <!DOCTYPE html>
    +<html lang="en">
    +<head>
    +  <meta charset="utf-8">
    +  <title>Link opens in new window notification</title>
    +  <style>
    +    body {
    +      background:#fff;
    +      color: #000;
    +      font: 1rem/1.5 system-ui, "Segoe UI", Roboto, Helvetica, sans-serif;
    +    }
    +
    +    [hidden] {
    +      display:none;
    +    }
    +
    +    .new-window-icon {
    +      fill:currentColor;
    +      height:0.75rem;
    +      margin-inline-start:0.3em;
    +      vertical-align:middle;
    +      width:0.75rem;
    +    }
    +  </style>
    +</head>
    +<body>
    +  <svg hidden>
    +    <symbol id="new-window-icon" viewBox="0 0 12 12">
    +      <title id="new-win-desc">opens in a new window</title>			
    +      ...
    +    </symbol>
    +  </svg>
    +
    +  <h1>Link opens in new window notification</h1>
    +  <p>This is an example of an 
    +     <a aria-describedby="new-win-desc" href="https://example.com" rel="noopener" 
    +     target="_blank">external link<svg class="new-window-icon" aria-hidden="true"
    +     role="img"><use href="#new-window-icon"></use></svg></a></p>
    +  </body>
    +</html>
    -

    A - working - example of Using CSS to provide a warning before opening a new window - is available.

    +

    A working example of Using CSS to provide a warning before opening a new window is available.

    -

    Tests

    -

    Procedure

    -

    For each link that opens automatically in a new window or tab when - a change of context is initiated by a user request:

    +
    +
    +

    Tests

    +
    +

    Procedure

    +

    For each link that opens automatically in a new window or tab when a change of context is initiated by a user request:

      -
    1. Check that there is a warning spoken in assistive technology that - this link opens to a new window.
    2. -
    3. Check that there is a visual warning in text that this link opens - to a new window.
    4. +
    5. Check that there is a warning spoken in assistive technology that this link opens to a new window.
    6. +
    7. Check that there is a visual warning in text that this link opens to a new window.
    -

    Expected Results

    +
    +

    Expected Results

    • Checks #1 and check #2 are true.
    -
    \ No newline at end of file +
    + + + \ No newline at end of file diff --git a/techniques/general/G202.html b/techniques/general/G202.html index 51d0020da8..1fc06a8556 100644 --- a/techniques/general/G202.html +++ b/techniques/general/G202.html @@ -1,4 +1,4 @@ -Ensuring keyboard control for all functionality

    Ensuring keyboard control for all functionality

    ID: G202

    Technology: general

    Type: Technique

    When to Use

    +Ensuring keyboard control for all functionality

    Ensuring keyboard control for all functionality

    ID: G202

    Technology: general

    Type: Technique

    When to Use

    All technologies that support interactive operation.

    Description

    The objective of this technique is to provide keyboard operation for all the functionality of the page. When all functionality of content can be operated through a keyboard or keyboard interface, it can be operated by those with no vision as well as by those who must use alternate keyboards or input devices that act as keyboard emulators like speech input software or on-screen keyboards.

    diff --git a/techniques/general/G203.html b/techniques/general/G203.html index f2887b0df2..630e9443b0 100644 --- a/techniques/general/G203.html +++ b/techniques/general/G203.html @@ -1,4 +1,4 @@ -Using a static text alternative to describe a talking head video

    Using a static text alternative to describe a talking head video

    ID: G203

    Technology: general

    Type: Technique

    When to Use

    +Using a static text alternative to describe a talking head video

    Using a static text alternative to describe a talking head video

    ID: G203

    Technology: general

    Type: Technique

    When to Use

    Videos of only a speaker

    Description

    The purpose of this technique is to provide an alternative to audio description for synchronized media that has no important time based information contained in the video portion of the media. This particularly applies to "talking head" videos where a person is talking in front of an unchanging background, such as a press conference, company president talk, or government announcement, etc. In this case there are no "important visual details" which would warrant audio description. @@ -13,9 +13,9 @@

    A video of a CEO speaking to shareholders

    -

    A CEO is speaking to shareholders from his office. The video has a title page at the beginning of the video giving the date. When the speaker begins, there is a strip of text at the bottom of the video saying "John Doe, President of XYZ Cooperation". At the end of the video are title credits that say "produced by the Honest TV Productions Ltd." +

    A CEO is speaking to shareholders from their office. The video has a title page at the beginning of the video giving the date. When the speaker begins, there is a strip of text at the bottom of the video saying "Jane Doe, President of XYZ Cooperation". At the end of the video are title credits that say "produced by the Honest TV Productions Ltd."

    -

    As an alternative, there is a paragraph below the video which is associated with the video file using aria-describedby which says: "July 22, 2011, John Doe, President of XYZ cooperation, speaking from his office. Video produced by the Honest TV Productions Ltd." +

    As an alternative, there is a paragraph below the video which is associated with the video file using aria-describedby which says: "July 22, 2011, Jane Doe, President of XYZ cooperation, speaking from her office. Video produced by the Honest TV Productions Ltd."

    diff --git a/techniques/general/G204.html b/techniques/general/G204.html index 18670516be..0c38405e2c 100644 --- a/techniques/general/G204.html +++ b/techniques/general/G204.html @@ -1,8 +1,8 @@ -Not interfering with the user agent's reflow of text as the viewing window is narrowed

    Not interfering with the user agent's reflow of text as the viewing window is narrowed

    ID: G204

    Technology: general

    Type: Technique

    When to Use

    +Not interfering with the user agent's reflow of text as the viewing window is narrowed

    Not interfering with the user agent's reflow of text as the viewing window is narrowed

    ID: G204

    Technology: general

    Type: Technique

    When to Use

    All technologies

    Description

    This technique helps avoid situations where horizontal scrolling may occur. Many people with cognitive disabilities and low vision users who do not use assistive technology have a great deal of trouble with blocks of text that require horizontal scrolling. It involves not interfering with the reflow of text if the window is narrowed. One of the best ways to do this is to define widths of text block containers in percentages.

    -

    HTML and XHTML user agents automatically reflow text as the browser window is narrowed as long as the author does not specify widths using absolute measurements such as pixels or points.

    +

    HTML user agents automatically reflow text as the browser window is narrowed as long as the author does not specify widths using absolute measurements such as pixels or points.

    Examples

    @@ -29,8 +29,8 @@
    \ No newline at end of file diff --git a/techniques/general/G205.html b/techniques/general/G205.html index 2f4cdf49d1..9416011366 100644 --- a/techniques/general/G205.html +++ b/techniques/general/G205.html @@ -1,35 +1,60 @@ -Including a text cue for colored form control labels

    Including a text cue for colored form control labels

    ID: G205

    Technology: general

    Type: Technique

    When to Use

    + + + + Including a text cue for colored form control labels + + + +

    Including a text cue for colored form control labels

    +
    +

    ID: G205

    +

    Technology: general

    +

    Type: Technique

    +
    +
    +

    When to Use

    All technologies that support color and text.

    -

    Description

    +
    +
    +

    Description

    The objective of this technique is to combine color and text or character cues to convey information. Most users can quickly scan the content to locate information conveyed by using color differences. Users who cannot see color can look or listen for text cues; people using Braille displays or other tactile interfaces can detect text cues by touch.

    The text cue must be included as part of the programmatically determinable name for the control.

    -

    Examples

    +
    +
    +

    Examples

    -

    Required fields in an HTML form

    - -

    The instructions for an online form say, "Required fields are shown in red and marked with (required)." The cue "(required)" is included within the label element.

    - -
    <label for="lastname" class="required">Last name (required): </label>
    -<input id="lastname" type="text" size="25" value=""/>
    -<style type="text/css">
    +				

    Required fields in an HTML form

    +

    The instructions for an online form say, "Required fields are shown in red and marked with (required)." The cue "(required)" is included within the label element.

    +
    <style>
       .required {
    -    color:red;
    +    color:#ec0000;
       }
    -</style>
    +</style> +<label for="lastname" class="required">Last name (required):</label> +<input autocomplete="family-name" id="lastname" type="text" value="">

    Tests

    Procedure

    -

    For any content where color differences are used to convey information: -

    +

    For any content where color differences are used to convey information:

    1. Check that the same information is available through text or character cues.
    -

    Expected Results

    -
      -
    • Check #1 is true.
    • -
    -
    -

    Resources

    \ No newline at end of file +
    +

    Expected Results

    +
      +
    • Check #1 is true.
    • +
    +
    +
    + +
    +

    Resources

    +
    + + \ No newline at end of file diff --git a/techniques/general/G206.html b/techniques/general/G206.html index 2d8347efa8..44dd2f0d16 100644 --- a/techniques/general/G206.html +++ b/techniques/general/G206.html @@ -1,11 +1,11 @@ -Providing options within the content to switch to a layout that does not require the user to scroll horizontally to read a line of text

    Providing options within the content to switch to a layout that does not require the user to scroll horizontally to read a line of text

    ID: G206

    Technology: general

    Type: Technique

    When to Use

    +Providing options within the content to switch to a layout that does not require the user to scroll horizontally to read a line of text

    Providing options within the content to switch to a layout that does not require the user to scroll horizontally to read a line of text

    ID: G206

    Technology: general

    Type: Technique

    When to Use

    All technologies that support style switching

    Description

    There may be situations where an author needs to use a layout that requires horizontal scrolling. In that case, it is sufficient to provide options within the content that switch to a layout that does not require the user to scroll horizontally to read a line of text. This may be achieved using standard style switching technology.

    It should be noted that it is also sufficient to lay out the content in such a way that horizontal scrolling is required to access content, but that it is not necessary to scroll horizontally in order to read a line of text.

    For instance, a spreadsheet that requires horizontal scrolling is acceptable if no horizontal scrolling is necessary for each column individually (i.e., scrolling is only necessary to see other columns, but not for the left or right edges of each individual column).

    -

    This technique can be used in combination with a style switching technique to present a page that is a conforming alternate version for non-conforming content. Refer to C29: Using a style switcher to provide a conforming alternate version and Understanding Conforming Alternate Versions for more information.

    +

    This technique can be used in combination with a style switching technique to present a page that is a conforming alternate version for non-conforming content. Refer to C29: Using a style switcher to provide a conforming alternate version and Understanding Conforming Alternate Versions for more information.

    Examples

    diff --git a/techniques/general/G207.html b/techniques/general/G207.html index 399be5a865..79a02ec380 100644 --- a/techniques/general/G207.html +++ b/techniques/general/G207.html @@ -18,33 +18,33 @@

    When to Use

    Description

    -

    The objective of this technique is to ensure graphical icons provide enough contrast for people with vision impairments. Not all graphics are within the scope of SC 1.4.11 Non-text contrast but if the icons are required to understand the content, then the icons need to have a contrast ratio of at least 3:1.

    -

    The success criteria for non-text contrast uses the term "graphical object" to cover small simple graphics, and parts of larger complex graphics. This technique focuses on solid color icons used on solid or gradient backgrounds.

    +

    The objective of this technique is to ensure graphical icons provide enough contrast for people with vision impairments. Not all graphics are within the scope of SC 1.4.11 Non-text contrast but if the icons are required to understand the content, then the icons need to have a contrast ratio of at least 3:1.

    +

    The success criteria for non-text contrast uses the term "graphical object" to cover small simple graphics, and parts of larger complex graphics. This technique focuses on solid color icons used on solid or gradient backgrounds.

    When choosing the colors for graphics, consider the color(s) adjacent to that graphic, and test that the contrast ratio is at least 3:1.

    -

    A selection of tools and applications for testing contrast ratios can be found in Understanding SC 1.4.3 Contrast (minimum).

    +

    A selection of tools and applications for testing contrast ratios can be found in Understanding SC 1.4.3 Contrast (minimum).

    Examples

    Solid icon color against the background

    A solid icon such as a telephone symbol uses orange on a white background. The color orange (#E3660E) is tested against the white background (#FFFFFF) and it has a contrast ratio of 3.4:1.

    -

    Orange icon on white background

    +

    Orange icon on white background

    Solid icon color against a custom background

    A solid icon such as a telephone symbol used within an orange background. The orange and white colors are the same as in example 1, in this case the contrast against the white background is not relevant, the white icon within the orange background is what provides the information in the icon and as a result needs to meet the contrast requirement.

    -

    Orange icon on white background

    +

    Orange icon on white background

    Solid icon with a gradient background

    A solid icon such as a telephone symbol using a dark blue icon on a white-to-blue gradient background. The first test of the icon should be against the darkest (least contrasting) background that is adjacent to the icon color. If that is at least 3:1, it passes the success criterion.

    -

    Dark blue icon on white-to-blue background.

    +

    Dark blue icon on white-to-blue background.

    Solid icon with gradient background overlapping in contrast

    A solid icon on a gradient background can overlap in contrast if the graphic is still understandable where it does not have contrast against all of the background. If you find the part of the gradient where it does not meet a 3:1 ratio with the graphic and treat that part as if it was removed, does the icon still convey the appropriate meaning?

    A method of visualizing this is to remove the non-contrasting area and check that you can still understand the icon. If so, it is sufficient. The images below shows an icon on a gradient background, and a second version where it removes the area of the icon that does not meet the 3:1 contrast ratio. It is still recognizable as a phone icon, so passes the success criterion.

    -

    Dark blue icon on white-to-blue background that is dark at the bottom. Dark blue icon on white-to-blue background.

    +

    Dark blue icon on white-to-blue background that is dark at the bottom. Dark blue icon on white-to-blue background.

    @@ -77,7 +77,7 @@

    Related Techniques

    Resources

    diff --git a/techniques/general/G208.html b/techniques/general/G208.html index 8bbf01a779..298a5961ba 100644 --- a/techniques/general/G208.html +++ b/techniques/general/G208.html @@ -47,7 +47,7 @@

    Generic link text concatenated with heading

    A generic link is combined with the heading of the paragraph to give context. It is a variation on the first example, this time using aria-labelledby. The advantage of this implementation is that it uses existing visible text on the page, and so is more likely to be properly translated during any localization transformations.

    - <h4 id="poor">Insufficient Link Names Invade Community</h4>
    + <h4 id="poor">Insufficient Link Names Invade Community</h4>
    <p>Citizens are reeling from the growing invasion of useless "read more" links appearing in their online resources. <a href="poor.html" aria-labelledby="generic poor"><span id="generic">More...</span></a>
    @@ -96,11 +96,11 @@

    Expected Results

    diff --git a/techniques/general/G209.html b/techniques/general/G209.html index 8de80237d0..6484151504 100644 --- a/techniques/general/G209.html +++ b/techniques/general/G209.html @@ -27,28 +27,28 @@

    Examples

    Pie chart with alternative light/dark colors

    - Pie chart of favorite candy flavours, including text labels and contrasting segments. + Pie chart of favorite candy flavours, including text labels and contrasting segments.
    The contrast between adjoining segments of the pie chart range from 5.8 to 9.4.

    Pie chart with borders between segments

    - Pie chart of favorite candy flavours, including text labels and contrasting borders between segments. + Pie chart of favorite candy flavours, including text labels and contrasting borders between segments.
    The contrast between the segments of the pie chart range from 1.1 to 1.8. A border has been added with at least a 3:1 contrast ratio with the colors to distinguish between segments. .

    Map with border boundaries

    - Map showing simple regions with dark background colours and a light border between regions. + Map showing simple regions with dark background colours and a light border between regions.
    The color contrast of areas within the map range between 1.3 and 1.8. A boundary line is added with a color contrast ratio of at least 3:1 with the area colors.

    Pie chart with black and white borders

    - Pie chart of favorite candy flavours, including text labels and black and white borders between segments. + Pie chart of favorite candy flavours, including text labels and black and white borders between segments.
    The colored areas in the chart are both dark and light. A black and white boundary line is added to ensure sufficient contrast between both light and dark colors.
    @@ -79,13 +79,13 @@

    Expected Results

    Resources

    diff --git a/techniques/general/G21.html b/techniques/general/G21.html index 0e655567c4..6b23ba5c8a 100644 --- a/techniques/general/G21.html +++ b/techniques/general/G21.html @@ -1,4 +1,4 @@ -Ensuring that users are not trapped in content

    Ensuring that users are not trapped in content

    ID: G21

    Technology: general

    Type: Technique

    When to Use

    +Ensuring that users are not trapped in content

    Ensuring that users are not trapped in content

    ID: G21

    Technology: general

    Type: Technique

    When to Use

    All technologies which support interactive operation.

    Description

    The objective of this technique is to ensure that keyboard users do not become trapped in a subset of the content that can only be exited using a mouse or pointing device. A common example is content rendered by plug-ins. Plug-ins are user agents that render content inside the user agent host window and respond to all user actions that takes place while the plug-in has the focus. If the plug-in does not provide a keyboard mechanism to return focus to the parent window, users who must use the keyboard may become trapped in the plug-in content.

    diff --git a/techniques/general/G211.html b/techniques/general/G211.html index cfd2352cf1..cf948ee9d8 100644 --- a/techniques/general/G211.html +++ b/techniques/general/G211.html @@ -14,79 +14,80 @@

    Metadata

    When to Use

    -

    This technique applies to all web technologies that include interactive controls (such as links or form inputs).

    +

    This technique applies to all web technologies that include interactive controls (such as links or form inputs).

    Description

    -

    The objective of this technique is to ensure that speech input users can operate web content reliably while not adversely affecting other users of assistive technology.

    +

    The objective of this technique is to ensure that speech input users can operate web content reliably while not adversely affecting other users of assistive technology.

    When speech input users interact with a web page, they usually speak a command followed by the reference to some visible label (such as text beside an input field or inside a button or link). For example, they may say "click search" to activate a button labelled Search. When speech recognition software processes speech input and looks for matches, it uses the accessible name of controls. Where there is a mismatch between the text in the label and the text in the accessible name, it can cause issues for the user. The simplest way to enable speech input users and meet 2.5.3 Label in Name is to ensure that the accessible name matches the visible text label.

    Determining the appropriate label

    Sometimes more than one text string will be positioned in the vicinity of a control that could be considered a candidate for its label. For example, a set of inputs that each have their own labels may also be preceded by a heading, an instruction or a group label (such as an HTML legend/fieldset or an ARIA group or radiogroup). Note that the term "group label" means something different than "label", both programmatically and in regard to 2.5.3 Label in Name.

    -

    The Understanding 2.5.3 Label in Name document recommends that only the text string adjacent to or in close proximity to an input should be treated as the label when assessing a control's label for the purposes of meeting 2.5.3 (see the section "Identifying label text for components"). There are both practical and technical reasons for restricting the designation of an input's label in this way. The technical reasons are discussed in the Understanding document's section called Accessible Name and Description Computation specification.

    +

    The Understanding 2.5.3 Label in Name document recommends that only the text string adjacent to or in close proximity to an input should be treated as the label when assessing a control's label for the purposes of meeting 2.5.3 (see the section "Identifying label text for components"). There are both practical and technical reasons for restricting the designation of an input's label in this way. The technical reasons are discussed in the Understanding document's section called Accessible Name and Description Computation specification.

    Examples

    -

    Mapping a visible label to the accessible name is achieved in many technologies by meeting 1.3.1 Information and Relationships through the proper use of native semantics. Many controls derive accessible names by correct nesting of elements, while other elements have specific attributes which are a valid means of providing or referencing an accessible name.

    +

    Mapping a visible label to the accessible name is achieved in many technologies by meeting 1.3.1 Information and Relationships through the proper use of native semantics. Many controls derive accessible names by correct nesting of elements, while other elements have specific attributes which are a valid means of providing or referencing an accessible name.

    The accessible name should be assigned through native elements and semantics where possible. That helps ensure an exact match between the visible label and name.

    Anchor text provides both the link's label and its accessible name

    -

    Using conventional HTML, the text between the anchor element's tags provides both the link's visible text and the accessible name "Code of conduct":

    - <p>Go to our <a href="url-to-page-about-code.html">Code of conduct</a></p> +

    Using conventional HTML, the text between the a element's tags provides both the link's visible text and the accessible name "Code of conduct":

    + <p>Go to our <a href="url-to-page-about-code.html">Code of conduct</a></p>

    Non-working sample of anchor

    Go to our Code of conduct

    -

    Text in label element provides name for input via for attribute

    -

    The text between the label tags also serves as the checkbox input's accessible name "Notify me of delays" by using the for attribute which references the id of the input.

    - - <input type="checkbox" id="notification" name="notify" value="delays">
    - <label for="notification">Notify me of delays</label> -
    -
    -

    Working sample of input

    - - -
    + +

    Text in label element provides name for input via for attribute

    +

    The text between the label tags also serves as the checkbox input's accessible name "Notify me of delays" by using the for attribute which references the id of the input.

    +
    <input type="checkbox" id="notification" name="notify" value="delays">
    +<label for="notification">Notify me of delays</label>
    +
    +
    +

    Working sample of input

    + + +

    The button text provides the accessible name

    -

    The text inside a button element becomes both its visible label and its accessible name:

    - <button>Send</button>
    -
    -

    Non-working sample of button

    - -
    + +

    The text inside a button element becomes both its visible label and its accessible name:

    + <button>Send</button> +
    +

    Non-working sample of button

    + +
    -

    Simple Radio Button Group

    +

    Simple Radio Button Group

    Radio buttons typically appear in a group, where each button is labelled and the group of buttons is preceded by information which explains or categorizes the group.

    - Call me when balance exceeds $10,000, Yes No + Call me when balance exceeds $10,000, Yes No
    Figure 1 "Call me when balance exceeds $10,000 radio group, with Yes and No choices
    -

    The label for each component should be restricted to "Yes" and "No". To meet 1.3.1 Information and Relationships and 3.3.2 Labels or Instructions, the "Call me…" text can be coded to convey the relationship to ATs, in this example by using a fieldset and legend.

    +

    The label for each component should be restricted to "Yes" and "No". To meet 1.3.1 Information and Relationships and 3.3.2 Labels or Instructions, the "Call me…" text can be coded to convey the relationship to ATs, in this example by using a fieldset and legend.

    If the label is not restricted to the string adjacent to the radio button, multiple interpretations of what constitutes the label can result in less uniform functionality. If "Yes" alone is not the label for the first radio button, is it "Call me when balance exceeds $10,000"? Or is it a combination of text strings, in which case is the order "Call me when balance exceeds $10,000 Yes" or "Yes, Call me when balance exceeds $10,000"? Decisions to combine text strings can have negative effects on screen reader users since the order of concatenation can affect meaning. In this example, "No, call me when balance exceeds $10,000" could be very confusing to a screen reader user.

    - <fieldset>
    - <legend>Call me when balance exceeds $10,000?</legend><br />
    - <input type="radio" id="yes" name="callme" value="yes">
    - <label for="yes">Yes</label>
    - <input type="radio" id="no" name="callme" value="no">
    - <label for="no">No</label>
    - </fieldset>
    + <fieldset>
    + <legend>Call me when balance exceeds $10,000?</legend><br />
    + <input type="radio" id="yes" name="callme" value="yes">
    + <label for="yes">Yes</label>
    + <input type="radio" id="no" name="callme" value="no">
    + <label for="no">No</label>
    + </fieldset>
    -

    Working example of Simple Radio Button Group

    +

    Working example of Simple Radio Button Group

    -

    Checkbox Groupings

    +

    Checkbox Groupings

    For checkbox groupings, implementations that attempt to incorporate more than just the immediate checkbox label into the accessible name can also be problematic if not isolated to the adjacent text string.

    - What do you value in our service? (Check all that apply) Courtesy, Promptness, Store Hours, Knowledge + What do you value in our service? (Check all that apply) Courtesy, Promptness, Store Hours, Knowledge
    Figure 2 What do you value in our service? checkbox group, with 4 choices.
    @@ -94,62 +95,98 @@

    Checkbox Groupings

    Attempting to include the preceding text as part of the accessible name can potentially make it more difficult to isolate a control by spoken commands for speech-input users. Such a construction will also negatively increase verbosity for screen reader users (with the combined text strings read out for each of the inputs before the input's state). The simplest solution is to restrict the accessible name to the text immediately beside the checkboxes, using similar techniques to those for the standard radio button group.

    -

    Stacked Labels

    +

    Stacked Labels

    Although labels for comboboxes, dropdown lists, text inputs, and other widgets are typically oriented immediately to the left of the component, there is an alternative established convention where labels are stacked above the inputs, aligned with their left edge.

    - two inputs labelled Email and Password + + two inputs labelled Email and Password +
    Figure 3 Two inputs with the labels positioned above and to the left.

    In Figure 3, the inputs are stacked and left-aligned, with the labels immediately preceding each input, also left-aligned. There is additional white space between the label and the preceding input so that the label is closest to its associated text input. Stacked labels are relatively common in mobile designs, where horizontal space is constrained.

    -

    Figure 4 shows a variation on stacked labels, where hints and guidance are included between the label and the input. This design does not provide an adjacent label. However, the "New Password" label is still considered to be in close enough proximity, especially given its size and boldness relative to the smaller and lower-contrast guidance text. The associations are reinforced programmatically, where the hint text is given a role of aria-describedby and the label is properly associated with the input.

    +

    Figure 4 shows a variation on stacked labels, where hints and guidance are included between the label and the input. This design does not provide an adjacent label. However, the "New Password" label is still considered to be in close enough proximity, especially given its size and boldness relative to the smaller and lower-contrast guidance text. The associations are reinforced programmatically, where the hint text is given a role of aria-describedby and the label is properly associated with the input.

    - New Password. Passwords must be 10 or more characters, and contain at least one capital, numeric and non-alphanumeric.' + New Password. Passwords must be 10 or more characters, and contain at least one capital, numeric and non-alphanumeric.'
    Figure 4 New Password label positioned above input with a smaller-point text string about the password requirements positioned between the large label and the input.

    The hint text in such implementations should be kept to a single line where possible, since accessibility issues can arise where a more lengthy hint separates the label from its input. Figure 4 illustrates that the concept of "adjacent text" is a guide for label interpretation, but cannot always serve as a hard rule.

    - <form>
    - <label class="label" for="example-2">
    - Password
    - </label>
    - <span id="example-2-hint" class="hint">
    - Passwords must be 10 or more characters, and contain at least one capital, numeric and non-alphanumeric.
    - </span>
    - <input class="input" id="example-2" name="example-2" type="text" aria-describedby="example-2-hint">
    - </form>
    + <form>
    + <label class="label" for="example-2">
    + Password
    + </label>
    + <span id="example-2-hint" class="hint">
    + Passwords must be 10 or more characters, and contain at least one capital, numeric and non-alphanumeric.
    + </span>
    + <input class="input" id="example-2" name="example-2" type="text" aria-describedby="example-2-hint">
    + </form>
    -

    Working example of stacked labels

    +

    Working example of stacked labels

    +
    -
    -

    Range of inputs with few labels

    +

    Range of inputs with few labels

    A less common disparity between labels and inputs can occur when a group of radio buttons is set up to elicit a choice across a range. The labels may only be located at each end of the range or may be interspersed at various points in the range.

    - Rate your response, Hated it, Loved it + Rate your response, Hated it, Loved it
    Figure 6 Line of 5 radio buttons with Hated it and Loved it labels at each end
    -

    The two labels, "Hated it" and "Loved it", are adjacent to the first and last radio buttons, and should be their accessible names. Speech-input users can speak either of these labels to select a radio button, and then use arrow navigation (e.g., "Press right arrow") to modify the selection. "Rate your response" is the text describing the whole widget and can be associated as the group label (here using legend). The three middle radio buttons do not have visible labels. In the code example they are given title attributes of "Disliked", "So-so" and "Liked" in order to meet 3.3.2 Labels or Instructions.

    +

    The two labels, "Hated it" and "Loved it", are adjacent to the first and last radio buttons, and should be their accessible names. Speech-input users can speak either of these labels to select a radio button, and then use arrow navigation (e.g., "Press right arrow") to modify the selection. "Rate your response" is the text describing the whole widget and can be associated as the group label (here using legend). The three middle radio buttons do not have visible labels. In the code example they are given title attributes of "Disliked", "So-so" and "Liked" in order to meet 3.3.2 Labels or Instructions.

    +
    <fieldset>
    +  <legend>Rate your response</legend>
    +  <label for="hated">Hated it</label>
    +  <input type="radio" name="meal" id="hated" value="hated">
    +  <input type="radio" name="meal" id="poor" value="poor" title="Disliked">
    +  <input type="radio" name="meal" id="neutral" value="neutral" title="So-so">
    +  <input type="radio" name="meal" id="okay" value="okay" title="Liked">
    +  <input type="radio" name="meal" id="loved" value="loved">
    +  <label for="loved">Loved it</label>
    +</fieldset>
    +
    +

    Working example of range of inputs

    +
    + +
    +

    Text in parentheses and punctuation

    +

    Technique G211 is not intended to complicate existing conventions for the construction of accessible form inputs. As described in the Punctuation and capitalization and Text in parentheses subsections of the Understanding document, information does not always need to be included in the accessible name in an attempt to meet the Label in Name requirement, especially where the text would not normally be spoken when using speech recognition to navigate to controls. Where there are established ways of ensuring information and relationships conveyed visually are present programmatically, it is acceptable to leave text in parentheses and punctuation out of the accessible name.

    +

    The following snippet demonstrates possible techniques mentioned in the Understanding document. Since the required field is programmatically indicated, and the input restrictions on the date are surfaced through aria-describedby, the asterisk and parenthetical information has been left out of the accessible name.

    + +
    
    +<label for="name">Name</label> *
    +<input type="text" name="name" id="name" required>
    +<label for="birth">Birth date</label> <span id="mask">(YYYY-MM-DD)</span>
    +<input type="text" name="birth" id="birth" aria-describedby="mask">
    + +
    +

    Working sample of inputs with simplified accessible names

    + + +
    *
    + +
    (YYYY-MM-DD)
    + +

    - <fieldset>
    <legend>Rate your response</legend>
    - <label for="hated">Hated it</label>
    - <input type="radio" name="meal" id="hated" value="hated">
    - <input type="radio" name="meal" id="poor" value="poor" title="Disliked">
    - <input type="radio" name="meal" id="neutral" value="neutral" title="So-so">
    - <input type="radio" name="meal" id="okay" value="okay" title="Liked">
    - <input type="radio" name="meal" id="loved" value="loved">
    - <label for="loved">Loved it</label>
    -</fieldset>
    + <fieldset>
    <legend>Rate your response</legend>
    + <label for="hated">Hated it</label>
    + <input type="radio" name="meal" id="hated" value="hated">
    + <input type="radio" name="meal" id="poor" value="poor" title="Disliked">
    + <input type="radio" name="meal" id="neutral" value="neutral" title="So-so">
    + <input type="radio" name="meal" id="okay" value="okay" title="Liked">
    + <input type="radio" name="meal" id="loved" value="loved">
    + <label for="loved">Loved it</label>
    +</fieldset>

    -

    Working example of range of inputs

    +

    Working example of range of inputs

    +
    -

    Tests

    @@ -157,9 +194,9 @@

    Tests

    Procedure

    1. For input controls, examine each input that has adjacent text which serves as its label
    2. -
    3. For each input, check that the entire string of text (disregarding letter case and punctuation) matches the accessible name for the input, according to the accessible name computation
    4. +
    5. For each input, check that the label's entire string of text (optionally disregarding letter case, punctuation, and information in parentheses) matches the accessible name for the input, according to the accessible name computation
    6. For buttons, links, menus and other non-input controls, examine each control that contains text which serves as its label
    7. -
    8. For each non-input control, check that the entire string of text (disregarding letter case and punctuation) matches the accessible name for the input
    +
  • For each non-input control, check that the label's entire string of text (optionally disregarding letter case, punctuation and information in parentheses) matches the accessible name for the input
  • Expected Results

    @@ -170,21 +207,18 @@

    Expected Results

    Resources

    -

    Provide links to external resources that are relevant to users of the technique. This section is optional.

    diff --git a/techniques/general/G212.html b/techniques/general/G212.html index 89751b935a..a88807fb4e 100644 --- a/techniques/general/G212.html +++ b/techniques/general/G212.html @@ -8,7 +8,6 @@

    Using native controls to ensure functionality is triggered on the up-event.

    Metadata

    -

    Provide information below to help editors associate the technique properly. Contents of the meta section are not output by the processor.

    2.5.2 Pointer Cancellation

    Sufficient

    @@ -38,7 +37,7 @@

    Using a native button or link in HTML

    Using a native button in iOS or Android

    In native buttons in iOS and Android onclick events are triggered on the up-event by default.

    -

    The WCAG standard itself applies to web pages at a URL, and therefore this example is provided as helpful supplementary advice for those looking to implement the WCAG2ICT for native applications.

    +

    The WCAG standard itself applies to web pages, and therefore this example is provided as helpful supplementary advice for those looking to implement the WCAG2ICT for native applications.

    @@ -50,7 +49,7 @@

    Procedure

    1. Activate the down-event then move the pointer outside the target before triggering the up-event, and then release the pointer to trigger the up-event.
    2. Check that the action was not triggered when the pointer is released outside of the hit area for the target.
    3. -
    4. If the action is triggered, check that the action is reversible.
    5. +
    6. If the action is triggered, check that the action is reversible.
    diff --git a/techniques/general/G214.html b/techniques/general/G214.html index bf7d046a54..6afdc4a9a0 100644 --- a/techniques/general/G214.html +++ b/techniques/general/G214.html @@ -2,7 +2,6 @@ Using a control to allow access to content in different orientations which is otherwise restricted -

    Using a control to allow access to content in different orientations which is otherwise restricted

    @@ -24,7 +23,7 @@

    Description

    Examples

    An e-Reader application

    -

    Users of an e-Reader web application sometimes read when laying down on their side. In this situation, the device is viewed by the user in portrait mode even though the device is in the landscape orientation with regard to gravity. The developer locks the content into the portrait orientation to allow for this reading behavior, but also provides a control to allow users who have devices mounted in a specific orientation to achieve the desired viewing orientation.

    +

    Users of an e-Reader web application sometimes read when lying down on their side. In this situation, the device is viewed by the user in portrait mode even though the device is in the landscape orientation with regard to gravity. The developer locks the content into the portrait orientation to allow for this reading behavior, but also provides a control to allow users who have devices mounted in a specific orientation to achieve the desired viewing orientation.

    @@ -47,7 +46,7 @@

    Expected Results

    diff --git a/techniques/general/G216.html b/techniques/general/G216.html index 2d11dedf85..0ef2cb7b02 100644 --- a/techniques/general/G216.html +++ b/techniques/general/G216.html @@ -22,7 +22,7 @@

    Description

    The objective of this technique is to ensure that users who have difficulties performing path-based gestures can operate a control slider. A control slider is a track with a "thumb" that you move along the track to set a value.

    - A horizontal line with a round button halfway along the line, labelled volume. + A horizontal line with a round button halfway along the line, labelled volume.
    Screenshot of an example control slider showing the thumb in the middle of the track.
    diff --git a/techniques/general/G217.html b/techniques/general/G217.html index d4a75d5a2f..3302cf710f 100644 --- a/techniques/general/G217.html +++ b/techniques/general/G217.html @@ -8,13 +8,12 @@

    Providing a mechanism to allow users to remap or turn off character key shortcuts

    Metadata

    -

    Provide information below to help editors associate the technique properly. Contents of the meta section are not output by the processor.

    2.1.4 Character Key Shortcuts

    Sufficient

    Applicability

    -

    Any technology that supports scripting.

    +

    Any technology that supports scripting.

    Description

    @@ -22,7 +21,7 @@

    Description

    To prevent accidental activation, authors must allow users to turn off or reconfigure shortcuts that are made up of only character keys. Reconfiguring the shortcut may involve the ability to add a modifier key such as Ctrl, or authors may elect to allow users to alter the character keys assigned in addition to adding a modifer. Providing a mechanism to turn off or reassign the shortcut ensures more users can successfully interact with the application.

    If the keyboard shortcut is only active when a particular user interface component has focus, then the author does not need to provide an override mechanism. For example, in a select element, it is expected behaviour that pressing a letter key will reposition to the next item within the select element that begins with that character. This shortcut is only triggered when the select element has focus, and so it does not interfere with a user's ability to interact with the rest of the page.

    Locating and testing for character key shortcuts

    -

    An initial challenge for testers is identifying if author-created shortcuts exist, and then determining if existing shortcuts are triggered by character keys without modifiers. Where testers have access to the develop team, the existence and nature of shortcut keys can often be determined simply by asking involved designers and developers. Where reliable information from the authors is not available, the presence of shortcuts can possibly be identified by checking code (for example, in javascript, the presence of keydown, keyup and keypress listeners). Another means of identifying shortcuts is to review documentation. Where none of these strategies provide information on the presence of keyboard shortcuts, manual tests will need to be completed to search for the existence of character key shortcuts. Review the test procedure in failure technique F99 for guidance.

    +

    An initial challenge for testers is identifying if author-created shortcuts exist, and then determining if existing shortcuts are triggered by character keys without modifiers. Where testers have access to the develop team, the existence and nature of shortcut keys can often be determined simply by asking involved designers and developers. Where reliable information from the authors is not available, the presence of shortcuts can possibly be identified by checking code (for example, in javascript, the presence of keydown, keyup and keypress listeners). Another means of identifying shortcuts is to review documentation. Where none of these strategies provide information on the presence of keyboard shortcuts, manual tests will need to be completed to search for the existence of character key shortcuts. Review the test procedure in failure technique F99 for guidance.

    @@ -53,19 +52,5 @@

    Expected Results

    - -
    -

    Resources

    -

    Provide links to external resources that are relevant to users of the technique. This section is optional.

    -
      -
    • Link
    • -
    -
    diff --git a/techniques/general/G218.html b/techniques/general/G218.html index c60bfd5371..8e08c3b495 100644 --- a/techniques/general/G218.html +++ b/techniques/general/G218.html @@ -8,12 +8,12 @@

    Email link authentication

    Metadata

    -

    3.3.7 Accessible Authentication

    +

    3.3.8 Accessible Authentication (Minimum)

    Sufficient

    Applicability

    -

    Technologies that support authentication.

    +

    Technologies that support authentication.

    Description

    @@ -38,12 +38,14 @@

    Procedure

  • Check that the email is received.
  • Check that selecting the link opens the website.
  • Check that the user account is logged in.
  • +
  • Check that no object recognition test is used as part of the authentication process.
  • Expected Results

    • #2, #3 and #4 are true.
    • +
    • For the AAA Accessible Authentication (Enhanced), #5 is also true.
    diff --git a/techniques/general/G219.html b/techniques/general/G219.html index daa0a6ad8d..249f4ec9a4 100644 --- a/techniques/general/G219.html +++ b/techniques/general/G219.html @@ -1,14 +1,13 @@ - Ensuring that a single pointer operable alternative is available for dragging movements that operate on content + Ensuring an alternative to dragging movements -

    Ensuring that a single pointer operable alternative is available for dragging movements that operate on content

    +

    Ensuring that an alternative is available for dragging movements that operate on content

    Metadata

    -

    Provide information below to help editors associate the technique properly. Contents of the meta section are not output by the processor.

    2.5.X Dragging

    Sufficient

    @@ -18,18 +17,20 @@

    Applicability

    Description

    -

    The objective of this Technique is to ensure that people with motor impairments who cannot carry out dragging movements are presented with a single pointer operable alternative. Some direct manipulation interfaces allow users to pick up targets and move them to another position, for example, to change the position of an item in a priority list in a list, or to change the status of a task in a Kanban implementation (a type of visual process management view which shows tasks in vertical lanes representing process steps such as ‘scheduled’, ‘processed’, ‘completed’).

    -

    The single pointer operable alternative may require the user to carry out a series of single pointer interactions (for example, activating a target to be moved; opening a dropdown menu; and selecting a drop destination from the list of menu items offered).

    +

    The objective of this Technique is to ensure that people with motor impairments who cannot carry out dragging movements are presented with an alternative single pointer interaction that does not involve dragging.

    +

    Some direct manipulation interfaces allow users to pick up targets and use dragging movements to move them to another position, for example, to change the position of an item in a priority list, or to move a task on a Kanban or planning board.

    +

    Such dragging movements are difficult or impossible to carry out for some users with motor disabilities. The alternative to dragging movements operates the underlying function by one or several single pointer activations that don't require dragging. A single tap or click may reveal controls (arrows) to move a target in a stepwise fashion; open a drop-down menu where the drop position can be selected; or allow moving it to an ajacent postion by a swipe gesture.

    +

    Examples

      -
    • A list of items can be re-ordered by picking up an item and dragging it upwards or downwards. Other elements move dynamically to open a gap where the picked-up target can be dropped. After a single pointer activation, the list items display up and down arrows which allow a step-wise re-ordering of the the list via a single pointer inputs (taps or clicks at the up or down arrow).
    • +
    • A list of items can be re-ordered by picking up an item and dragging it upwards or downwards. Other elements move dynamically to open a gap where the picked-up target can be dropped. After a single pointer activation, the list items display up and down arrows which allow a step-wise re-ordering of the list via single pointer inputs (taps or clicks at the up or down arrow).
    • A vertical priority list indicates the priority of items listed. Each item can be ‘picked up’ with a pointer and dragged up or down to another position. The other list items rearrange dynamically. To the left of each list item, a number in a text field shows the current priority position. For any of the items, users can put in another number. This leads to a dynamic reordering and renumbering of the priority list.
    • -
    • In a Kanban implementation for process management, tasks can be dragged horizontally from one ‘swimming lane’ to another in order to change the status of tasks (for example, to change the status of a task from “in process” to “completed”). One or several items in a lande can be selected by a single tap or click. A single pointer activation of a drop-down menu labelled “Move selected items to” offers a selection of drop targets (other lanes). A further single pointer activation over the desired menu item moves targets to the specified lane.
    • -
    • In a Kanban implementation for process management, tasks can be dragged horizontally from one ‘swimming lane’ to another in order to change the status of tasks. A directional horizontal swipe over an item moves it to the adjacent lane. This process can be repeated until the item is in the desired lane.
    • +
    • In a Kanban implementation for process management, tasks can be dragged horizontally from one ‘swimming lane’ to another in order to change the status of tasks (for example, to change the status of a task from “in process” to “completed”). One or several items in a lane can be selected by a single tap or click. A single pointer activation of a drop-down menu labelled “Move selected items to” offers a selection of drop targets (other lanes). A further single pointer activation over the desired menu item moves targets to the specified lane.
    • +
    • In a radial control widget, the visual indicator of the current value of the control can be dragged to a different position. Users can also click or tap on another position of the radial control to change the value.
    @@ -41,7 +42,7 @@

    Procedure

    For interface elements that support dragging:

    1. Check the interface for the presence of functions triggered by dragging movements.
    2. -
    3. Check that there is a single pointer input alternative to operate the same function
    4. +
    5. Check that there is a single pointer activation alternative that does not require dragging to operate the same function
    @@ -54,14 +55,9 @@

    Expected Results

    -
    -

    Resources

    - -
    diff --git a/techniques/general/G220.html b/techniques/general/G220.html index ebe013b3b4..117c490165 100644 --- a/techniques/general/G220.html +++ b/techniques/general/G220.html @@ -1,11 +1,11 @@ - Provide a contact-us link + Provide a contact-us link in a consistent location -

    Provide a contact-us link

    +

    Provide a contact-us link in a consistent location

    Metadata

    Findable Help

    @@ -13,7 +13,7 @@

    Metadata

    Applicability

    -

    Technologies that contain links

    +

    Technologies that contain links

    Description

    @@ -23,12 +23,19 @@

    Description

    Examples

    -

    A link at the top of the page

    -

    An on-line job application asks for many types of information from the user, such as their identification number, but they may have several and not know which one to enter. They may need more information from someone that can answer their question when the contextual help provided does not meet their needs. The (for example) sixth link that the user reaches when tabbing through the page is titled "Contact Us". This link is also visually in the same location on each page. Activating the link brings the user to the contact details page. The contact details page has an email address for a company representative or general information inbox which is then shared with appropriate personnel.

    +

    A link at the top of the page

    +

    An on-line job application asks for many types of information from the user, such as their identification number, but they may have several and not know which one to enter. They may need more information from someone that can answer their question when the contextual help provided does not meet their needs. One of the first links that the user reaches when tabbing through the page is titled "Contact Us". This link is also visually in the same location on each page. Activating the link brings the user to the contact details page. The contact details page has an email address for a company representative or general information inbox which is then shared with appropriate personnel.

    A link in the footer region

    -

    A Web page’s footer region contains links repeated on every page in a set of web pages. The visual and programmatic order are consistent when viewed in the same size display. The (example) third link in the footer region is labeled visually and programmatically “Contact Us.” A user activates the link and is brought to the contact details page. The contact details page has an email address for a company representative or general information inbox which is then shared with appropriate personnel.

    +

    A Web page's footer region contains links repeated on every page in a set of web pages. The visual and programmatic order are consistent when viewed in the same size display. One of the first links in the footer region is labeled visually and programmatically "Contact Us". A user activates the link and is brought to the contact details page. The contact details page has an email address for a company representative or general information inbox which is then shared with appropriate personnel.

    +
    +
    +

    A link sometimes in a disclosure widget

    +

    On some pages in a set of web pages, there is a link to a help mechanism directly on the page. On one or more other pages in the set, the link is within a disclosure widget which is in the same relative order as the link that is directly on the page.

    +
    +

    Although this example technically passes the Success Criterion, it creates a less consistent user experience and is less preferable than consistently placing a link directly on the page.

    +
    @@ -36,7 +43,7 @@

    Tests

    Procedure

      -
    1. Determine if this is a single page app or a set of web pages, with blocks of content that are repeated on multiple web pages.
    2. +
    3. Determine if this is a set of web pages with blocks of content that are repeated on multiple pages.
    4. Determine if at least one of the following is included or linked in a consistent location:
      • Human contact details
      • @@ -45,9 +52,16 @@

        Procedure

      • A fully automated mechanism
    5. -
    6. Without changing the viewport size, check that the identified help is present on all other web pages within that set of web pages.
    7. +
    8. Without changing the viewport size, check that the identified help is present on all other web pages within that set of web pages.
    +
    +

    Expected Results

    +
      +
    • If #1 is true, #2 and #3 are true.
    • +
    • Otherwise, #1 is false.
    • +
    +