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 193897b182..598250a1d5 100644 --- a/.gitignore +++ b/.gitignore @@ -214,3 +214,34 @@ pip-log.txt #Mr Developer .mr.developer.cfg + +############# +## Apache Ant +############# + +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 50e84731ec..0000000000 --- a/.travis.yml +++ /dev/null @@ -1,21 +0,0 @@ -language: java -env: - global: - - GH_REF: github.com/w3c/wcag.git - -git: - depth: 3 - -script: - - mkdir output - - git clone --depth=1 --branch=gh-pages https://github.com/w3c/wcag.git output - - 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 ad0db9e124..6bee8669d4 100644 --- a/README.md +++ b/README.md @@ -1,22 +1,30 @@ -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. +## Editorial style guide + +@@To complete + +* 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 @@ -28,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 @@ -73,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. @@ -105,11 +115,9 @@ 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. Small inline images may be loaded with a `` element with suitable `alt` text. +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. Techniques should include brief code examples to demonstrate how to author content that follows the technique. Code examples should be easy to read, and usually not complete content in themselves. More complete examples can be provided as [working examples](#user-content-provide-working-examples-of-techniques) (see below). Link to working examples at the bottom of each example, in a `

    ` element, containing a relative link to `../../working-examples/{example-name}/`. @@ -128,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: @@ -143,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. @@ -168,5 +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.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.html b/acknowledgements.html index 963ea368cc..ab496ae110 100644 --- a/acknowledgements.html +++ b/acknowledgements.html @@ -1,123 +1,7 @@ -<section class="appendix" id="acknowledgments"> - <h1>Acknowledgments</h1> - <p>Additional information about participation in the Accessibility Guidelines Working Group (AG WG) can be found on the <a href="https://www.w3.org/WAI/GL/">Working Group home page</a>.</p> - - <section id="ack_participants-active"> - <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>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>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>Michael Cooper (W3C)</li> - <li>Romain Deltour (DAISY Consortium)</li> - <li>Wayne Dick (Knowbility, Inc)</li> - <li>Chaohai Ding (University of Southampton)</li> - <li>Kim Dirks (Thompson 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>Wilco Fiers (Deque Systems, Inc.)</li> - <li>Detlev Fischer (Invited Expert)</li> - <li>John Foliot (Deque Systems, Inc.)</li> - <li>Matt Garrish (DAISY Consortium)</li> - <li>Alistair Garrison (Level Access)</li> - <li>Michael Gower (IBM Corporation)</li> - <li>Jon Gunderson</li> - <li>Markku Hakkinen (Educational Testing Service)</li> - <li>Katie Haritos-Shea (Knowbility, Inc)</li> - <li>Andy Heath (Invited Expert)</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>Marc Johlic (IBM Corporation)</li> - <li>Rick Johnson (VitalSource | Ingram Content Group)</li> - <li>Crystal Jones (Microsoft Corporation)</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>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>Neil Milliken (Unify Software and Solutions)</li> - <li>Rachael Montgomery (MITRE Corporation)</li> - <li>Mary Jo Mueller (IBM Corporation)</li> - <li>Brooks Newton (Thomson Reuters)</li> - <li>James Nurthen (Oracle Corporation)</li> - <li>Joshue O Connor (Invited Expert)</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>Ruoxi Ran (W3C)</li> - <li>Stephen Repsher (The Boeing Company)</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>Adam Solomon (Invited Expert)</li> - <li>Jaeil Song (National Information Society Agency (NIA))</li> - <li>Jeanne Spellman (The Paciello Group, LLC)</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>Jason White (Educational Testing Service)</li> - <li>Mark Wilcock (Unify Software and Solutions)</li> - </ul> - </section> - - <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> - </section> - - <section> - <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> +<section class="appendix informative section" id="acknowledgements"> + <h3>Acknowledgments</h3> + <p>Additional information about participation in the Accessibility Guidelines Working Group (AG WG) can be found on the <a href="https://www.w3.org/WAI/GL/">Working Group home page</a>.</p> + <div data-include="../acknowledgements/ag-wg-active.html" data-include-replace="true"></div> + <div data-include="../acknowledgements/ag-contributors.html" data-include-replace="true"></div> + <div data-include="../acknowledgements/funders.html" data-include-replace="true"></div> </section> diff --git a/acknowledgements/ag-contributors.html b/acknowledgements/ag-contributors.html new file mode 100644 index 0000000000..4d1a2542cd --- /dev/null +++ b/acknowledgements/ag-contributors.html @@ -0,0 +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, 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 new file mode 100644 index 0000000000..19cc2fd7ea --- /dev/null +++ b/acknowledgements/ag-wg-active.html @@ -0,0 +1,93 @@ +<section id="ack_participants-active"> + <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 (Amazon)</li> + <li>Chuck Adams (Oracle Corporation)</li> + <li>Amani Ali (Nomensa)</li> + <li>Jim Allan (Invited Expert)</li> + <li>Jon Avila (Level Access)</li> + <li>Bruce Bailey (U.S. Access Board)</li> + <li>Renaldo Bernard (University of Southampton)</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>Sukriti Chadha (Invited Expert)</li> + <li>Rafal Charlampowicz (AccessibilityOZ)</li> + <li>Michael Cooper (W3C)</li> + <li>Jennifer Delisi (Invited Expert)</li> + <li>Wayne Dick (Knowbility, Inc)</li> + <li>Kim Dirks (Thomson Reuters)</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 (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>Markku Hakkinen (Educational Testing Service)</li> + <li>Charles Hall (Invited Expert)</li> + <li>Katie Haritos-Shea (Knowbility, Inc)</li> + <li>Dan Harper-Wain (HM Government)</li> + <li>Shawn Henry (W3C)</li> + <li>Sarah Horton (Invited Expert)</li> + <li>Abi James (University of Southampton)</li> + <li>Marc Johlic (IBM Corporation)</li> + <li>Oliver Keim (SAP SE)</li> + <li>Andrew Kirkpatrick (Adobe)</li> + <li>John Kirkwood (Invited Expert)</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>Chris Loiselle (Invited Expert)</li> + <li>David MacDonald (Invited Expert)</li> + <li>Jan McSorley (Pearson plc)</li> + <li>Rain Breaw Michaels (Google LLC)</li> + <li>Neil Milliken (Unify Software and Solutions)</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>Kim Patch (Invited Expert)</li> + <li>Melanie Philipp (Deque Systems, Inc.)</li> + <li>Mike Pluke (Invited Expert)</li> + <li>Ian Pouncey (TetraLogical)</li> + <li>Ruoxi Ran (W3C)</li> + <li>Stephen Repsher (Invited Expert)</li> + <li>John Rochford (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 (TPGi)</li> + <li>Andrew Somers (Invited Expert)</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>Gregg Vanderheiden (Raising the Floor)</li> + <li>Kathleen Wahlbin (Invited Expert)</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> diff --git a/acknowledgements/ag-wg-participants.html b/acknowledgements/ag-wg-participants.html new file mode 100644 index 0000000000..bd53c4ded9 --- /dev/null +++ b/acknowledgements/ag-wg-participants.html @@ -0,0 +1,149 @@ +<section class="section" id="ack_group"> + <h4>Participants active in the AG WG at the time of publication</h4> + <ul> + <li>Abma, Jake (Invited expert)</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> + <li>Allen, Matt (Deque Systems, Inc.)</li> + <li>Avila, Jonathan (SSB BART Group)</li> + <li>Bailey, Bruce (Invited expert)</li> + <li>Batterman, Jared (MITRE Corporation)</li> + <li>Bernard, Renaldo (University of Southampton)</li> + <li>Bernier, Alex (association BrailleNet)</li> + <li>Bigby, Garenne (Dyno Mapper)</li> + <li>Blouch, Chris (SSB BART Group)</li> + <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> + <li>Craig, James (Apple, Inc.)</li> + <li>Cronin, Joe (Amazon)</li> + <li>Crutchfield, Elizabeth (SSB BART Group)</li> + <li>Dailey, Jennifer (Deque Systems, Inc.)</li> + <li>de Vries, Hidde (W3C Staff)</li> + <li>Delisi, Jennifer (Invited expert)</li> + <li>Deltour, Romain (DAISY Consortium)</li> + <li>Dick, Wayne (Knowbility)</li> + <li>Ding, Chaohai (University of Southampton)</li> + <li>Dirks, Kim (Thomson Reuters Corp.)</li> + <li>Dixit, Shwetank (eyeo GmbH)</li> + <li>Dogbo, Nicaise (Microsoft Corporation)</li> + <li>Draffan, E.A. (University of Southampton)</li> + <li>Eggert, Eric (W3C Staff)</li> + <li>Elledge, Michael (Invited expert)</li> + <li>Eng, Kathy (Invited expert)</li> + <li>Faulkner, Steve (The Paciello Group, LLC)</li> + <li>Fazio, David (Invited expert)</li> + <li>Fernando, Anthony (Pearson plc)</li> + <li>Ferraz, Reinaldo (NIC.br - Brazilian Network Information Center)</li> + <li>Fiers, Wilco (Deque Systems, Inc.)</li> + <li>Fischer, Detlev (Invited expert)</li> + <li>Foliot, John (Deque Systems, Inc.)</li> + <li>Garrish, Matt (DAISY Consortium)</li> + <li>Garrison, Alistair (SSB BART Group)</li> + <li>Gilbert, Michael (Google, Inc.)</li> + <li>Gower, Michael (IBM Corporation)</li> + <li>Graff, Kim (Macmillan Learning)</li> + <li>Grant, Garry (Search Engine Optimization Inc)</li> + <li>Griesemer, Jim (SSB BART Group)</li> + <li>Grorssi, Alexandra (IBM Corporation)</li> + <li>Guarino Reid, Loretta (Google, Inc.)</li> + <li>Hakkinen, Markku (Educational Testing Service)</li> + <li>Hall, Charles (Invited expert)</li> + <li>Haritos-Shea, Katie (Knowbility)</li> + <li>Heath, Andy (Invited expert)</li> + <li>Henry, Shawn (W3C Staff)</li> + <li>Hoffmann, Thomas (Educational Testing Service)</li> + <li>Horton, Sarah (The Paciello Group, LLC)</li> + <li>Isager, Kasper (Siteimprove)</li> + <li>James, Abi (University of Southampton)</li> + <li>Johlic, Marc (IBM Corporation)</li> + <li>Johnson, Jeffrey (SAP SE)</li> + <li>Joys Andersen, Wilhelm (W3C invited expert)</li> + <li>Kapoor, Shilpi (BarrierBreak Technologies)</li> + <li>Keim, Oliver (SAP SE)</li> + <li>Kennaugh, Peter (Nomensa)</li> + <li>Kirkpatrick, Andrew (Adobe)</li> + <li>Kirkwood, John (Invited expert)</li> + <li>Korn, Peter (Amazon)</li> + <li>Kraft, Maureen (IBM Corporation)</li> + <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 (TetraLogical)</li> + <li>Lauriat, Shawn (Google, Inc.)</li> + <li>Lazrus, Robin (Pearson plc)</li> + <li>Lee, Jerry (Macmillan Learning)</li> + <li>Lee, Steve (W3C Staff)</li> + <li>Lemon, Gez (The Paciello Group, LLC)</li> + <li>Li, Angel (Alibaba Group)</li> + <li>Li, Kepeng (Alibaba Group)</li> + <li>Loiselle, Chris (Invited expert)</li> + <li>MacDonald, David (Invited expert)</li> + <li>Mace, Amanda (Web Key IT Pty Ltd)</li> + <li>McCormack, Scott (SSB BART Group)</li> + <li>McMeeking, Chris (Deque Systems, Inc.)</li> + <li>McSorley, Jan (Pearson plc)</li> + <li>Mueller, Mary Jo (IBM Corporation)</li> + <li>Mussinelli, Cristina (Fondazione LIA)</li> + <li>Nandakumar, Jey (Deque Systems, Inc.)</li> + <li>Newton, Brooks (Thomson Reuters Corp.)</li> + <li>nicole, windmann (SAP SE)</li> + <li>Niemann, Gundula (SAP SE)</li> + <li>Othman, Achraf (MADA Center, Qatar)</li> + <li>Pagel, Caryn (Thomson Reuters Corp.)</li> + <li>Panchang, Sailesh (Deque Systems, Inc.)</li> + <li>Pandhi, Charu (IBM Corporation)</li> + <li>Pascalides, Justine (Educational Testing Service)</li> + <li>Pasi, Aparna (Deque Systems, Inc.)</li> + <li>Patch, Kimberly (Invited expert)</li> + <li>Pellegrino, Gregorio (Fondazione LIA)</li> + <li>Philipp, Melanie (Deque Systems, Inc.)</li> + <li>Pluke, Mike (Invited expert)</li> + <li>Pouncey, Ian (TetraLogical)</li> + <li>Ran, Ruoxi (W3C Staff)</li> + <li>Recke, Kai (eyeo GmbH)</li> + <li>Repsher, Stephen (Invited expert)</li> + <li>Rochford, John (Invited expert)</li> + <li>Sack, Cybele (Invited expert)</li> + <li>Sahasrabudhe, Shrirang (Educational Testing Service)</li> + <li>Sajka, Janina (Amazon)</li> + <li>saleem, muhammad (Miskan Environmental Consultation)</li> + <li>Savva, Andreas (Royal National Institute of Blind People (RNIB))</li> + <li>Schnabel, Stefan (SAP SE)</li> + <li>Seeman-Kestenbaum, Lisa (Invited expert)</li> + <li>Sims, Glenda (Deque Systems, Inc.)</li> + <li>Singh, Avneesh (DAISY Consortium)</li> + <li>Skotkjerra, Stein Erik (Siteimprove)</li> + <li>Sloan, David (The Paciello Group, LLC)</li> + <li>Smith, Keyonda (Invited expert)</li> + <li>Somers, Andrew (Invited expert)</li> + <li>Soroken, Arthur (Google, Inc.)</li> + <li>Spellman, Jeanne F (TetraLogical)</li> + <li>Steenhout, Nicolas (Knowbility)</li> + <li>Swallow, David (The Paciello Group, LLC)</li> + <li>Thyme Nørregaard, Anne (Siteimprove)</li> + <li>Ueki, Makoto (Invited expert)</li> + <li>Vaishnav, Jatin (Deque Systems, Inc.)</li> + <li>Venkata, Manoj (Deque Systems, Inc.)</li> + <li>Wahlbin, Kathleen (The Paciello Group, LLC)</li> + <li>Watson, Léonie (TetraLogical)</li> + <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> +</section> diff --git a/acknowledgements/funders.html b/acknowledgements/funders.html new file mode 100644 index 0000000000..7d1b5f9402 --- /dev/null +++ b/acknowledgements/funders.html @@ -0,0 +1,4 @@ +<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, 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 ae11a1fe5a..d98875bab7 100644 --- a/biblio.js +++ b/biblio.js @@ -1,4 +1,4 @@ -var biblio = { +respecConfig.localBiblio = { "CAPTCHA": { "href": "http://www.captcha.net/", @@ -26,26 +26,22 @@ var biblio = { }, "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 2a035b03b7..826a539a19 100644 --- a/build.xml +++ b/build.xml @@ -10,6 +10,8 @@ <!-- The following properties need to be set appropriately before doing a build - they should all be overridden by the above property file, but are kept here to serve as defaults --> <property name="outputdir" location="." description="Directory within which the output folders are created, normally "../YYYY" unless doing TR in which case it is "../../../TR/<YYYY>""/> <property name="uri.prefix" value="file:///" description="Prefix if any that must be prepended to URIs to make it resolve on the platform"/> + <property name="guidelines.version" value="22" description="Which version of WCAG is being built"/> + <property name="w3ccvs.location" location="../../../w3ccvs"/> <property name="xslt.factory" value="net.sf.saxon.TransformerFactoryImpl" description="Class name of the XSLT transformer factory, which sets which XSLT engine to use; must be an XSLT 2.0 processor"/> <property name="classpath.saxon" value="lib/saxon9he.jar" description="Path to Saxon jar in order to run XSLT 2.0"/> @@ -38,12 +40,20 @@ <target name="clean" description="Clean up any temp files"> <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"/> </target> <target name="flatten" depends="init" description="Build a copy of guidelines with all data-include files incorporated"> @@ -55,15 +65,60 @@ </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}"/> </xslt> </target> + <target name="guidelines-versions" description="Create XML list of which WCAG version introduces which guidelines"> + <local name="output.file"/> + <property name="output.file" value="${inputdir.guidelines}/versions.xml"/> + <echo file="${output.file}"><![CDATA[<versions> +]]></echo> + <for param="current.dir"> + <path><dirset dir="understanding" includes="*"/></path> + <sequential> + <local name="version"/> + <basename file="@{current.dir}" property="version"/> + <echo file="${output.file}" append="yes"><![CDATA[ <version name="${version}"> +]]></echo> + <for param="current.file"> + <path><fileset dir="@{current.dir}" includes="*"/></path> + <sequential> + <local name="id"/> + <basename file="@{current.file}" property="id" suffix="html"/> + <echo file="${output.file}" append="yes"><![CDATA[ <id id="${id}"/> +]]></echo> + </sequential> + </for> + <echo file="${output.file}" append="yes"><![CDATA[ </version> +]]></echo> + </sequential> + </for> + <echo file="${output.file}" append="yes"><![CDATA[</versions> +]]></echo> + </target> + + <target name="guidelines" depends="init"> + <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.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"/> + <arg value="output/guidelines/${guidelines.version}/index.html"/> + <arg value="-f"/> + <arg value="--retry"/> + <arg value="3"/> + </exec> + </target> + <!-- Techniques --> <target name="techniques-list" description="Create XML list of all the technique files"> + <local name="output.file"/> <property name="output.file" value="${inputdir.techniques}/techniques.xml"/> <echo file="${output.file}"><![CDATA[<techniques> ]]></echo> @@ -106,7 +161,7 @@ ]]></echo> </target> - <target name="techniques-association" depends="flatten, guidelines-xml" description="Build an XML structure of all techniques"> + <target name="techniques-association" depends="flatten, guidelines-xml, guidelines-versions" description="Build an XML structure of all techniques"> <makeurl file="${basedir}/techniques" property="techniques.dir"/> <makeurl file="${basedir}/understanding" property="understanding.dir"/> <xslt in="${inputdir.guidelines}/wcag.xml" out="${inputdir.techniques}/technique-associations.xml" style="xslt/generate-technique-associations.xslt"> @@ -117,147 +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="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/WCAG21/" if="publication"/> - <param name="loc.understanding" expression="https://www.w3.org/WAI/WCAG21/Understanding/" if="publication"/> - <param name="loc.techniques" expression="https://www.w3.org/WAI/WCAG21/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="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="${basedir}/output/techniques/index.html" style="xslt/flatten-document.xslt" force="true"> - <classpath path="${classpath.saxon}"/> - <factory name="${xslt.factory}"/> - <param name="base.dir" expression="${base.techniques}"/> - <param name="loc.guidelines" expression="https://www.w3.org/TR/WCAG21/" if="publication"/> - <param name="loc.understanding" expression="https://www.w3.org/WAI/WCAG21/Understanding/" if="publication"/> - <param name="loc.techniques" expression="https://www.w3.org/WAI/WCAG21/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, 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="loc.guidelines" expression="https://www.w3.org/TR/WCAG21/" if="publication"/> - <param name="loc.understanding" expression="https://www.w3.org/WAI/WCAG21/Understanding/" if="publication"/> - <param name="loc.techniques" expression="https://www.w3.org/WAI/WCAG21/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="understanding/understanding.css" todir="output/understanding/"/> - <copy file="css/slicenav.css" todir="output/understanding/"/> - <copy todir="output/understanding/img/"> - <fileset dir="understanding/21/img"/> - </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}/output/understanding/index.html" style="xslt/flatten-document.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="loc.guidelines" expression="https://www.w3.org/TR/WCAG21/" if="publication"/> - <param name="loc.understanding" expression="https://www.w3.org/WAI/WCAG21/Understanding/" if="publication"/> - <param name="loc.techniques" expression="https://www.w3.org/WAI/WCAG21/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> - <!-- 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="techniques"/> - <antcall target="understanding"/> - <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="../../../smartcvs/WWW/WAI/WCAG21/"> - <fileset dir="output/"/> - <globmapper from="*index.html" to="*Overview.html"/> - </copy> - <copy todir="../../../smartcvs/WWW/WAI/WCAG21/"> - <fileset dir="output" excludes="index.html **/index.html"/> - </copy> - <copy todir="../../../smartcvs/WWW/WAI/WCAG21/working-examples/"> - <fileset dir="working-examples/"/> - <globmapper from="*index.html" to="*Overview.html"/> - </copy> - <copy todir="../../../smartcvs/WWW/WAI/WCAG21/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 new file mode 100644 index 0000000000..8f43476527 --- /dev/null +++ b/conformance-challenges/index.html @@ -0,0 +1,1266 @@ +<!DOCTYPE html> +<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> + <head> + <meta charset="UTF-8"/> + <title>Challenges with Accessibility Guidelines Conformance and Testing, and Approaches for Mitigating Them + + + + + + + + +

    + + + +

    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 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. Applying a web-based, and page-based conformance model can be challenging to do for non-web Information and Communications Technologies (ICT).
    8. +
    9. 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).
    10. +
    +

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

    +
    +
    +

    Introduction

    +
    +

    Problem Statement

    + +

    Assessing the accessibility of a website is of critical importance. +Website authors want to have website accessibility assessments in order to +understand the places where visitors with disabilities may be unable to use +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 + Accessibility Guidelines Working Group +(AGWG) of the World Wide Web Consortium +(W3C) developed the Web Content +Accessibility Guidelines (WCAG), containing +both a rich set of success criteria to meet the needs of people with +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 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. 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, +including content updates, new content, and user interface changes that happen +almost continuously, perhaps at the rate of hundreds or even thousands of page +updates per second. This is especially the case where third parties are +actively populating and changing site content, such as website users +contributing content. Ensuring that every one of these page updates fully +satisfies all success criteria (as appropriate), especially where expert human +review is required for some criteria presents a problem for scaling conformance assessments. +Further, where pages are generated programmatically, finding every bug +related to that generation may prove challenging, especially when they only +arise from uncommon content scenarios or combinations (and updates to those +algorithms and code happen multiple times per week). It is incumbent on websites - especially for large, complex, dynamic websites - to do everything they can to conform. However, to date, no large, complex software has been bug free. Similarly, authors of large, dynamic, and complex sites have struggled to claim conformance with no accessibility defects on any page. +

    + +

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

    + +

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

    + +

    +Further, the Research + Report on Web Accessibility Metrics +[[accessibility-metrics-report]] from the Research and Development Working + Group (RDWG) explores the main qualities that website +accessibility need to consider to communicate accessibility in a simple form +such as a number. One particularly interesting thing this research report +explored are qualities such as the severity of an accessibility barrier and the +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 issues. +

    + +

    Finally, the Accessibility +Conformance Testing Task Force and ACT Rules Community Group (ACT-R) +are working to standardize accessibility conformance testing methodologies. +They are doing it through defining a W3C specification, published as a W3C Recommendation in +2019, Accessibility Conformance Testing +(ACT) Rules Format 1.0, [[act-rules-format-1.0]] as well as considering ways to output metrics around +what the tests find. This could contribute to an alternative to the conformance model, which requires a site to have no defects on any page to claim conformance. Whenever possible, they are turning +WCAG success criteria into automated test rules to enable accessibility +testing on a large scale. When effective automated tests are not +possible, they are writing semi-automated or manual accessibility tests that +are both informative and valuable. It does not, however, speak to scaling +tests that require human involvement, or the challenges of third-party +content, or solve the problem of programmatically generated web pages. While +they are all substantial contributions to the field of web accessibility, +WCAG-EM, ATAG, and ACT task forces actively address different types of challenges, +and do not fully address the challenges described in this document. +

    +

    Separately, the phrase substantially conforms to WCAG is a way of conveying that a website is broadly accessible, but that not every page conforms to every requirement. Unfortunately, that phrase has no W3C definition today + and there is no definition or mechanism that sets a level for a site to meet that would qualify as substantial conformance. +

    +
    + +
    +

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

    +

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

    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.

    + +

    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 +are much more likely to have well defined headings and structure. Further, if pages are +limited to rendering images that come from a fully vetted library of images that have well +defined ALT text, and these images are always used in similar contexts (i.e., a store inventory) + then issues with poor ALT text can be minimized if not entirely eliminated. Another approach that can be used in +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 <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. +

    +
    + +
    +
    +

    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 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 +possible valid and invalid content. Another is Integration Testing, where the +individual Units or Components of the software are combined in pairs, to +validate their interoperability across a wide range of possible interactions. +These approaches and others for quality assurance of complex software systems +are effective tools for minimizing the number of bugs in the system, though +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.

    +

    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

    +

    WCAG 2.x speaks to 3rd party content and conformance, in the context of a +Statement of +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; +or
    2. +
    3. Make a statement of partial conformance if the page could conform if the 3rd party content were removed.
    4. +
    +

    The provision of monitoring and required repair within a 2 business day +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 +anticipate encountering inaccessible content, it does little to practically enable large sites to address such concerns.

    +
    + +
    +

    Silver Research Findings

    + +

    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 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, 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 +content that poses accessibility challenges, which may also offer a great +opportunity to help educate users and provide a teachable moment that would +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.

    + + +

    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 +describing how to meet WCAG success criteria for Adobe PDF documents, and +Adobe includes a PDF accessibility assessment tool that also helps authors +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 +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 +3rd party assistive technologies in some cases. Further, there are a variety +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 +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. +

    +
    +
    + +
    +

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

    +
    +

    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:

    + + +
    +
    +

    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 +

    + + +

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

    +
    +
    +

    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 +

    + +

    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 +

    + + +

    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 +

    + + +

    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.

    +
    +
    +

    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 +

    + + +

    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 +

    + + +

    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 +

    + + +

    This success criterion requires several levels of checks that are difficult or impossible to automate as it allows for exceptions which require human intervention to examine the intent and potentially employ exceptions to comply with the guideline. Automated checks would have to include:

    +
      +
    • A way to identify UI components, which is easy for standard HTML elements, but more difficult for non-standard custom scripted components.
    • +
    • Whether the default user agent visual treatments for identifying UI components and states are being used (so that the exception can be utilized)
    • +
    • Where default treatments are not employed, a way to identify changes in state and then compare the two states for sufficient contrast. This requires human evaluation to test for differences in the portions of graphics used to show the different states or provide meaning (e.g. checked, unchecked, radio button selected, radio button unselected, toggle button selected vs. unselected and so on).
    • +
    • For graphical objects, a way to identify what part of the graphics are required to understand the content. Once identified, checks to determine whether the presentation of the graphics is essential + to utilize the exception which requires human intervention.
    • +
    +
    +
    +

    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

    + + +

    As content needs to be surfaced by providing focus using either a mouse pointer or keyboard focus, to then determine whether the following 3 criteria are met, this test currently requires human evaluation.

    +
      +
    • Dismissible: A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content; +
    • +
    • Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing; +
    • +
    • Persistent: The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid. +
    • +
    +
    +
    +

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

    + + +

    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 +

    + + +

    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 +

    + + +

    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 +

    + + +

    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 +

    + + +

    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 +

    + + +

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

    + + +

    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 +

    + + +

    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 +

    + + +

    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 +

    + + +

    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 +

    + + +

    When mouse-down events are used (this can be done automatically), checking for one of the following four options that ensure the functionality is accessible requires human evaluation:

    +
      +
    • No Down-Event: The down-event of the pointer is not used to execute any part of the function; +
    • +
    • Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion; +
    • +
    • Up Reversal: The up-event reverses any outcome of the preceding down-event; +
    • +
    • Essential: Completing the function on the down-event is essential. +
    • +
    +
    +
    +

    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 +

    + + +

    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 +

    + + +

    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 +

    + + +

    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 +

    + + +

    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 +

    + + +

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

    +
    +
    +

    Name, Role, Value +

    + + +

    Incorrect use of ARIA constructs can be detected automatically but constructs that appear correct may still not work, and widgets that have no ARIA (but need it to be understood) can go undetected. Human post-check of automatic checks is still necessary.

    +
    +
    + +
    +

    Detailed Challenges with Conformance Verification and Testing for Non-Web ICT

    + +

    As noted in Challenge #4 Non-Web Information and +Communications Technologies above, 18 success criteria out of the 38 A and AA criteria in WCAG 2.0 could be +applied to non-web ICT only after replacing specific terms or phrases. 4 of +those 12 (2.4.1, 2.4.5, 3.2.3, and 3.2.4) related to either a set of web + pages or multiple web pages, which is more difficult to characterize for +non-web ICT. Another 4 are the non-interference set (1.4.2, 2.1.2, 2.2.2, +and 2.3.1) which need further special consideration as they would apply to an +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. +

    + +

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

    + +
    +

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

    + +

    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 +

    + + +

    To ensure this criterion is met for non-web documents, once the set of documents is defined, every document in the set must provide multiple mechanisms for locating every other document in the set. As noted by WCAG2ICT, if the documents 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 documents must expose at least 2 ways of locating every other document 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. +

    + +

    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 +

    + + +

    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 the navigation mechanisms it contains (e.g. a table of contents, an index). Every document in that set must then be inspected to verify it contains the same navigation mechanisms as every other document, in the same relative order. Determining if this is the case is not possible today with any testing tool we are aware of, and so would require human inspection. +

    + +

    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 the navigation mechanisms it contains (e.g. the way keyboard commands are implemented should be the same for every application). Every application in that set must then be inspected to verify it contains the same navigation mechanisms as every other software application. 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 Identification +

    + + +

    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 all of the functional components (e.g. tables, figures, graphs, indices), noting how those components are identified. Every document in that set must then be inspected to verify that where they contain the same components as every other document in the set, they are identified in a consistent fashion. Determining if this is the case is not possible today with any testing tool we are aware of, and so would require human inspection. +

    + +

    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 all of the functional components (e.g. menus, dialog boxes, other user interface elements and patterns), noting how those components are identified. Every application in that set must then be inspected to verify that where they contain the same components as every other software application in the set, they are identified in a consistent fashion. Determining if this is the case is not possible today with any testing tool we are aware of, and so would require human inspection. +

    + +
    +
    + +
    +

    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 +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 +used. Standard software testing employs both programmatic testing and manual +testing – automating what can be automated, and using human inspection +otherwise. In the cases below, some level of human inspection or involvement +would normally be part of the software testing strategy to verify compliance +with these four criteria.

    + +
    +

    Audio Control +

    + + +

    Where non-web documents contain audio, especially audio that automatically +plays in certain circumstances (e.g. a slide in a slide deck starts playing a +video when that slide is shown), – this criterion is typically met through the +user agent or software application or operating system the user is using to +interact with the document (rather than through an affordance in the static +document itself). Because of this, compliance with this success criterion may +be software application or operating system dependent, and therefore difficult +to assess compliance for outside of a specific, named application or operating +system.

    + +

    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.

    + +
    + +
    +

    No Keyboard Trap +

    + + +

    Non-web documents rarely if ever include code for responding to keyboard focus. This criterion is typically met through the user agent or software application the user is using to interact with the document (rather than through an affordance in the static document itself). Because of this, compliance with this success criterion may be software application or operating system dependent, and therefore difficult to assess compliance for outside of a specific, named application or operating system. Even then, programmatic testing for this may not be possible. +

    + +

    Where non-web software contains a user interface that can be interacted with from a keyboard, it may be possible to test for this programmatically, though we are not aware of any such test today. Where interaction with the user interface is supported from a keyboard interface provided by an assistive technology (e.g. a Bluetooth keyboard driving a screen reader for a tablet or phone UI), programmatic testing may be especially challenging. +

    +
    + +
    +

    Pause, Stop, Hide +

    + + +

    As with audio, where non-web documents contain animation — especially animation that automatically plays in certain circumstances (e.g. a slide in a slide deck starts an animation when that slide is shown) — this criterion is typically met through the user agent or software application the user is using to interact with the document (rather than through an affordance in the static document itself). Because of this, compliance with this success criterion may be software application dependent, and therefore difficult to assess compliance for outside of a specific, named application. Even then, programmatic testing for this may not be possible. +

    + +

    Where non-web software contains animation — especially audio that +automatically plays in certain circumstances (e.g. showing a trailer for a +movie when the user selects a movie title) — this criterion is typically +met through some setting in the application to suppress such animations, or +perhaps in the operating system. Because it can be difficult to tell when the +animation is not desired by the user and when it is (did the user ask to play a +trailer?), this may not be possible to discern programmatically. +

    +
    + +
    +

    Three Flashes or Below Threshold +

    + + +

    While this success criterion may be difficult to programmatically test for +in all situations (especially for software applications), there is nothing in +this criterion that is otherwise challenging to apply in the non-web ICT +context.

    +
    +
    +
    +

    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.

    +
    + +
    +

    Timing Adjustable +

    + + +

    EDITOR'S NOTE
    Section content yet to be written.

    +
    + +
    +

    Pointer Gestures +

    + + +

    EDITOR'S NOTE
    Section content yet to be written.

    +
    + +
    +

    Pointer Cancellation +

    + + +

    EDITOR'S NOTE
    Section content yet to be written.

    +
    + +
    +

    Language of Page +

    + + +

    EDITOR'S NOTE
    Section content yet to be written.

    +
    + +
    +

    Language of Parts +

    + + +

    The purpose of this success criterion is to enable assistive technologies like screen readers to determine the language used for different passages of text on a web page. While some software environments like Java and GNOME/GTK+ support +this both for text substrings within a block of text as well as for individual user interface elements, others do not. Therefore, it may not be possible for some software to meet this success criterion. Separately, programmatic testing +for this may not be possible, as expert human judgment is needed to determine what the correct language is for some text passages. +

    + +
    + +
    +

    Error Prevention +

    + + +

    EDITOR'S NOTE
    Section content yet to be written.

    +
    + +
    +

    Parsing +

    + + +

    EDITOR'S NOTE
    Section content yet to be written.

    +
    + +
    +

    Name, Role, Value +

    + + +

    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.

    +
    +
    + +
    +

    Success Criteria Needing Special Treatment in Non-Accessibility Supported Environments

    +

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

    + + +
    +
    + +
    +

    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 (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 new file mode 100644 index 0000000000..ece8d4ac34 --- /dev/null +++ b/conformance-challenges/respec-config.js @@ -0,0 +1,114 @@ +var respecConfig = { + // embed RDFa data in the output + trace: true, + useExperimentalStyles: true, + doRDFa: '1.1', + includePermalinks: true, + permalinkEdge: true, + permalinkHide: false, + tocIntroductory: true, + // specification status (e.g., WD, LC, NOTE, etc.). If in doubt use ED. + specStatus: "ED", + //crEnd: "2012-04-30", + //perEnd: "2013-07-23", + //publishDate: "2013-08-22", + diffTool: "http://www.aptest.com/standards/htmldiff/htmldiff.pl", + + // the specifications short name, as in https://www.w3.org/TR/short-name/ + shortName: "accessibility-conformance-challenges", + + + // if you wish the publication date to be other than today, set this + //publishDate: "2020-06-04", + copyrightStart: "2020", + license: "w3c-software-doc", + noRecTrack: true, + + // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date + // and its maturity status + //previousPublishDate: "2020-06-04", + //previousMaturity: "WD", + //prevRecURI: "https://www.w3.org/TR/2018/REC-WCAG21-20180605/", + //previousDiffURI: "https://www.w3.org/TR/2014/REC-wai-aria-20140320/", + + // if there a publicly available Editors Draft, this is the link + edDraftURI: "https://w3c.github.io/wcag/conformance-challenges/", + + // if this is a LCWD, uncomment and set the end of its review period + // lcEnd: "2012-02-21", + + // editors, add as many as you like + // only "name" is required + editors: [ + { + name: "Janina Sajka", + URL: "https://linkedin.com/in/jsajka", + mailto: "janina@rednote.net", + w3cid: 33688 + }, + { + name: "Michael Cooper", + url: 'https://www.w3.org/People/cooper/', + company: "W3C", + companyURL: "https://www.w3.org/", + w3cid: 34017 + } + ], + + // authors, add as many as you like. + // This is optional, uncomment if you have authors as well as editors. + // only "name" is required. Same format as editors. + + authors: [ + // { name: "Your Name", url: "http://example.org/", + // company: "Your Company", companyURI: "http://example.com/" }, + { + name: "Janina Sajka", + URL: "https://linkedin.com/in/jsajka", + mailto: "janina@rednote.net", + w3cid: 33688 + }, + { + name: "Peter Korn", + company: "Amazon", + companyURL: "https://www.amazon.com/", + mailto: "pkorn@amazon.com", + w3cid: 37425 + }, + { + name: "Charles Hall", + mailto: "charles.hall@mrm.com", + w3cid: 57439 + } + ], + + /* + alternateFormats: [ + { uri: 'wcag21-diff.html', label: "Diff from Previous Recommendation" } , + { uri: 'wcag21.ps', label: "PostScript version" }, + { uri: 'wcag21.pdf', label: "PDF version" } + ], + */ + + // errata: 'https://www.w3.org/2010/02/rdfa/errata.html', + + // 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", + maxTocLevel: 4, + + postProcess: [addTextSemantics, swapInDefinitions] + +}; 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/additional.css b/css/additional.css index f886d3663e..3cb28bdd48 100644 --- a/css/additional.css +++ b/css/additional.css @@ -162,7 +162,6 @@ div.sc div.note p.prefix { margin-bottom: 0; } - span.screenreader {position: absolute; left: -10000px} /* tabbed styles - repeated here to keep cover sheets consistent with /TR/ style */ diff --git a/css/base.css b/css/base.css new file mode 100644 index 0000000000..25a82c2c1f --- /dev/null +++ b/css/base.css @@ -0,0 +1,473 @@ +main { + display: block; +} + +.nav-container { +} + +.nav { + overflow: inherit; +} + +.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; + 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 bf5bc7e1a3..2b29e5330a 100644 --- a/guidelines/guidelines.css +++ b/guidelines/guidelines.css @@ -6,6 +6,27 @@ display:inline; } +.new { + border: medium solid #008000; +} +.proposed { + border: medium solid #D34245; +} +.changed { + border: medium solid #c28017; +} +section.new, section.proposed, section.changed { + padding: 1em; + margin-top: 1em; +} +dt.new, dt.proposed, dt.changed { + border-bottom: none; +} +dd.new, dd.proposed, dd.changed { + border-top: none; + margin-left: 0; + padding-left: 2em; +} .doclinks { float: right; border: thin solid black; @@ -13,6 +34,11 @@ display: block; width: 25%; hyphens: none; + padding: 1em; + display: flex; + flex-direction: column; + gap: .5em; + margin-left: 2em; } .sc dt { display: list-item; @@ -29,4 +55,7 @@ div.note-title, div.ednote-title { color: #008400 } -span.screenreader {position: absolute; left: -10000px} \ No newline at end of file +a.internalDFN[title]:hover, .internalDFN[title]:active, a.internalDFN[title]:focus { + cursor: help; +} +span.screenreader {position: absolute; left: -10000px} diff --git a/guidelines/index.html b/guidelines/index.html index 7e016db1d2..8402db4640 100644 --- a/guidelines/index.html +++ b/guidelines/index.html @@ -1,32 +1,36 @@ - + - Web Content Accessibility Guidelines (WCAG) 2.1 - - + Web Content Accessibility Guidelines (WCAG) 2.2 + - - + + +
    -

    Web Content Accessibility Guidelines (WCAG) 2.1 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content more accessible to a wider range of people with disabilities, including accommodations for blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and combinations of these, and some accommodation for learning disabilities and cognitive limitations; but will not address every user need for people with these disabilities. These guidelines address accessibility of web content on desktops, laptops, tablets, and mobile devices. Following these guidelines will also often make Web content more usable to users in general.

    -

    WCAG 2.1 success criteria are written as testable statements that are not technology-specific. Guidance about satisfying the success criteria in specific technologies, as well as general information about interpreting the success criteria, is provided in separate documents. See Web Content Accessibility Guidelines (WCAG) Overview for an introduction and links to WCAG technical and educational material.

    -

    WCAG 2.1 extends Web Content Accessibility Guidelines 2.0 [[!WCAG20]], which was published as a W3C Recommendation December 2008. Content that conforms to WCAG 2.1 also conforms to WCAG 2.0. The WG intends that for policies requiring conformance to WCAG 2.0, WCAG 2.1 can provide an alternate means of conformance. The publication of WCAG 2.1 does not deprecate or supersede WCAG 2.0. While WCAG 2.0 remains a W3C Recommendation, the W3C advises the use of WCAG 2.1 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.

    +

    Web Content Accessibility Guidelines (WCAG) 2.2 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content more accessible to a wider range of people with disabilities, including accommodations for blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and combinations of these, and some accommodation for learning disabilities and cognitive limitations; but will not address every user need for people with these disabilities. These guidelines address accessibility of web content on desktops, laptops, tablets, and mobile devices. Following these guidelines will also often make Web content more usable to users in general.

    +

    WCAG 2.2 success criteria are written as testable statements that are not technology-specific. Guidance about satisfying the success criteria in specific technologies, as well as general information about interpreting the success criteria, is provided in separate documents. See Web Content Accessibility Guidelines (WCAG) Overview for an introduction and links to WCAG technical and educational material.

    +

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

    -

    This is an Editors' Draft of Web Content Accessibility Guidelines (WCAG) 2.1. WCAG 2.1 is a W3C Recommendation. This draft incorporates errata and are described in the change log. At some point these changes might be incorporated into a Edited or Amended 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.1 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.1 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.1 builds on WCAG 2.0 [[!WCAG20]], which in turn built on WCAG 1.0 [[WAI-WEBCONTENT]] and is designed to apply broadly to different Web technologies now and in the future, and to be testable with a combination of automated testing and human evaluation. For an introduction to WCAG, see the Web Content Accessibility Guidelines (WCAG) Overview.

    +

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

    +

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

    Significant challenges were encountered in defining additional criteria to address cognitive, language, and learning disabilities, including a short timeline for development as well as challenges in reaching consensus on testability, implementability, and international considerations of proposals. Work will carry on in this area in future versions of WCAG. We encourage authors to refer to our supplemental guidance on improving inclusion for people with disabilities, including learning and cognitive disabilities, people with low-vision, and more.

    @@ -35,108 +39,103 @@

    Background on WCAG 2

  • Essential Components of Web Accessibility
  • User Agent Accessibility Guidelines (UAAG) Overview
  • Authoring Tool Accessibility Guidelines (ATAG) Overview
  • - + +

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

      +

      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.1 Supporting Documents

    -

    The WCAG 2.1 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.1 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:

    +
    +

    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.1 - A customizable quick reference to WCAG 2.1 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 and WCAG 2.1 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.1 - A guide to understanding and implementing WCAG 2.1. There is a short "Understanding" document for each guideline and success criterion in WCAG 2.1 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.1 - 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.1 supporting material, including education resources related to WCAG 2. Additional resources covering topics such as the business case for Web accessibility, planning implementation to improve the accessibility of Web sites, and accessibility policies are listed in WAI Resources.

    +

    See Web Content Accessibility Guidelines (WCAG) Overview for a description of the WCAG 2.2 supporting material, including education resources related to WCAG 2. Additional resources covering topics such as the business case for Web accessibility, planning implementation to improve the accessibility of Web sites, and accessibility policies are listed in WAI Resources.

    -
    -

    Requirements for WCAG 2.1

    -

    WCAG 2.1 meets a set of requirements for WCAG 2.1 which, in turn, inherit requirements from WCAG 2.0. 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.1. This constraint was important to preserve its nature as a dot-release of WCAG 2.

    +
    +

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

    -

    WCAG 2.1 was initiated with the goal to improve 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.1 incrementally advances web content accessibility guidance for all these areas, but underscores that not all user needs are met by these guidelines.

    - -

    WCAG 2.1 builds on and is backwards compatible with WCAG 2.0, meaning web pages that conform to WCAG 2.1 also conform to WCAG 2.0. Authors that are required by policy to conform with WCAG 2.0 will be able to update content to WCAG 2.1 without losing conformance with WCAG 2.0. Authors following both sets of guidelines should be aware of the following differences:

    -
    -

    New Features in WCAG 2.1

    -

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

    -

    The following Success Criteria are new in WCAG 2.1:

    -
      -
    • 1.3.4 Orientation (AA)
    • -
    • 1.3.5 Identify Input Purpose (AA)
    • -
    • 1.3.6 Identify Purpose (AAA)
    • -
    • 1.4.10 Reflow (AA)
    • -
    • 1.4.11 Non-Text Contrast (AA)
    • -
    • 1.4.12 Text Spacing (AA)
    • -
    • 1.4.13 Content on Hover or Focus (AA)
    • -
    • 2.1.4 Character Key Shortcuts (A)
    • -
    • 2.2.6 Timeouts (AAA)
    • -
    • 2.3.3 Animation from Interactions (AAA)
    • -
    • 2.5.1 Pointer Gestures (A)
    • -
    • 2.5.2 Pointer Cancellation (A)
    • -
    • 2.5.3 Label in Name (A)
    • -
    • 2.5.4 Motion Actuation (A)
    • -
    • 2.5.5 Target Size (AAA)
    • -
    • 2.5.6 Concurrent Input Mechanisms (AAA)
    • -
    • 4.1.3 Status Messages (AA)
    • +
      +

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

      + -

      Many of these success criteria reference new terms that have also been added to the glossary and form part of the normative requirements of the success criteria.

      -

      In the Conformance section, a third note about page variants has been added to Full Pages, and an option for machine-readable metadata added to Optional Components of a Conformance Claim.

      +

      The new success criteria may reference new terms that have also been added to the glossary and form part of the normative requirements of the success criteria.

      +

      WCAG 2.2 also introduces new sections detailing aspects of the specification which may impact privacy and security.

      +
      -
      -

      Numbering in WCAG 2.1

      -

      In order to avoid confusion for implementers for whom backwards compatibility to WCAG 2.0 is important, new success criteria in WCAG 2.1 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.0, 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.1 Quick Reference provides ways to view success criteria grouped by conformance level, along with many other filter and sort options.

      +
      +

      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.

      -
      -

      Conformance to WCAG 2.1

      -

      WCAG 2.1 uses the same conformance model as WCAG 2.0 with a couple additions, which is described in the Conformance section. It is intended that sites that conform to WCAG 2.1 also conform to WCAG 2.0, which means they meet the requirements of any policies that reference WCAG 2.0, while also better meeting the needs of users on the current Web.

      +
      +

      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.1, 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.1 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.

      +

      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.

      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.

      @@ -159,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.

      @@ -177,7 +176,7 @@

      Adaptable

      -
      +

      Distinguishable

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

      @@ -206,6 +205,7 @@

      Distinguishable

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

      Distinguishable

      Operable

      User interface components and navigation must be operable.

      -
      +

      Keyboard Accessible

      Make all functionality available from a keyboard.

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

      Keyboard Accessible

      -
      +

      Enough Time

      Provide users enough time to read and use content.

      @@ -245,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.

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

      Seizures and Physical Reactions

      -
      + -
      +

      Input Modalities

      -

      New

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

      @@ -296,10 +301,14 @@

      Input Modalities

      -
      +
      +
      + +
      +
      @@ -307,7 +316,7 @@

      Input Modalities

      Understandable

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

      -
      +

      Readable

      Make text content readable and understandable.

      @@ -325,7 +334,7 @@

      Readable

      -
      +

      Predictable

      Make Web pages appear and operate in predictable ways.

      @@ -338,10 +347,12 @@

      Predictable

      + +
      -
      +

      Input Assistance

      Help users avoid and correct mistakes.

      @@ -356,7 +367,13 @@

      Input Assistance

      + +
      + +
      +
      +
      @@ -364,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.

      @@ -380,33 +397,35 @@

      Compatible

      Conformance

      -

      This section lists requirements for conformance to WCAG 2.1. 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.1 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.

      +

      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.

      The key words MAY, MUST, MUST NOT, NOT RECOMMENDED, RECOMMENDED, SHOULD, and SHOULD NOT are to be interpreted as described in [[RFC2119]].

      Conformance Requirements

      -

      In order for a Web page to conform to WCAG 2.1, all of the following conformance requirements must be satisfied:

      +

      In order for a Web page to conform to WCAG 2.2, all of the following conformance requirements must be satisfied:

      +

      Conformance Level

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

        -
      • For Level A conformance (the minimum level of conformance), the Web page +
      • 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.

      -
      + +

      Full pages

      Conformance (and conformance level) is for full Web page(s) only, and cannot be achieved if part of a Web page is excluded.

      For the purpose of determining conformance, alternatives to part of a page's content are considered part of the page when the alternatives can be obtained directly from the page, e.g., a long description or an alternative presentation of a video.

      @@ -414,20 +433,23 @@

      Full pages

      A full page includes each variation of the page that is automatically presented by the page for various screen sizes (e.g. variations in a responsive Web page). Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform.

      -
      + +

      Complete processes

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

      -

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

      -
      + +

      Non-Interference

      If technologies are used in a way that is not accessibility supported, or if they are used in a non-conforming way, then they do not block the ability of users to access the rest of the page. In addition, the Web page as a whole continues to meet the conformance requirements under each of the following conditions:

        @@ -444,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.

    @@ -455,10 +477,10 @@

    Conformance Claims (Optional)

    Required Components of a Conformance Claim

    -

    Conformance claims are not required. Authors can conform to WCAG 2.1 without making a claim. However, if a conformance claim is made, then the conformance claim must include the following information:

    +

    Conformance claims are not required. Authors can conform to WCAG 2.2 without making a claim. However, if a conformance claim is made, then the conformance claim must include the following information:

    1. Date of the claim
    2. -
    3. Guidelines title, version and URI "Web Content Accessibility Guidelines 2.1 at https://www.w3.org/TR/WCAG21/"
    4. +
    5. Guidelines title, version and URI "Web Content Accessibility Guidelines 2.2 at https://www.w3.org/TR/WCAG22/"
    6. Conformance level satisfied: (Level A, AA or AAA)
    7. A concise description of the Web pages, such as a list of URIs for which the claim is made, including whether subdomains are included in the claim.

      @@ -479,21 +501,21 @@

      Optional Components of a Conformance Claim

    8. A list of success criteria beyond the level of conformance claimed that have been met. This information should be provided in a form that users can use, preferably machine-readable metadata.
    9. A list of the specific technologies that are " used but not relied upon."
    10. A list of user agents, including assistive technologies that were used to test the content.
    11. -
    12. A list of specific accessibility characteristics of the content, provided in machine-readable metadata.
    13. +
    14. A list of specific accessibility characteristics of the content, provided in machine-readable metadata.
    15. Information about any additional steps taken that go beyond the success criteria to enhance accessibility.
    16. A machine-readable metadata version of the list of specific technologies that are relied upon.
    17. A machine-readable metadata version of the conformance claim.
    18. -

      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. @@ -501,7 +523,7 @@

      Statement of Partial Conformance - Third Party Content

      OR

    2. -

      A "statement of partial conformance" may be made that the page does not conform, but could conform if certain parts were removed. The form of that statement would be, "This page does not conform, but would conform to WCAG 2.1 at level X if the following parts from uncontrolled sources were removed." In addition, the following would also be true of uncontrolled content that is described in the statement of partial conformance:

      +

      A "statement of partial conformance" may be made that the page does not conform, but could conform if certain parts were removed. The form of that statement would be, "This page does not conform, but would conform to WCAG 2.2 at level X if the following parts from uncontrolled sources were removed." In addition, the following would also be true of uncontrolled content that is described in the statement of partial conformance:

      1. It is not content that is under the author's control.
      2. It is described in a way that users can identify (e.g., they cannot be described as "all parts that we do not control" unless they are clearly marked as such.)
      3. @@ -512,7 +534,37 @@

        Statement of Partial Conformance - Third Party Content

        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.1 at level X if accessibility support existed for the following language(s):"

        +

        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:

        +
    @@ -547,6 +599,8 @@

    Glossary

    + +
    @@ -564,15 +618,21 @@

    Glossary

    +
    +
    +
    +
    -
    +
    + +
    @@ -610,6 +670,8 @@

    Glossary

    +
    +
    @@ -622,6 +684,8 @@

    Glossary

    +
    +
    @@ -665,7 +729,7 @@

    Glossary

    - +
    @@ -719,12 +783,32 @@

    Glossary

    Change Log

    -

    This section shows changes proposed for WCAG 2.1 since its publication as a W3C Recommendation. These changes are also recorded as errata.

    -

    The full commit history to WCAG 2.1 is available.

    -

    No changes have been made to date.

    +

    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.

    + +
    +
    +

    Acknowledgments

    +

    Additional information about participation in the Accessibility Guidelines Working Group (AG WG) can be found on the Working Group home page.

    +
    +
    +
    -
    -

    Acknowledgements

    -
    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 0515f9ebc6..a6189081a5 100644 --- a/guidelines/respec-config.js +++ b/guidelines/respec-config.js @@ -11,27 +11,27 @@ 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/ - shortName: "WCAG21", + shortName: "WCAG22", // if you wish the publication date to be other than today, set this //publishDate: "2014-12-11", - copyrightStart: "2017", + copyrightStart: "2020", license: "document", // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date // and its maturity status //previousPublishDate: "2014-06-12", //previousMaturity: "WD", - prevRecURI: "https://www.w3.org/TR/2018/REC-WCAG21-20180605/", + 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 - edDraftURI: "https://w3c.github.io/wcag/21/guidelines/", + edDraftURI: "https://w3c.github.io/wcag/guidelines/22/", // if this is a LCWD, uncomment and set the end of its review period // lcEnd: "2012-02-21", @@ -39,39 +39,47 @@ var respecConfig = { // editors, add as many as you like // only "name" is required editors: [ - { - name: "Andrew Kirkpatrick", - url: "http://www.adobe.com/", - mailto: "akirkpat@adobe.com", - company: "Adobe", - companyURI: "http://www.adobe.com/", - w3cid: 39770 - }, - { - name: "Joshue O Connor", - url: "http://interaccess.ie/", - mailto: "josh@interaccess.ie", - company: "Invited Expert, InterAccess", - companyURI: "http://interaccess.ie/", - w3cid: 41218 - }, { 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: "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: "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/", + mailto: "akirkpat@adobe.com", + company: "Adobe", + companyURI: "http://www.adobe.com/", + w3cid: 39770 } ], + /* formerEditors: [ { name: "Ben Caldwell", @@ -102,8 +110,14 @@ var respecConfig = { name: "Jason White", company: "University of Melbourne", w3cid: 74028 + }, + { + name: "Joshue O Connor", + company: "Invited Expert, InterAccess", + w3cid: 41218 } ], + */ // authors, add as many as you like. // This is optional, uncomment if you have authors as well as editors. @@ -122,27 +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, - localBiblio: biblio, - - 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 @@ -
    + @@ -577,19 +466,19 @@

    Additional Techniques (Advisory) for Info and Relationships

  • - Using CSS to control visual presentation of text + Using CSS to control visual presentation of text
  • - Positioning labels to maximize predictability of relationships + Positioning labels to maximize predictability of relationships
  • - ARIA1: Using Accessible Rich Internet Application describedby property to provide + ARIA1: Using Accessible Rich Internet Application describedby property to provide a descriptive, programmatically determined label @@ -597,7 +486,7 @@

    Additional Techniques (Advisory) for Info and Relationships

  • - Using Dynamic Web Content Accessibility to programmatically identify form fields as + Using Dynamic Web Content Accessibility to programmatically identify form fields as required @@ -605,7 +494,7 @@

    Additional Techniques (Advisory) for Info and Relationships

  • - G141 + G141
  • @@ -621,7 +510,7 @@

    Failures for Info and Relationships

  • - Failure due to using CSS to create variations in presentation of text that conveys + Failure due to using CSS to create variations in presentation of text that conveys information without also using the appropriate markup or text @@ -629,7 +518,7 @@

    Failures for Info and Relationships

  • - Failure due to using white space characters to create multiple columns in plain text + Failure due to using white space characters to create multiple columns in plain text content @@ -637,19 +526,19 @@

    Failures for Info and Relationships

  • - Failure due to using white space characters to format tables in plain text content + Failure due to using white space characters to format tables in plain text content
  • - Failure due to using scripting events to emulate links + Failure due to using scripting events to emulate links
  • - Failure due to using structural markup in a way that does not represent relationships + Failure due to using structural markup in a way that does not represent relationships in the content @@ -657,7 +546,7 @@

    Failures for Info and Relationships

  • - Failure due to using th elements, caption elements, or non-empty summary attributes + Failure due to using th elements, caption elements, or non-empty summary attributes in layout tables @@ -665,31 +554,25 @@

    Failures for Info and Relationships

  • - Failure due to using the pre element to markup tabular information - -
  • - -
  • - - + Failure due to using the pre element to markup tabular information
  • - +
  • - +
  • - +
  • diff --git a/understanding/20/input-assistance.html b/understanding/20/input-assistance.html index a83187e58b..766a265838 100644 --- a/understanding/20/input-assistance.html +++ b/understanding/20/input-assistance.html @@ -3,7 +3,7 @@ Understanding Input Assistance - +

    Understanding Input Assistance

    diff --git a/understanding/20/interruptions.html b/understanding/20/interruptions.html index 87b0aa76e4..24b9eefe81 100644 --- a/understanding/20/interruptions.html +++ b/understanding/20/interruptions.html @@ -3,12 +3,21 @@ Understanding Interruptions - +

    Understanding Interruptions

    - +
    +

    In brief

    +
    +
    Goal
    Users are not interrupted.
    +
    What to do
    Let people delay or turn off updates, except in emergencies.
    +
    Why it's important
    Updates distract and disrupt assistive technology users and people with attention deficits.
    +
    + +
    +

    Intent of Interruptions

    @@ -46,25 +55,11 @@

    Benefits of Interruptions

    Examples of Interruptions

    - -
      - -
    • - -

      - - Example 1. Setting user preferences - -

      - -

      The preferences page of a Web portal includes an option to postpone all updates and - alerts until the end of the current session, except for alerts concerning emergencies. - -

      - -
    • - -
    +
    +
    Example 1. Setting user preferences
    +
    The preferences page of a Web portal includes an option to postpone all updates and + alerts until the end of the current session, except for alerts concerning emergencies.
    +
    @@ -82,17 +77,17 @@

    Techniques for Interruptions

    Sufficient Techniques for Interruptions

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

    Failures for Interruptions

  • - Failure due to using meta redirect with a time limit + Failure due to using meta redirect with a time limit @@ -130,7 +125,7 @@

    Failures for Interruptions

  • - Failure due to using meta refresh with a time limit + Failure due to using meta refresh with a time limit diff --git a/understanding/20/keyboard-accessible.html b/understanding/20/keyboard-accessible.html index 26652e5f46..3a882c24a3 100644 --- a/understanding/20/keyboard-accessible.html +++ b/understanding/20/keyboard-accessible.html @@ -3,7 +3,7 @@ Understanding Keyboard Accessible - +

    Understanding Keyboard Accessible

    diff --git a/understanding/20/keyboard-no-exception.html b/understanding/20/keyboard-no-exception.html index e48e209dea..695fd9ece8 100644 --- a/understanding/20/keyboard-no-exception.html +++ b/understanding/20/keyboard-no-exception.html @@ -3,24 +3,60 @@ Understanding Keyboard (No Exception) - +

    Understanding Keyboard (No Exception)

    +
    +

    In brief

    +
    +
    Goal
    Everything can be done with a keyboard.
    +
    What to do
    Ensure all pointer actions have a keyboard equivalent.
    +
    Why it's important
    People who can only use the keyboard interface need to be able to accomplish everything.
    +
    + +

    Intent of Keyboard (No Exception)

    -

    The intent of this Success Criterion is to ensure that +

    The intent of this Success Criterion is to ensure that all content is operable from the keyboard. This is the same as Success Criterion 2.1.1, except that no exceptions are allowed. This does not mean that content where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (excluded from the requirements of 2.1.1) must be made keyboard accessible. Rather, it means that content that uses path-dependent input cannot conform to this - Success Criterion and therefore cannot meet Guideline 2.1 at Level AAA. + Success Criterion and therefore cannot meet Guideline 2.1 at Level AAA.

    + +
    +

    Platforms and user agents usually have conventions for how web content or + applications are controlled with a keyboard interface. If content does not follow + the platform/user agent conventions it may be difficult to use, as users will need + to learn different interaction methods. As a best practice, content + should follow the platform/user agent conventions. However, deviating from these + conventions does not fail the normative requirement of this Success Criterion.

    +

    + For instance, buttons that have focus can generally be activated using both the + Enter key and the Space bar. If a custom button control + in a web application instead only reacts to Enter + (or even a completely custom key or key combination), this still + satisfies the requirements of this Success Criterion. +

    +
    + +
    +

    This Success Criterion does not require that every visible control that can be activated + using a pointer (such as a mouse or touch screen input) must also be focusable and actionable using the keyboard. + The normative requirement is only that there must be a way for keyboard interface users to perform + the same, or comparable, actions and to operate the content. Generally, the easiest way + to achieve this is to provide controls that can be operated with all possible input devices; + however, if a web application implements a separate mode of operation for keyboard interface users, + it will not fail the Success Criterion. +

    +
    diff --git a/understanding/20/keyboard.html b/understanding/20/keyboard.html index af8a13d28a..c779848171 100644 --- a/understanding/20/keyboard.html +++ b/understanding/20/keyboard.html @@ -3,11 +3,20 @@ Understanding Keyboard - +

    Understanding Keyboard

    +
    +

    In brief

    +
    +
    Goal
    Everything can be done with a keyboard except freehand movements.
    +
    What to do
    Ensure pointer actions have a keyboard equivalent.
    +
    Why it's important
    Many people rely on the keyboard interface, including blind and some mobility impaired people.
    +
    + +

    Intent of Keyboard

    @@ -41,8 +50,7 @@

    Intent of Keyboard

    example, clicking, selecting, moving, sizing). However, there is a small class of input that is done with a pointing device that cannot be done from the keyboard in any known fashion without requiring an inordinate number of keystrokes. Free hand - drawing, watercolor painting, and flying a helicopter through an obstacle course are - all examples of functions that require path dependent input. Drawing straight lines, + drawing, or watercolor painting require path dependent input. Drawing straight lines, regular geometric shapes, re-sizing windows and dragging objects to a location (when the path to that location is not relevant) do not require path dependent input. @@ -60,6 +68,32 @@

    Intent of Keyboard

    +
    +

    Platforms and user agents usually have conventions for how web content or + applications are controlled with a keyboard interface. If content does not follow + the platform/user agent conventions it may be difficult to use, as users will need + to learn different interaction methods. As a best practice, content + should follow the platform/user agent conventions. However, deviating from these + conventions does not fail the normative requirement of this Success Criterion.

    +

    + For instance, buttons that have focus can generally be activated using both the + Enter key and the Space bar. If a custom button control + in a web application instead only reacts to Enter + (or even a completely custom key or key combination), this still + satisfies the requirements of this Success Criterion. +

    +
    + +
    +

    This Success Criterion does not require that every visible control that can be activated + using a mouse or touch screen must also be focusable and actionable using the keyboard. + The normative requirement is only that there must be a way for keyboard interface users to perform + the same, or comparable, actions and to operate the content. Generally, the easiest way + to achieve this is to provide controls that can be operated with all possible input devices; + however, if a web application implements a separate mode of operation for keyboard interface users, + it will not fail the Success Criterion. +

    +
    @@ -88,96 +122,30 @@

    Benefits of Keyboard

    Examples of Keyboard

    - -
      - -
    • - -

      - - Example 1: A drawing Program. - -

      - -

      A drawing program allows users to create, size, position and rotate objects from the - keyboard. -

      - -
    • - -
    • - -

      - - Example 2: A drag and Drop Feature. - -

      - -

      An application that uses drag and drop also supports "cut" and "paste" or form controls - to move objects. -

      - -
    • - -
    • - -

      - - Example 3: Moving between and connecting discrete points. - -

      - -

      A connect-the-dots program allows the user to move between dots on a screen and use - the spacebar to connect the current dot to the previous one. -

      - -
    • - -
    • - -

      - - Example 4: Exception - Painting Program. - -

      - -

      A watercolor painting program passes as an exception because the brush strokes vary - depending on the speed and duration of the movements. -

      - -
    • - -
    • - -

      - - Example 5: Exception - Model helicopter flight training simulator. - -

      - -

      A model helicopter flight training simulator passes as an exception because the nature - of the simulator is to teach real-time behavior of a model helicopter. -

      - -
    • - -
    • - -

      - - Example 6: A PDA with an optional keyboard - -

      - -

      A PDA device that is usually operated via a stylus has an optional keyboard that can +

      +
      Example 1: A drawing Program
      +
      A drawing program allows users to create, size, position and rotate objects from the keyboard.
      +
      Example 2: A drag and Drop Feature
      +
      An application that uses drag and drop also supports "cut" and "paste" or form controls to move objects.
      +
      Example 3: Moving between and connecting discrete points
      +
      A connect-the-dots program allows the user to move between dots on a screen and use + the spacebar to connect the current dot to the previous one.
      +
      Example 4: Exception - Painting Program
      +
      A watercolor painting program passes as an exception because the brush strokes vary + depending on the speed and duration of the movements.
      +
      Example 5: Exception - Model helicopter flight training simulator
      +
      A model helicopter flight training simulator passes as an exception because the nature + of the simulator is to teach real-time behavior of a model helicopter.
      +
      Example 6: A PDA with an optional keyboard
      +
      A PDA device that is usually operated via a stylus has an optional keyboard that can be attached. The keyboard allows full Web browsing in standard fashion. The Web - content is operable because it was designed to work with keyboard-only access. -

      - -
    • - -
    - + content is operable because it was designed to work with keyboard-only access. +
    Example 7: Simple search form with pointer-operable submit button
    +
    A search form includes a text input field followed by a submit button. The submit button itself + has been coded so that it does not receive focus, and can only be activated using a pointer input. + However, since keyboard users can submit the search by pressing Enter in the text input + after typing their search terms, the form passes this Success Criterion.
    +
    @@ -194,11 +162,11 @@

    Techniques for Keyboard

    Sufficient Techniques for Keyboard

    -
      +
    +
    @@ -328,9 +245,9 @@

    Additional Techniques (Advisory) for Keyboard

    @@ -307,7 +271,7 @@

    Failures for Labels or Instructions

  • - Failure of Success Criterion 3.3.2 by visually formating a set of phone number fields + Failure of Success Criterion 3.3.2 by visually formatting a set of phone number fields but not including a text label diff --git a/understanding/20/language-of-page.html b/understanding/20/language-of-page.html index 39782eb40a..05ecb7bcc0 100644 --- a/understanding/20/language-of-page.html +++ b/understanding/20/language-of-page.html @@ -3,11 +3,20 @@ Understanding Language of Page - +

    Understanding Language of Page

    +
    +

    In brief

    +
    +
    Goal
    Assistive technology can determine the language of a page.
    +
    What to do
    Indicate the predominant language on a page.
    +
    Why it's important
    People using assistive technology get information in the correct language.
    +
    + +

    Intent of Language of Page

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

    Intent of Language of Page

    The default human language of the Web page is the default text-processing language as discussed in - Internationalization Best Practices: Specifying Language in XHTML & HTML Content. When a Web page uses several languages, the default text-processing language is + Internationalization Best Practices: Specifying Language in XHTML & HTML Content. When a Web page uses several languages, the default text-processing language is the language which is used most. (If several languages are used equally, the first language used should be chosen as the default human language.) @@ -76,26 +85,12 @@

    Benefits of Language of Page

    Examples of Language of Page

    - -
      - -
    • - -

      - - Example 1. A Web page with content in two languages - -

      - -

      A Web page produced in Germany and written in HTML includes content in both German +

      +
      Example 1. A Web page with content in two languages
      +
      A Web page produced in Germany and written in HTML includes content in both German and English, but most of the content is in German. The default human language is identified - as German (de) by the lang attribute on the html element. - -

      - -
    • - -
    + as German (de) by the lang attribute on the html element. +
    @@ -107,7 +102,7 @@

    Resources for Language of Page

  • - Internationalization Best Practices: Specifying Language in XHTML & HTML Content + Internationalization Best Practices: Specifying Language in XHTML & HTML Content
  • @@ -124,33 +119,27 @@

    Techniques for Language of Page

    Sufficient Techniques for Language of Page

    -
      - -
    1. - - Using the lang attribute of the html element - -
    2. +
    +
    @@ -162,7 +151,7 @@

    Additional Techniques (Advisory) for Language of Page

  • - Specifying the default language in the HTTP header + Specifying the default language in the HTTP header
  • diff --git a/understanding/20/language-of-parts.html b/understanding/20/language-of-parts.html index 93478c1c8c..d0afe39b65 100644 --- a/understanding/20/language-of-parts.html +++ b/understanding/20/language-of-parts.html @@ -3,18 +3,27 @@ Understanding Language of Parts - +

    Understanding Language of Parts

    - - + +
    +

    In brief

    +
    +
    Goal
    Assistive technology can identify the languages used within a page.
    +
    What to do
    Indicate when words are in a different language.
    +
    Why it's important
    People using assistive technology get information in the correct language.
    +
    + +
    +

    Intent of Language of Parts

    The intent of this Success Criterion is to ensure that user agents can correctly present - content written in multiple languages. This makes it possible for user agents and + phrases, passages, and in some cases words written in multiple languages. This makes it possible for user agents and assistive technologies to present content according to the presentation and pronunciation rules for that language. This applies to graphical browsers as well as screen readers, braille displays, and other voice browsers. @@ -31,9 +40,9 @@

    Intent of Language of Parts

    When no other language has been specified for a phrase or passage of text, its human - language is the default human language of the Web page (see Success Criterion 3.1.1). + language is the default human language of the Web page (see Success Criterion 3.1.1). So the human language of all content in single language documents can be programmatically - determined. + determined.

    Individual words or phrases in one language can become part of another language. For @@ -48,7 +57,6 @@

    Intent of Language of Parts

    whether a change in language is intended, consider whether the word would be pronounced the same (except for accent or intonation) in the language of the immediately surrounding text. -

    Most professions require frequent use of technical terms which may originate from @@ -60,9 +68,7 @@

    Intent of Language of Parts

    and habeas corpus.

    -

    Identifying changes in language is important for a number of reasons: - -

    +

    Identifying changes in language is important for a number of reasons:

      @@ -74,8 +80,8 @@

      Intent of Language of Parts

    • Speech synthesizers that support multiple languages will be able to speak the text in the appropriate accent with proper pronunciation. If changes are not marked, the synthesizer will try its best to speak the words in the default language it works - in. Thus, the French word for car, "voiture" would be pronounced "voyture" by a speech - synthesizer that uses English as its default language. + in. Thus, the French word for car, "voiture" would be pronounced "voyture" by a speech + synthesizer that uses English as its default language.
    • Marking changes in language can benefit future developments in technology, for example @@ -94,11 +100,9 @@

      Intent of Language of Parts

      Benefits of Language of Parts

      -

      This Success Criterion helps:

        -
      • people who use screen readers or other technologies that convert text into synthetic speech;
      • @@ -124,80 +128,57 @@

        Benefits of Language of Parts

        Examples of Language of Parts

        - -
          - -
        1. - -

          - - A German phrase in an English sentence. - +

            +
          • +

            + A German phrase in an English sentence.

            -

            In the sentence, "He maintained that the DDR (German Democratic Republic) was just - a 'Treppenwitz der Weltgeschichte'," the German phrase 'Treppenwitz der Weltgeschichte' is marked as German. Depending on the markup language, English may either be marked + a 'Treppenwitz der Weltgeschichte'," the German phrase 'Treppenwitz der Weltgeschichte' is marked as German. Depending on the markup language, English may either be marked as the language for the entire document except where specified, or marked at the paragraph level. When a screen reader encounters the German phrase, it changes pronunciation rules from English to German to pronounce the word correctly.

            -
          • -
          • - -

            - - Alternative language links - +

            + Alternative language links

            -

            An HTML Web page includes links to versions of the page in other languages (e.g., - Deutsch, Français, Nederlands, Castellano, etc.). The text of each link is the name - of the language, in that language. The language of each link is indicated via a lang attribute. - + Deutsch, Français, Nederlands, Catalan, etc.). The text of each link is the name of the language, in that language. The language of each link is indicated via a lang attribute.

            - +
            <ul>
            +  <li><a href="..." lang="de">Deutsch</a></li>
            +  <li><a href="..." lang="it">Italiano</a></li>
            +  <li><a href="..." lang="fr">Français</a></li>
            +  ...
            +  <li><a href="..." lang="zh-hant">繁體中文</a></li>
            +</ul>
          • -
          • - -

            - - "Podcast" used in a French sentence. - +

            + "Podcast" used in a French sentence.

            -

            Because "podcast" is part of the vernacular of the immediately surrounding text in - the following excerpt, "À l'occasion de l'exposition "Energie éternelle. 1500 ans d'art indien", le Palais - des Beaux-Arts de Bruxelles a lancé son premier podcast. Vous pouvez télécharger ce - podcast au format M4A et MP3," no indication of language change is required. + the following excerpt, "À l'occasion de l'exposition "Energie éternelle. 1500 ans d'art indien", le Palais des Beaux-Arts de Bruxelles a lancé son premier podcast. Vous pouvez télécharger ce podcast au format M4A et MP3", no indication of language change is required.

            -
          • - -
        - +

      Resources for Language of Parts

      - - +
      @@ -205,61 +186,28 @@

      Resources for Language of Parts

      Techniques for Language of Parts

      -

      Sufficient Techniques for Language of Parts

      - - -
        - -
      1. - - Using the lang attribute to identify changes in the human language - -
      2. - -
      3. - - Using HTML language attributes to specify language in Flash content - -
      4. - -
      5. - - - + +
      +

    Additional Techniques (Advisory) for Language of Parts

    - -
      - -
    • - - - -
    • - -
    -

    Failures for Language of Parts

    - - +
    diff --git a/understanding/20/link-purpose-in-context.html b/understanding/20/link-purpose-in-context.html index d1f9119849..4c7533ba7c 100644 --- a/understanding/20/link-purpose-in-context.html +++ b/understanding/20/link-purpose-in-context.html @@ -3,11 +3,20 @@ Understanding Link Purpose (In Context) - +

    Understanding Link Purpose (In Context)

    +
    +

    In brief

    +
    +
    Goal
    Users understand what each link will do.
    +
    What to do
    Provide descriptive names or context for all links.
    +
    Why it's important
    People with visual and cognitive disabilities can navigate more easily.
    +
    + +

    Intent of Link Purpose (In Context)

    @@ -118,97 +127,29 @@

    Benefits of Link Purpose (In Context)

    Examples of Link Purpose (In Context)

    - - -
      - -
    • - -

      - - A link contains text that gives a description of the information at that URI - -

      - -

      - A page contains the sentence "There was much bloodshed during the Medieval period - of history." Where "Medieval period of history" is a link. - -

      - -
    • - -
    • - -

      - - A link is preceded by a text description of the information at that URI - -

      - -

      - A page contains the sentence "Learn more about the Government of Ireland's Commission - on Electronic Voting at Go Vote!" where "Go Vote!" is a link. - -

      - -
    • -
    • - -

      - - Both an icon and text are included in the same link - -

      - -

      - An icon of a voting machine and the text "Government of Ireland's Commission of Electronic +

      +
      A link contains text that gives a description of the information at that URI
      +
      A page contains the sentence "There was much bloodshed during the Medieval period + of history." Where "Medieval period of history" is a link.
      +
      A link is preceded by a text description of the information at that URI
      +
      A page contains the sentence "Learn more about the Government of Ireland's Commission + on Electronic Voting at Go Vote!" where "Go Vote!" is a link.
      +
      Both an icon and text are included in the same link
      +
      An icon of a voting machine and the text "Government of Ireland's Commission of Electronic Voting" are combined to make a single link. The alt text for the icon is null, since - the purpose of the link is already described by the text of the link next to the icon. - -

      - -
    • - -
    • - -

      - - A list of book titles - -

      - -

      - A list of books is available in three formats: HTML, PDF, and mp3 (a recording of + the purpose of the link is already described by the text of the link next to the icon. +

      A list of book titles
      +
      A list of books is available in three formats: HTML, PDF, and mp3 (a recording of a person reading the book). To avoid hearing the title of each book three times (once for each format), the first link for each book is the title of the book, the second - link says "PDF" and the third says, "mp3." - -

      - -
    • - -
    • - -

      - - News article summaries - -

      - -

      - A Web page contains a collection of news articles. The main page lists the first few + link says "PDF" and the third says, "mp3." +

      News article summaries
      +
      A Web page contains a collection of news articles. The main page lists the first few sentences of each article, followed by a "Read more" link. A screen reader command to read the current paragraph provides the context to interpret the purpose of the - link. - - -

      - -
    • - -
    + link. +
    @@ -248,31 +189,26 @@

    Techniques for Link Purpose (In Context)

    Sufficient Techniques for Link Purpose (In Context)

    -
      - -
    1. - - Providing link text that describes the purpose of a link - -
    2. +
    +
    @@ -431,19 +355,13 @@

    Additional Techniques (Advisory) for Link Purpose (In Context)

  • - Combining adjacent image and text links for the same resource - -
  • - -
  • - - Combining adjacent image and text buttons for the same resource + Combining adjacent image and text links for the same resource
  • - Identifying the purpose of a link using link text combined with the preceding heading + Identifying the purpose of a link using link text combined with the preceding heading element @@ -461,7 +379,7 @@

    Failures for Link Purpose (In Context)

  • - Failure of 2.4.4 due to providing link context only in content that is not related + Failure of 2.4.4 due to providing link context only in content that is not related to the link @@ -469,7 +387,7 @@

    Failures for Link Purpose (In Context)

  • - Failure of 2.4.4 due to using null alt on an image where the image is the only content + Failure of 2.4.4 due to using null alt on an image where the image is the only content in a link diff --git a/understanding/20/link-purpose-link-only.html b/understanding/20/link-purpose-link-only.html index f06e547096..e22b02ce94 100644 --- a/understanding/20/link-purpose-link-only.html +++ b/understanding/20/link-purpose-link-only.html @@ -3,11 +3,20 @@ Understanding Link Purpose (Link Only) - +

    Understanding Link Purpose (Link Only)

    +
    +

    In brief

    +
    +
    Goal
    Users understand what each link will do.
    +
    What to do
    Provide descriptive names for all links.
    +
    Why it's important
    Descriptive link text is more understandable for all users, especially when using assistive technology.
    +
    + +

    Intent of Link Purpose (Link Only)

    @@ -99,41 +108,17 @@

    Benefits of Link Purpose (Link Only)

    Examples of Link Purpose (Link Only)

    - -
      - -
    • - -

      - - Both an icon and text are included in the same link - -

      - -

      An icon of a voting machine and the text "Government of Ireland's Commission of Electronic - Voting" are combined to make a single link. -

      - -
    • - -
    • - -

      - - A list of book titles - -

      - -

      A list of books is available in three formats: HTML, PDF, and mp3 (a recording of +

      +
      Both an icon and text are included in the same link
      +
      An icon of a voting machine and the text "Government of Ireland's Commission of Electronic + Voting" are combined to make a single link.
      +
      A list of book titles
      +
      A list of books is available in three formats: HTML, PDF, and mp3 (a recording of a person reading the book). The title of the book is followed by links to the different formats. The rendered text for each link is just the format type, but the text associated with each link includes the title as well as the format; for instance, "Gulliver's - Travels, MP3." -

      - -
    • - -
    + Travels, MP3." +
    @@ -173,37 +158,32 @@

    Techniques for Link Purpose (Link Only)

    Sufficient Techniques for Link Purpose (Link Only)

    -
      +
    +
    @@ -292,19 +260,13 @@

    Additional Techniques (Advisory) for Link Purpose (Link Only)

  • - Combining adjacent image and text links for the same resource - -
  • - -
  • - - Combining adjacent image and text buttons for the same resource + Combining adjacent image and text links for the same resource
  • - Supplementing link text with the title attribute + Supplementing link text with the title attribute
  • @@ -320,7 +282,7 @@

    Failures for Link Purpose (Link Only)

  • - Failure of Success Criterion 2.4.9 due to using a non-specific link such as "click + Failure of Success Criterion 2.4.9 due to using a non-specific link such as "click here" or "more" without a mechanism to change the link text to specific text. @@ -328,7 +290,7 @@

    Failures for Link Purpose (Link Only)

  • - Failure of 2.4.4 due to using null alt on an image where the image is the only content + Failure of 2.4.4 due to using null alt on an image where the image is the only content in a link diff --git a/understanding/20/location.html b/understanding/20/location.html index e45b33918e..58b5cebda5 100644 --- a/understanding/20/location.html +++ b/understanding/20/location.html @@ -3,11 +3,21 @@ Understanding Location - +

    Understanding Location

    +
    +

    In brief

    +
    +
    Goal
    Users know where they are in a set of pages.
    +
    What to do
    Use breadcrumbs, site maps, or other indicators to give context.
    +
    Why it's important
    Location indicators reduce confusion for people with cognitive disabilities.
    +
    + +
    +

    Intent of Location

    @@ -39,39 +49,15 @@

    Benefits of Location

    Examples of Location

    - -
      - -
    • - -

      - - Links to help user determine their location in a site - -

      - -

      A research group is part of an educational department at a university. The group's - home page links to the department home page and the university's home page. -

      - -
    • - -
    • - -

      - - A breadcrumb trail - -

      - -

      A portal Web site organizes topics into categories. As the user navigates through +

      +
      Links to help user determine their location in a site
      +
      A research group is part of an educational department at a university. The group's + home page links to the department home page and the university's home page.
      +
      A breadcrumb trail
      +
      A portal Web site organizes topics into categories. As the user navigates through categories and subcategories, a breadcrumb trail shows the current location in the - hierarchy of categories. Each page also contains a link to the portal home page. -

      - -
    • - -
    + hierarchy of categories. Each page also contains a link to the portal home page. +
    @@ -99,46 +85,33 @@

    Techniques for Location

    Sufficient Techniques for Location

    -
      +
    +
    @@ -150,13 +123,13 @@

    Additional Techniques (Advisory) for Location

  • - +
  • - +
  • diff --git a/understanding/20/low-or-no-background-audio.html b/understanding/20/low-or-no-background-audio.html index 5d1661119a..66c22fc394 100644 --- a/understanding/20/low-or-no-background-audio.html +++ b/understanding/20/low-or-no-background-audio.html @@ -3,11 +3,21 @@ Understanding Low or No Background Audio - +

    Understanding Low or No Background Audio

    +
    +

    In brief

    +
    +
    Goal
    Prerecorded speech is not disrupted by background sound.
    +
    What to do
    Avoid or lessen background sound, or let users turn it off.
    +
    Why it's important
    People who are hard of hearing may have difficulty distinguishing speech from music and other sounds.
    +
    + +
    +

    Intent of Low or No Background Audio

    @@ -48,22 +58,22 @@

    Examples of Low or No Background Audio

    -
    +

    Resources for Low or No Background Audio

    - - + + - +
    - +

    Techniques for Low or No Background Audio

    @@ -72,17 +82,17 @@

    Techniques for Low or No Background Audio

    Sufficient Techniques for Low or No Background Audio

    -
      +
    +
    diff --git a/understanding/20/meaningful-sequence.html b/understanding/20/meaningful-sequence.html index e3af7fa438..3370f8d3cf 100644 --- a/understanding/20/meaningful-sequence.html +++ b/understanding/20/meaningful-sequence.html @@ -3,11 +3,20 @@ Understanding Meaningful Sequence - +

    Understanding Meaningful Sequence

    +
    +

    In brief

    +
    +
    Goal
    The order of content can be understood by more people.
    +
    What to do
    Use code to preserve meaningful content order.
    +
    Why it's important
    Assistive technology can present content to users in the proper order.
    +
    + +

    Intent of Meaningful Sequence

    @@ -49,7 +58,7 @@

    Intent of Meaningful Sequence

    For clarity:

    -
      +
      • Providing a particular linear order is only required where it affects meaning.
      • @@ -57,7 +66,7 @@

        Intent of Meaningful Sequence

      • Only one correct order needs to be provided.
      • -
    +
    @@ -114,11 +123,11 @@

    Techniques for Meaningful Sequence

    Sufficient Techniques for Meaningful Sequence

    -
      +
    +
    @@ -206,25 +203,25 @@

    Failures for Meaningful Sequence

  • - Failure due to using white space characters to format tables in text content + Failure due to using white space characters to format tables in text content
  • - Failure due to using white space characters to create multiple columns in text content + Failure due to using white space characters to create multiple columns in text content
  • - Failure due to using white space characters to control spacing within a word + Failure due to using white space characters to control spacing within a word
  • - Failure due to changing the meaning of content by positioning information with HTML + Failure due to changing the meaning of content by positioning information with HTML layout tables @@ -232,7 +229,7 @@

    Failures for Meaningful Sequence

  • - Failure due to changing the meaning of content by positioning information with CSS + Failure due to changing the meaning of content by positioning information with CSS
  • diff --git a/understanding/20/media-alternative-prerecorded.html b/understanding/20/media-alternative-prerecorded.html index 2e774e522f..66e69a7021 100644 --- a/understanding/20/media-alternative-prerecorded.html +++ b/understanding/20/media-alternative-prerecorded.html @@ -3,12 +3,22 @@ Understanding Media Alternative (Prerecorded) - +

    Understanding Media Alternative (Prerecorded)

    +
    +

    In brief

    +
    +
    Goal
    Precorded videos can be understood by more people.
    +
    What to do
    Provide a text equivalent for all content in videos.
    +
    Why it's important
    More people, including those who are deaf-blind, can better understand the content at their own pace.
    +
    + +
    +

    Intent of Media Alternative (Prerecorded)

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

    Benefits of Media Alternative (Prerecorded)

      -
    • People who cannot see well or at all and who also cannot hear well or at all can get +
    • People who are deaf-blind, who cannot see well or at all, and who also cannot hear well or at all can get access to information in audio-visual presentations.
    • @@ -88,28 +98,15 @@

      Benefits of Media Alternative (Prerecorded)

      Examples of Media Alternative (Prerecorded)

      - -
        - -
      • - -

        - - Example 1. alternative for time-based media for a training video - -

        - -

        A community center purchases a Training video for use by its clients and puts it on +

        +
        Example 1. alternative for time-based media for a training video
        +
        A community center purchases a Training video for use by its clients and puts it on the center's intranet. The video involves explaining use of a new technology and has a person talking and showing things at the same time. The community center provides an alternative for time-based media that all clients, including those who can neither see the demonstrations nor hear the explanations in the synchronized media, can use - to better understand what is being presented. -

        - -
      • - -
      + to better understand what is being presented. +
      @@ -147,29 +144,23 @@

      Sufficient Techniques for Media Alternative (Prerecorded)

      Situation A: If the content is prerecorded synchronized media:

      -
        +
      +
    @@ -200,34 +191,21 @@

    Situation A: If the content is prerecorded synchronized media:

    Situation B: If the content is prerecorded video-only:

    -
      +
    +
    -

    Additional Techniques (Advisory) for Media Alternative (Prerecorded)

    - - - -
    @@ -238,7 +216,7 @@

    Failures for Media Alternative (Prerecorded)

  • - Failure of 1.2.1 due to not labeling a synchronized media alternative to text as an + Failure of 1.2.1 due to not labeling a synchronized media alternative to text as an alternative diff --git a/understanding/20/multiple-ways.html b/understanding/20/multiple-ways.html index 4154c50a41..80eac3792f 100644 --- a/understanding/20/multiple-ways.html +++ b/understanding/20/multiple-ways.html @@ -3,11 +3,20 @@ Understanding Multiple Ways - +

    Understanding Multiple Ways

    +
    +

    In brief

    +
    +
    Goal
    Users can get to content in multiple ways.
    +
    What to do
    Provide at least two options for reaching the same content.
    +
    Why it's important
    Not everyone can navigate content in the same way.
    +
    + +

    Intent of Multiple Ways

    @@ -43,7 +52,7 @@

    Benefits of Multiple Ways

  • Individuals with cognitive limitations may find it easier to use search features than - to use a hierarchical navigation scheme that be difficult to understand. + to use a hierarchical navigation scheme that may be difficult to understand.
  • @@ -53,72 +62,26 @@

    Benefits of Multiple Ways

    Examples of Multiple Ways

    - -
      - -
    • - -

      - - A search mechanism. - -

      - -

      A large food processing company provides a site containing recipes created using its +

      +
      A search mechanism
      +
      A large food processing company provides a site containing recipes created using its products. The site provides a search mechanism to search for recipes using a particular ingredient. In addition, it provides a list box that lists several categories of foods. A user may type "soup" in to the search engine or may select "soup" from the list - box to go to a page with a list of recipes made from the company's soup products -

      - -
    • - -
    • - -

      - - Links between Web pages. - -

      - -

      A local hair salon has created a Web site to promote its services. The site contains + box to go to a page with a list of recipes made from the company's soup products. +

      Links between Web pages
      +
      A local hair salon has created a Web site to promote its services. The site contains only five Web pages. There are links on each Web page to sequentially move forward or backward through the Web pages. In addition, each Web page contains a list of links - to reach each of the other Web pages. -

      - -
    • - -
    • - -

      - - Where content is a result of a process or task - Funds transfer confirmation. - -

      - -

      An on-line banking site allows fund transfer between accounts via the Web. There is + to reach each of the other Web pages. +

      Where content is a result of a process or task - Funds transfer confirmation
      +
      An on-line banking site allows fund transfer between accounts via the Web. There is no other way to locate the confirmation of fund transfer until the account owner completes - the transfer. -

      - -
    • - -
    • - -

      - - Where content is a result of a process or task - Search engine results. - -

      - -

      A search engine provides the search results based on user input. There is no other - way to locate the search results except to perform the search process itself. -

      - -
    • - -
    + the transfer. +
    Where content is a result of a process or task - Search engine results
    +
    A search engine provides the search results based on user input. There is no other + way to locate the search results except to perform the search process itself.
    +
    @@ -136,7 +99,7 @@

    Techniques for Multiple Ways

    Sufficient Techniques for Multiple Ways

    -
      +
    +
    @@ -200,12 +157,12 @@

    Additional Techniques (Advisory) for Multiple Ways

    diff --git a/understanding/20/name-role-value.html b/understanding/20/name-role-value.html index 5e66a888d1..e0db538bbb 100644 --- a/understanding/20/name-role-value.html +++ b/understanding/20/name-role-value.html @@ -3,44 +3,61 @@ Understanding Name, Role, Value - +

    Understanding Name, Role, Value

    +
    +

    In brief

    +
    +
    Goal
    People using assistive technology understand all components.
    +
    What to do
    Give components correct names, roles, states, and values.
    +
    Why it's important
    Assistive technology only works well when code is done properly.
    +
    + +

    Intent of Name, Role, Value

    The intent of this Success Criterion is to ensure that Assistive Technologies (AT) - can gather information about, activate(or set) and keep up to date on the status of + can gather appropriate information about, activate (or set) and keep up to date on the status of user interface controls in the content.

    When standard controls from accessible technologies are used, this process is straightforward. If the user interface elements are used according to specification the conditions - of this provision will be met. (See examples of Success Criterion 4.1.2 below) + of this provision will be met. (See examples of Success Criterion 4.1.2 below)

    If custom controls are created, however, or interface elements are programmed (in code or script) to have a different role and/or function than usual, then additional - measures need to be taken to ensure that the controls provide important information + measures need to be taken to ensure that the controls provide important and appropriate information to assistive technologies and allow themselves to be controlled by assistive technologies.

    + +

    What roles and states are appropriate to convey to assistive technology will depend + on what the control represents. Specifics about such information are defined by other + specifications, such as WAI-ARIA, or the + relevant platform standards. Another factor to consider is whether there is sufficient + accessibility support with assistive technologies to convey the information as specified. +

    A particularly important state of a user interface control is whether or not it has focus. The focus state of a control can be programmatically determined, and notifications about change of focus are sent to user agents and assistive technology. Other examples - of user interface control state are whether or not a checkbox or radio button has - been selected, or whether or not a collapsible tree or list node is expanded or collapsed. + of user interface control states are whether or not a checkbox or radio button has + been selected, or whether a collapsible tree view or accordion is expanded or collapsed.

    - + +

    Success Criterion 4.1.2 requires a programmatically determinable name for all user - interface components. Names may be visible or invisible. Occasionally, the name must - be visible, in which case it is identified as a label. Refer to the definition of + interface components. Names may be visible or invisible. Occasionally, the name needs + to be visible, in which case it is identified as a label. Refer to the definition of name and label in the glossary for more information.

    @@ -66,22 +83,10 @@

    Benefits of Name, Role, Value

    Examples of Name, Role, Value

    - -
      - -
    • - -

      - - Accessible APIs - -

      - -

      A Java applet uses the accessibility API defined by the language.

      - -
    • - -
    +
    +
    Accessible APIs
    +
    A Java applet uses the accessibility API defined by the language.
    +
    @@ -90,37 +95,15 @@

    Resources for Name, Role, Value

    @@ -139,17 +122,17 @@

    Situation A: If using a standard user interface component in a markup langua HTML):

    -
      +
    +
    @@ -210,7 +193,7 @@

    Situation B: If using script or code to re-purpose a standard user interface in a markup language:

    -
      +
      • @@ -222,7 +205,7 @@

        Situation B: If using script or code to re-purpose a standard user interface
      • - +
      • @@ -230,7 +213,7 @@

        Situation B: If using script or code to re-purpose a standard user interface

      • -
    +
    @@ -238,59 +221,29 @@

    Situation B: If using script or code to re-purpose a standard user interface

    Situation C: If using a standard user interface component in a programming technology:

    -
      +
    +
    @@ -306,13 +259,13 @@

    Situation C: If using a standard user interface component in a programming t

    Situation D: If creating your own user interface component in a programming language:

    -
      +
    + @@ -385,36 +314,26 @@

    Failures for Name, Role, Value

    diff --git a/understanding/20/non-text-content.html b/understanding/20/non-text-content.html index d95136162b..d59a583f0e 100644 --- a/understanding/20/non-text-content.html +++ b/understanding/20/non-text-content.html @@ -3,11 +3,22 @@ Understanding Non-text Content - +

    Understanding Non-text Content

    +
    +

    In brief

    +
    + +
    Goal
    Non-text information is available to more people.
    +
    What to do
    Create a text alternative for visual and auditory content.
    +
    Why it's important
    People who can’t fully see or hear content can understand it.
    +
    + +
    +

    Intent of Non-text Content

    @@ -18,9 +29,9 @@

    Intent of Non-text Content

    way for making information accessible because they can be rendered through any sensory modality (for example, visual, auditory or tactile) to match the needs of the user. Providing text alternatives allows the information to be rendered in a variety of - ways by a variety of user agents. For example, a person who cannot see a picture can - have the text alternative read aloud using synthesized speech. A person who cannot - hear an audio file can have the text alternative displayed so that he or she can read + ways by a variety of user agents. For example, people who cannot see a picture can + have the text alternative read aloud using synthesized speech. People who cannot + hear an audio file can have the text alternative displayed so that they can read it. In the future, text alternatives will also allow information to be more easily translated into sign language or into a simpler form of the same language.

    @@ -228,105 +239,34 @@

    Benefits of Non-text Content

    Examples of Non-text Content

    - -
      - -
    1. - -

      - - A data chart - -

      - -

      A bar chart compares how many widgets were sold in June, July, and August. The short +

      +
      A data chart
      +
      A bar chart compares how many widgets were sold in June, July, and August. The short label says, "Figure one - Sales in June, July and August." The longer description identifies the type of chart, provides a high-level summary of the data, trends and implications comparable to those available from the chart. Where possible and practical, - the actual data is provided in a table. - - -

      - -
    2. - -
    3. - -

      - - An audio recording of a speech - -

      - -

      The link to an audio clip says, "Chairman's speech to the assembly." A link to a text - transcript is provided immediately after the link to the audio clip. - -

      - -
    4. - -
    5. - -

      - - An animation that illustrates how a car engine works - -

      - -

      An animation shows how a car engine works. There is no audio and the animation is + the actual data is provided in a table. +

      An audio recording of a speech
      +
      The link to an audio clip says, "Chairman's speech to the assembly." A link to a text + transcript is provided immediately after the link to the audio clip.
      +
      An animation that illustrates how a car engine works
      +
      An animation shows how a car engine works. There is no audio and the animation is part of a tutorial that describes how an engine works. Since the text of the tutorial already provides a full explanation, the image is an alternative for text and the text alternative includes only a brief description of the animation and refers to - the tutorial text for more information. - - -

      - -
    6. - -
    7. - -

      - - A traffic Web camera - -

      - -

      A Web site allows users to select from a variety of Web cameras positioned throughout + the tutorial text for more information. +

      A traffic Web camera
      +
      A Web site allows users to select from a variety of Web cameras positioned throughout a major city. After a camera is selected, the image updates every two minutes. A short text alternative identifies the Web camera as "traffic Web camera." The site also provides a table of travel times for each of the routes covered by the Web cameras. - The table is also updated every two minutes. - -

      - -
    8. - -
    9. - -

      - - A photograph of an historic event in a news story - -

      - -

      A photograph of two world leaders shaking hands accompanies a news story about an + The table is also updated every two minutes. +

      A photograph of an historic event in a news story
      +
      A photograph of two world leaders shaking hands accompanies a news story about an international summit meeting. The text alternative says, "President X of Country X - shakes hands with Prime Minister Y of country Y." - -

      - -
    10. - -
    11. - -

      - - A photograph of a historic event in content discussing diplomatic relationships - -

      - -

      The same image is used in a different context intended to explain nuances in diplomatic + shakes hands with Prime Minister Y of country Y." +

      A photograph of a historic event in content discussing diplomatic relationships
      +
      The same image is used in a different context intended to explain nuances in diplomatic encounters. The image of the president shaking hands with the prime minister appears on a Web site discussing intricate diplomatic relationships. The first text alternative reads, "President X of country X shakes hands with Prime Minister Y of country Y on @@ -334,112 +274,34 @@

      Examples of Non-text Content

      are standing as well as the expressions on the leaders' faces, and identifies the other people in the room. The additional description might be included on the same page as the photograph or in a separate file associated with the image through a link - or other standard programmatic mechanism. - -

      - -
    12. - -
    13. - -

      - - An audio recording of a press conference - -

      - -

      A Web page includes a link to an audio recording of a press conference. The link text + or other standard programmatic mechanism. +

      An audio recording of a press conference
      +
      A Web page includes a link to an audio recording of a press conference. The link text identifies the audio recording. The page also links to a text transcript of the press conference. The transcript includes a verbatim record of everything the speakers say. It identifies who is speaking as well as noting other significant sounds that are part of the recording, such as applause, laughter, questions from the audience, and - so on. - -

      - -
    14. - -
    15. - -

      - - - An e-learning application - - - -

      - -

      - An e-learning application uses sound effects to indicate whether or not the answers + so on. +

      An e-learning application
      +
      An e-learning application uses sound effects to indicate whether or not the answers are correct. The chime sound indicates that the answer is correct and the beep sound indicates that the answer is incorrect. A text description is also included so that people who can't hear or understand the sound understand whether the answer is correct - or incorrect. - - -

      - -
    16. - -
    17. - -

      - - - A linked thumbnail image - - - -

      - -

      A thumbnail image of the front page of a newspaper links to the home page of the "Smallville - Times". The text alternative says "Smallville Times". - -

      - -
    18. - -
    19. - -

      - - - The same image used on different sites - - - -

      - -

      Different alternatives for an image of the world: An image of the world that is used + or incorrect. +

      A linked thumbnail image
      +
      A thumbnail image of the front page of a newspaper links to the home page of the "Smallville + Times". The text alternative says "Smallville Times".
      +
      The same image used on different sites
      +
      Different alternatives for an image of the world: An image of the world that is used on a travel site as a link to the International Travel section has the text alternative "International Travel". The same image is used as a link on a university Web site - with the text alternative "International Campuses". - -

      - -
    20. - -
    21. - -

      - - - An image map - - - -

      - -

      An image of a building floor plan is interactive, allowing the user to select a + with the text alternative "International Campuses". +

      An image map
      +
      An image of a building floor plan is interactive, allowing the user to select a particular room and navigate to a page containing information about that room. The short text alternative describes the image and its interactive purpose: - "Building floor plan. Select a room for more information." -

      - -
    22. - -
    + "Building floor plan. Select a room for more information." +
    @@ -503,11 +365,11 @@

    Situation A: If a short description can serve the same purpose and present t information as the non-text content:

    -
      +
    +

    @@ -528,79 +390,49 @@

    Situation A: If a short description can serve the same purpose and present t
  • - - -
  • - -
  • - - - -
  • - -
  • - - - -
  • - -
  • - - - -
  • - -
  • - - +
  • - +
  • - +
  • - +
  • - +
  • - +
  • - +
  • - - -
  • - -
  • - - +
  • @@ -615,11 +447,11 @@

    Situation B: If a short description can a chart or diagram):

    -
      +
    +

    @@ -647,79 +479,50 @@

    Situation B: If a short description can
  • - +
  • - +
  • - +
  • - +
  • -
  • +
  • - + +
  • - +
  • - +
  • - - -
  • - -
  • - - - -
  • - -
  • - - - -
  • - -
  • - - - -
  • - -
  • - - - -
  • - -
  • - - +
  • @@ -734,55 +537,31 @@

    Situation B: If a short description can
  • - - -
  • - -
  • - - - -
  • - -
  • - - - -
  • - -
  • - - - -
  • - -
  • - - +
  • - +
  • - +
  • - +
  • - +
  • @@ -794,11 +573,11 @@

    Situation B: If a short description can

    Situation C: If non-text content is a control or accepts user input:

    -
      +
    +

    @@ -817,97 +596,43 @@

    Situation C: If non-text content is a control or accepts user input:

  • - - -
  • - -
  • - - - -
  • - -
  • - - - -
  • - -
  • - - - -
  • - -
  • - - - -
  • - -
  • - - - -
  • - -
  • - - - -
  • - -
  • - - - -
  • - -
  • - - +
  • - +
  • - +
  • - +
  • - +
  • - +
  • - - -
  • - -
  • - - +
  • @@ -922,7 +647,7 @@

    Situation D: If non-text content is time-based media (including live video-o primarily intended to create a specific sensory experience:

    -
      +
    +

    @@ -965,79 +690,49 @@

    Situation D: If non-text content is time-based media (including live video-o
  • - - -
  • - -
  • - - - -
  • - -
  • - - - -
  • - -
  • - - - -
  • - -
  • - - - -
  • - -
  • - - +
  • - +
  • - +
  • - +
  • - +
  • - +
  • - +
  • - +
  • @@ -1049,21 +744,21 @@

    Situation D: If non-text content is time-based media (including live video-o

    Situation E: If non-text content is a CAPTCHA:

    -
      +
    +
    @@ -1071,7 +766,7 @@

    Situation E: If non-text content is a CAPTCHA:

    Situation F: If the non-text content should be ignored by assistive technology:

    -
      +
      • Implementing or marking the non-text content so that it will be ignored by assistive technology using one of the following @@ -1082,7 +777,7 @@

        Situation F: If the non-text content should be ignored by assistive technolo :

      • -
    +

    @@ -1093,19 +788,13 @@

    Situation F: If the non-text content should be ignored by assistive technolo
  • - Using CSS to include decorative images - -
  • - -
  • - - Marking objects in Flash so that they can be ignored by AT + Using CSS to include decorative images
  • - Using null alt text and no title attribute on img elements for images that AT should + Using null alt text and no title attribute on img elements for images that AT should ignore @@ -1113,7 +802,7 @@

    Situation F: If the non-text content should be ignored by assistive technolo
  • - +
  • @@ -1126,22 +815,6 @@

    Situation F: If the non-text content should be ignored by assistive technolo

    Additional Techniques (Advisory) for Non-text Content

    -
    - -

    HTML Techniques (Advisory)

    - - - -
    -

    CSS Techniques (Advisory)

    @@ -1150,7 +823,7 @@

    CSS Techniques (Advisory)

  • - Using CSS margin and padding rules instead of spacer images + Using CSS margin and padding rules instead of spacer images
  • @@ -1158,22 +831,6 @@

    CSS Techniques (Advisory)

    -
    - -

    Silverlight Techniques (Advisory)

    - -
      - -
    • - - - -
    • - -
    - -
    -
    @@ -1184,13 +841,13 @@

    Failures for Non-text Content

  • - Failure due to using CSS to include images that convey important information + Failure due to using CSS to include images that convey important information
  • - Failure of Success Criterion 1.1.1 and 1.4.1 due to having a text alternative that + Failure of Success Criterion 1.1.1 and 1.4.1 due to having a text alternative that does not include information that is conveyed by color differences in the image @@ -1198,13 +855,13 @@

    Failures for Non-text Content

  • - Failure due to not updating text alternatives when changes to non-text content occur + Failure due to not updating text alternatives when changes to non-text content occur
  • - Failure due to using text alternatives that are not alternatives (e.g., filenames + Failure due to using text alternatives that are not alternatives (e.g., filenames or placeholder text) @@ -1212,7 +869,7 @@

    Failures for Non-text Content

  • - Failure due to omitting the alt-attribute for non-text content used for decorative + Failure due to omitting the alt-attribute for non-text content used for decorative purposes only in HTML @@ -1220,7 +877,7 @@

    Failures for Non-text Content

  • - Failure due to providing a text alternative that is not null. (e.g., alt="spacer" + Failure due to providing a text alternative that is not null. (e.g., alt="spacer" or alt="image") for Images that should be ignored by AT @@ -1228,7 +885,7 @@

    Failures for Non-text Content

  • - Failure of 1.1.1 due to omitting the alt attribute on img elements, area elements, + Failure of 1.1.1 due to omitting the alt attribute on img elements, area elements, and input elements of type "image" @@ -1236,7 +893,7 @@

    Failures for Non-text Content

  • - Failure of 1.1.1 due to providing long description for non-text content that does + Failure of 1.1.1 due to providing long description for non-text content that does not serve the same purpose or does not present the same information @@ -1244,7 +901,7 @@

    Failures for Non-text Content

  • - Failure of Success Criterion 1.1.1 due to using text look-alikes to represent text + Failure of Success Criterion 1.1.1 due to using text look-alikes to represent text without providing a text alternative @@ -1252,7 +909,7 @@

    Failures for Non-text Content

  • - Failure of Success Criterion 1.1.1 due to using ASCII art without providing a text + Failure of Success Criterion 1.1.1 due to using ASCII art without providing a text alternative diff --git a/understanding/20/on-focus.html b/understanding/20/on-focus.html index 700f02843c..91a2712073 100644 --- a/understanding/20/on-focus.html +++ b/understanding/20/on-focus.html @@ -3,11 +3,20 @@ Understanding On Focus - +

    Understanding On Focus

    +
    +

    In brief

    +
    +
    Goal
    Content can be navigated more predictably.
    +
    What to do
    Do not change a user's context when items get focus.
    +
    Why it's important
    Content that behaves predictably is especially important to people with disabilities.
    +
    + +

    Intent of On Focus

    @@ -39,7 +48,7 @@

    Intent of On Focus

    What is meant by "component" here is also sometimes called "user interface element" - or "user interface component''. + or "user interface component".

    @@ -63,48 +72,19 @@

    Benefits of On Focus

    Examples of On Focus

    - -
      - -
    • - -

      - - Example 1: A dropdown menu - -

      - -

      A dropdown menu on a page allows users to choose between jump destinations. If the +

      +
      Example 1: A dropdown menu
      +
      A dropdown menu on a page allows users to choose between jump destinations. If the person uses the keyboard to move down to a choice and activates it (with a spacebar or enter key) it will jump to a new page. However, if the person moves down to a choice and either hits the escape or the tab key to move out of the pulldown menu - – it does not jump to a new screen as the focus shifts out of the dropdown menu. -

      - -
    • - -
    • - -

      - - - Example of a Failure: A help dialog - - - -

      - -

      - When a field receives focus, a help dialog window describing the field and providing + – it does not jump to a new screen as the focus shifts out of the dropdown menu. +

      Example of a Failure: A help dialog
      +
      When a field receives focus, a help dialog window describing the field and providing options opens. As a keyboard user tabs through the Web page, the dialog opens, moving the keyboard focus away from the control every time the user attempts to tab past - the field. - -

      - -
    • - -
    + the field. +
    @@ -122,15 +102,15 @@

    Techniques for On Focus

    Sufficient Techniques for On Focus

    -
      +
    +
    @@ -151,13 +131,13 @@

    Additional Techniques (Advisory) for On Focus

  • - Opening new windows and tabs from a link only when necessary + Opening new windows and tabs from a link only when necessary
  • - Giving users advanced warning when opening a new window + Giving users advanced warning when opening a new window
  • @@ -173,7 +153,7 @@

    Failures for On Focus

  • - Failure due to using script to remove focus when focus is received + Failure due to using script to remove focus when focus is received
  • diff --git a/understanding/20/on-input.html b/understanding/20/on-input.html index 41f5a1c08c..66223c97b6 100644 --- a/understanding/20/on-input.html +++ b/understanding/20/on-input.html @@ -3,11 +3,20 @@ Understanding On Input - +

    Understanding On Input

    +
    +

    In brief

    +
    +
    Goal
    Content can be operated more predictably.
    +
    What to do
    Forewarn users if their context will change based on their input.
    +
    Why it's important
    Content that behaves predictably is especially important to people with disabilities.
    +
    + +

    Intent of On Input

    @@ -28,7 +37,7 @@

    Intent of On Input

    This Success Criterion covers changes in context due to changing the setting of a - control. Clicking on links or tabs in a tab control is activating the control, not + control. Clicking on links or buttons is activating a control, not changing the setting of that control.

    @@ -132,44 +141,32 @@

    Techniques for On Input

    Sufficient Techniques for On Input

    -
      +
    +
    @@ -210,7 +207,7 @@

    Additional Techniques (Advisory) for On Input

  • - Giving users advanced warning when opening a new window + Giving users advanced warning when opening a new window
  • @@ -226,7 +223,7 @@

    Failures for On Input

  • - Failure due to automatically submitting a form and presenting new content without + Failure due to automatically submitting a form and presenting new content without prior warning when the last field in the form is given a value @@ -234,7 +231,7 @@

    Failures for On Input

  • - Failure due to launching a new window without prior warning when the status of a radio + Failure due to launching a new window without prior warning when the status of a radio button, check box or select list is changed diff --git a/understanding/20/page-titled.html b/understanding/20/page-titled.html index 0e06f3ba2f..a6c1f16ed8 100644 --- a/understanding/20/page-titled.html +++ b/understanding/20/page-titled.html @@ -3,11 +3,20 @@ Understanding Page Titled - +

    Understanding Page Titled

    +
    +

    In brief

    +
    +
    Goal
    Each web page has a meaningful title.
    +
    What to do
    Provide a descriptive page title using appropriate technology.
    +
    Why it's important
    Page titles help users identify and distinguish different pages.
    +
    + +

    Intent of Page Titled

    @@ -27,6 +36,12 @@

    Intent of Page Titled

    it is not required to use the name of the document or web application; other things may also describe the purpose or the topic of the page.

    + +

    In cases such as Single Page Applications (SPAs), where various distinct pages/views are + all nominally served from the same URI and the content of the page is changed dynamically, + the title of the page should also be changed dynamically to reflect the content or topic of + the current view. +

    @@ -77,73 +92,28 @@

    Benefits of Page Titled

    Examples of Page Titled

    - -
      - -
    • - -

      - - An HTML Web page - -

      - -

      The descriptive title of an HTML Web page is marked up with the <title> element so - that it will be displayed in the title bar of the user agent. -

      - -
    • - -
    • - -

      - - A document collection. - -

      - -

      The title of - Understanding WCAG 2.1 is "Understanding WCAG 2.1." -

      - +
      +
      An HTML Web page
      +
      The descriptive title of an HTML Web page is marked up with the <title> element so + that it will be displayed in the title bar of the user agent.
      +
      A document collection
      +
      +

      The title of Understanding WCAG 2.2 is "Understanding WCAG 2.2".

        - -
      • The introduction page has the title "Introduction to Understanding WCAG 2.0."
      • - -
      • Major sections of the document are pages titled "Understanding Guideline X" and "Understanding - Success Criterion X." -
      • - +
      • The Introduction to Understanding WCAG page has the title "Introduction to Understanding WCAG".
      • +
      • Major sections of the document collection are pages titled "Understanding Guideline X" and "Understanding Success Criterion X."
      • Appendix A has the title "Glossary."
      • -
      • Appendix B has the title "Acknowledgements."
      • -
      • Appendix C has the title "References."
      • -
      - -
    • - -
    • - -

      - - A Web application. - -

      - -

      - A banking application lets a user inspect his bank accounts, view past statements, + +

      A Web application
      +
      A banking application lets users inspect their bank accounts, view past statements, and perform transactions. The Web application dynamically generates titles for each - Web page, e.g., "Bank XYZ, accounts for John Smith" "Bank XYZ, December 2005 statement - for Account 1234-5678". - - -

      - -
    • - -
    + Web page, e.g., "Bank XYZ, accounts for Alex Smith" "Bank XYZ, December 2005 statement + for Account 1234-5678". + +
    @@ -155,16 +125,16 @@

    Resources for Page Titled

  • - Writing Better Web Page Titles How to write titles for Web pages that will enhance search engine effectiveness. + Writing Better Web Page Titles. How to write titles for Web pages that will enhance search engine effectiveness.
  • - Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen - Readers + Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen + Readers (PDF) . Theofanos, M.F., and Redish, J. (2003). Interactions, Volume X, Issue 6, November-December 2003, pages 38-51, - http://dl.acm.org/citation.cfm?doid=947226.947227 + https://dl.acm.org/doi/10.1145/947226.947227
  • @@ -180,13 +150,13 @@

    Techniques for Page Titled

    Sufficient Techniques for Page Titled

    -
      +
    +
    @@ -222,7 +192,7 @@

    Additional Techniques (Advisory) for Page Titled

  • - Identifying a Web page's relationship to a larger collection of Web pages + Identifying a Web page's relationship to a larger collection of Web pages
  • @@ -238,7 +208,7 @@

    Failures for Page Titled

  • - Failure due to the title of a Web page not identifying the contents + Failure due to the title of a Web page not identifying the contents
  • diff --git a/understanding/20/parsing.html b/understanding/20/parsing.html index bab3a2af20..ae72ef4d58 100644 --- a/understanding/20/parsing.html +++ b/understanding/20/parsing.html @@ -3,23 +3,48 @@ Understanding Parsing - +

    Understanding Parsing

    +
    +

    In brief

    +
    +
    Goal
    Assistive technology can properly present page content.
    +
    What to do
    Create web pages according to specifications.
    +
    Why it's important
    People can browse web content more easily with their assistive technology.
    +
    + +

    Intent of Parsing

    - -

    The intent of this Success Criterion is to ensure that user agents, including assistive - technologies, can accurately interpret and parse content. If the content cannot be - parsed into a data structure, then different user agents may present it differently - or be completely unable to parse it. Some user agents use "repair techniques" to render - poorly coded content. - - +

    +

    This criterion has been removed from WCAG 2.2.

    + +

    The intent of this Success Criterion was to ensure that user-agents, including assistive technologies, can accurately interpret and parse content. Since WCAG 2.0 was published, the specifications (such as HTML) and browsers have improved their handling of parsing errors. It is also the case that assistive technology used to do their own parsing of markup, but now rely on the browser. For that reason this success criterion has been removed. Many issues that would have failed this criterion will fail Info and Relationships or Name, Role, Value. Other issues are excepted by the "except where the specification allow these features" part of the criterion.

    + +

    The following content is left for historical purposes to show the original intent.

    + +
    + +
    +

    Success Criterion 4.1.1 Parsing (Level A): In content implemented using markup languages, elements have complete start and end + tags, elements are nested according to their specifications, elements do not contain + duplicate attributes, and any IDs are unique, except where the specifications allow + these features. +

    +

    Start and end tags that are missing a critical character in their formation, such + as a closing angle bracket or a mismatched attribute value quotation mark are not + complete. +

    +
    +
    + +

    + The intent of this Success Criterion is to ensure that user agents, including assistive technologies, can accurately interpret and parse content. If the content cannot be parsed into a data structure, then different user agents may present it differently or be completely unable to parse it. Some user agents use "repair techniques" to render poorly coded content.

    Since repair techniques vary among user agents, authors cannot assume that content @@ -39,16 +64,16 @@

    Intent of Parsing

    The concept of "well formed" is close to what is required here. However, exact parsing requirements vary amongst markup languages, and most non XML-based languages do not explicitly define requirements for well formedness. Therefore, it was necessary to - be more explicit in the success criterion in order to be generally applicable to markup + be more explicit in the Success Criterion in order to be generally applicable to markup languages. Because the term "well formed" is only defined in XML, and (because end tags are sometimes optional) valid HTML does not require well formed code, the term - is not used in this success criterion. + is not used in this Success Criterion.

    -

    With the exception of one success criterion ( - 1.4.2: Resize text, which specifically mentions that the effect specified by the success criterion must - be achieved without relying on an assistive technology) authors can meet the success - criteria with content that assumes use of an assistive technology (or access features +

    With the exception of one Success Criterion ( + 1.4.4: Resize Text, which specifically mentions that the effect specified by the Success Criterion must + be achieved without relying on an assistive technology) authors can meet the Success + Criteria with content that assumes use of an assistive technology (or access features in use agents) by the user, where such assistive technologies (or access features in user agents) exist and are available to the user.

    @@ -93,23 +118,23 @@

    Techniques for Parsing

    Sufficient Techniques for Parsing

    -
      +
    +
    @@ -169,13 +188,13 @@

    Failures for Parsing

  • - Failure of 4.1.1 due to incorrect use of start and end tags or attribute markup + Failure of 4.1.1 due to incorrect use of start and end tags or attribute markup
  • - Failure of 4.1.1 due to duplicate values of type ID + Failure of 4.1.1 due to duplicate values of type ID
  • diff --git a/understanding/20/pause-stop-hide.html b/understanding/20/pause-stop-hide.html index 76fe7f1302..e513facd7c 100644 --- a/understanding/20/pause-stop-hide.html +++ b/understanding/20/pause-stop-hide.html @@ -3,11 +3,20 @@ Understanding Pause, Stop, Hide - +

    Understanding Pause, Stop, Hide

    +
    +

    In brief

    +
    +
    Goal
    Fewer users are distracted by content that updates or moves.
    +
    What to do
    Let users control content changes that occur in parallel with other content.
    +
    Why it's important
    Some people with cognitive disabilities and attention deficits cannot concentrate with continual movement.
    +
    + +

    Intent of Pause, Stop, Hide

    @@ -33,7 +42,7 @@

    Intent of Pause, Stop, Hide

  • there is no five second exception for auto-updating since it makes little sense to - auto-update for just three seconds and then stop + auto-update for a few seconds and then stop
  • @@ -54,7 +63,7 @@

    Intent of Pause, Stop, Hide

    point in the presentation where the user left off.

    -
      +
      • @@ -91,7 +100,7 @@

        Intent of Pause, Stop, Hide

      • -
    +

    For a mechanism to be considered "a mechanism for the user to pause," it must provide the user with a means to pause that does not tie up the user or the focus so that @@ -153,131 +162,39 @@

    Benefits of Pause, Stop, Hide

    Examples of Pause, Stop, Hide

    - -
      - -
    • - -

      - - An essential animation can be paused without affecting the activity - -

      - -

      A Web site helps users understand 'how things work' through animations that demonstrate - processes. Animations have "pause" and "restart" buttons. -

      - -
    • - -
    • - -

      - - A stock ticker - -

      - -

      - A stock ticker has "pause" and "restart" buttons. Pausing the ticker causes it to +

      +
      An essential animation can be paused without affecting the activity
      +
      A Web site helps users understand 'how things work' through animations that demonstrate + processes. Animations have "pause" and "restart" buttons.
      +
      A stock ticker
      +
      A stock ticker has "pause" and "restart" buttons. Pausing the ticker causes it to pause on the currently displayed stock. Restarting causes the ticker to resume from the stopped point but with a notice that the display is delayed. Since the intent of the stock ticker is usually to provide realtime information, there might also be - a button that would advance the ticker to the most recently traded stock. - - -

      - -
    • - -
    • - -

      - - A game is designed so that users take turns rather than competing in real-time - -

      - -

      One party can pause the game without invalidating the competitive aspect of it.

      - -
    • - -
    • - -

      - - A Web advertisement - -

      - -

      An advertisement blinks to get viewers attention but stops after 5 seconds

      - -
    • - -
    • - -

      - - A form prompt - -

      - -

      A form blinks an arrow near the submit button if a user finishes filling out the form - but does not activate the submit button. The blinking stops after 5 seconds. -

      - -
    • - -
    • - -

      - - An animation - -

      - -

      An animation runs in the upper portion of the page but has a "freeze animation" button - near the bottom of the animation. - -

      - -
    • - -
    • - -

      - - A "loading" animation - -

      - -

      A preloader animation is shown on a page which requires a certain percentage of a + a button that would advance the ticker to the most recently traded stock. +

      A game is designed so that users take turns rather than competing in real-time
      +
      One party can pause the game without invalidating the competitive aspect of it.
      +
      A Web advertisement
      +
      An advertisement blinks to get viewers attention but stops after 5 seconds
      +
      A form prompt
      +
      A form blinks an arrow near the submit button if a user finishes filling out the form + but does not activate the submit button. The blinking stops after 5 seconds.
      +
      An animation
      +
      An animation runs in the upper portion of the page but has a "freeze animation" button + near the bottom of the animation.
      +
      A "loading" animation
      +
      A preloader animation is shown on a page which requires a certain percentage of a large file to be downloaded before playback can begin. The animation is the only content on the page and instructs the user to please wait while the video loads. Because the moving content is not presented in parallel with other content, no mechanism to pause, stop or hide it needs to be provided, even though the animation may run for more than - 5 seconds for users with slower connections. -

      - -
    • - -
    • - -

      - - A full-page advertisement - -

      - -

      A site requires that all users view a 15 second advertisement before they can access + 5 seconds for users with slower connections. +

      A full-page advertisement
      +
      A site requires that all users view a 15 second advertisement before they can access free content available from their site. Because viewing the advertisement is a requirement for all users and because it is not presented in parallel with other content, no mechanism - to pause, stop or hide it needs to be provided. -

      - -
    • - -
    + to pause, stop or hide it needs to be provided. +
    @@ -295,91 +212,53 @@

    Techniques for Pause, Stop, Hide

    Sufficient Techniques for Pause, Stop, Hide

    -
      - -
    1. - - Allowing the content to be paused and restarted from where it was stopped - -
    2. - -
    3. - - - -
    4. - -
    5. - - - -
    6. - -
    7. - - Using script to scroll content, and providing a mechanism to pause it - -
    8. - -
    9. - - Using script to scroll Flash content, and providing a mechanism to pause it - -
    10. +
    +
    @@ -396,7 +275,7 @@

    Failures for Pause, Stop, Hide

  • - Failure due to including scrolling content where there is not a mechanism to pause + Failure due to including scrolling content where there is not a mechanism to pause and restart the content @@ -404,13 +283,13 @@

    Failures for Pause, Stop, Hide

  • - Failure due to using the blink element + Failure due to using the blink element
  • - Failure due to using text-decoration:blink without a mechanism to stop it in less + Failure due to using text-decoration:blink without a mechanism to stop it in less than five seconds @@ -418,7 +297,7 @@

    Failures for Pause, Stop, Hide

  • - Failure due to a script that causes a blink effect without a mechanism to stop the + Failure due to a script that causes a blink effect without a mechanism to stop the blinking at 3 seconds or less @@ -426,7 +305,7 @@

    Failures for Pause, Stop, Hide

  • - Failure due to an object or applet, such as Java or Flash, that has blinking content + Failure due to an object or applet that has blinking content without a mechanism to pause the content that blinks for more than five seconds diff --git a/understanding/20/predictable.html b/understanding/20/predictable.html index fe9a7999d5..5f4ca83e02 100644 --- a/understanding/20/predictable.html +++ b/understanding/20/predictable.html @@ -3,7 +3,7 @@ Understanding Predictable - +

    Understanding Predictable

    diff --git a/understanding/20/pronunciation.html b/understanding/20/pronunciation.html index 7835d25af7..7f671e03ac 100644 --- a/understanding/20/pronunciation.html +++ b/understanding/20/pronunciation.html @@ -3,11 +3,20 @@ Understanding Pronunciation - +

    Understanding Pronunciation

    +
    +

    In brief

    +
    +
    Goal
    Users can identify the pronunciation of ambiguous words.
    +
    What to do
    Indicate how to pronounce a word, where its meaning is otherwise unclear.
    +
    Why it's important
    Some people, including those with cognitive disabilities, may not understand the meaning of content.
    +
    + +

    Intent of Pronunciation

    @@ -63,98 +72,34 @@

    Benefits of Pronunciation

    Examples of Pronunciation

    - -
      - -
    • - -

      - - Giving the reading of a person's name. - -

      - -

      Web content in Japanese provides kana (Japanese phonetic syllabary characters) written +

      +
      Giving the reading of a person's name
      +
      Web content in Japanese provides kana (Japanese phonetic syllabary characters) written next to Han characters (Kanji) show the pronunciation of a person's name. The kana is provided to users in parentheses right after the word. Giving the reading of the words written in Han characters (Kanji) allows both sighted users and screen readers to read/pronounce the words correctly. Note that screen readers will speak the word twice: the Han characters (Kanji) that can be pronounced in a wrong way are read first - and then kana is spoken in order to provide the correct reading. - -

      - -
    • - -
    • - -

      - - Showing the reading of the words by ruby element. - -

      - -

      Web content using XHTML 1.1 provides kana (phonetic syllabary characters) written + and then kana is spoken in order to provide the correct reading. +

      Showing the reading of the words by ruby element
      +
      Web content using HTML provides kana (phonetic syllabary characters) written above the characters to show the reading (pronunciation) of the words by using the - ruby element. - -

      - -
    • - -
    • - -

      - - Providing sound files of the pronunciation. - -

      - -

      A document includes some words whose meaning cannot be determined without knowing + ruby element. +

      Providing sound files of the pronunciation
      +
      A document includes some words whose meaning cannot be determined without knowing the correct pronunciation. Each word is linked to a sound file that gives the correct - pronunciation. Users can select these links to find out how to pronounce the words. - -

      - -
    • - -
    • - -

      - - Including pronunciation information in the glossary. - -

      - -

      - A Web page includes a glossary section. Some items in the glossary include pronunciation + pronunciation. Users can select these links to find out how to pronounce the words. +

      Including pronunciation information in the glossary
      +
      A Web page includes a glossary section. Some items in the glossary include pronunciation information as well as definitions. Words in the content whose meaning cannot be determined - without knowing their pronunciation are linked to the appropriate entries in the glossary. - -

      - -
    • - -
    • - -

      - - Text that includes pronunciation information for characters shared by several languages - but pronounced differently in each language - - -

      - -

      A Japanese university Web site includes several short phrases quoted from scholarly + without knowing their pronunciation are linked to the appropriate entries in the glossary. +

      Text that includes pronunciation information for characters shared by several languages + but pronounced differently in each language
      +
      A Japanese university Web site includes several short phrases quoted from scholarly texts in Chinese and Korean. The quotations are written using the same script as the Japanese text. Pronunciation information is provided to show the correct reading of - the Chinese and Korean characters. - -

      - -
    • - -
    + the Chinese and Korean characters. +
    @@ -180,40 +125,40 @@

    Techniques for Pronunciation

    Sufficient Techniques for Pronunciation

    -
      +
    +
    diff --git a/understanding/20/re-authenticating.html b/understanding/20/re-authenticating.html index d9dd8e0814..f8ac890d7a 100644 --- a/understanding/20/re-authenticating.html +++ b/understanding/20/re-authenticating.html @@ -3,11 +3,20 @@ Understanding Re-authenticating - +

    Understanding Re-authenticating

    +
    +

    In brief

    +
    +
    Goal
    Users do not lose information or context due to reauthentication.
    +
    What to do
    Preserve users' prior activity and data through reauthentication.
    +
    Why it's important
    Some people may require additional time to complete an activity.
    +
    + +

    Intent of Re-authenticating

    @@ -59,67 +68,30 @@

    Benefits of Re-authenticating

    Examples of Re-authenticating

    - -
      - -
    • - -

      - - A shopping site checkout - -

      - -

      A user with extremely limited use of the hands is logged into a shopping site. It +

      +
      A shopping site checkout
      +
      A user with extremely limited use of the hands is logged into a shopping site. It takes so long to enter credit card information into the application that a time limit occurs while the user is performing the checkout process. When the user returns to the checkout process and submits the form, the site returns a login screen to re-authenticate. After the user logs in, the check out process is restored with the same information and at the same stage. The user did not lose any data because the server had temporarily accepted and stored the submission even though the session had timed out and restored - the user to the same state after re-authentication was completed. -

      - -
    • - -
    • - -

      - - Authentication in an email program - -

      - -

      An email program has an authentication time-out after 30 minutes. The program prompts + the user to the same state after re-authentication was completed. +

      Authentication in an email program
      +
      An email program has an authentication time-out after 30 minutes. The program prompts the user several minutes before the time-out occurs and provides a link to open a new window in order to re-authenticate. The original window with the in-progress email - remains intact and, after re-authentication, the user may send that data. -

      - -
    • - -
    • - -

      - - A questionnaire with a time limit - - - -

      - -

      A long questionnaire provided within a single Web page has information at the beginning + remains intact and, after re-authentication, the user may send that data. +

      A questionnaire with a time limit
      +
      A long questionnaire provided within a single Web page has information at the beginning that indicates that the session will time out after 15 minutes. The user is also informed that the questionnaire can be saved at any point and completed at a later time. Within the Web page there are several buttons provided to save the partially completed form. In addition, with JavaScript in the list of accessibility-supported content technologies that are relied upon, the user can elect to be alerted via a pop-up if the session - is close to timing out. -

      - -
    • - -
    + is close to timing out. +
    @@ -137,7 +109,7 @@

    Techniques for Re-authenticating

    Sufficient Techniques for Re-authenticating

    -
      +
    +
    @@ -190,7 +162,7 @@

    Failures for Re-authenticating

  • - Failure due to having a session time limit without a mechanism for saving user's input + Failure due to having a session time limit without a mechanism for saving user's input and re-establishing that information upon re-authentication diff --git a/understanding/20/readable.html b/understanding/20/readable.html index 14638dea8e..9bc2656e11 100644 --- a/understanding/20/readable.html +++ b/understanding/20/readable.html @@ -3,7 +3,7 @@ Understanding Readable - +

    Understanding Readable

    diff --git a/understanding/20/reading-level.html b/understanding/20/reading-level.html index 1855ccdd87..26c90be58c 100644 --- a/understanding/20/reading-level.html +++ b/understanding/20/reading-level.html @@ -3,11 +3,20 @@ Understanding Reading Level - +

    Understanding Reading Level

    +
    +

    In brief

    +
    +
    Goal
    Users can get a simplified version of complex information.
    +
    What to do
    When text information becomes complex, create a more easily understood version.
    +
    Why it's important
    More people, especially those with cognitive disabilities, can understand the meaning of content.
    +
    + +

    Intent of Reading Level

    @@ -106,31 +115,22 @@

    Intent of Reading Level

    Readability formulas are available for at least some languages when running the spell checkers in popular software if you specify in the options of this engine that you want to have the statistics when it has finished checking your documents. - -

    - Levels of education - - - Primary education - Lower secondary education - Upper secondary education - Advanced education +

    Levels of education

    +
    +
    Primary education
    +
    First 6 years of school
    +
    Lower secondary education
    +
    7-9 years of school
    +
    Upper secondary education
    +
    10-12 years of school
    +
    Advanced education
    +
    More than 12 years of school
    +
    - First 6 years of school - 7-9 years of school - 10-12 years of school - More than 12 years of school - - - - -

    Adapted from International Standard Classification of Education - [[UNESCO]] - -

    +

    Adapted from International Standard Classification of Education (UNESCO).

    @@ -169,110 +169,49 @@

    Benefits of Reading Level

    Examples of Reading Level

    - -
      - -
    1. - -

      - - A scientific journal including readable summaries of complex research articles - -

      - -

      A scientific journal includes articles written in highly technical language aimed +

      +
      A scientific journal including readable summaries of complex research articles
      +
      A scientific journal includes articles written in highly technical language aimed at specialists in the field. The journal's Table of Contents page includes a plain-language summary of each article. The summaries are intended for a general audience with eight years of school. The metadata for the journal uses the Dublin Core specification to identify the education level of the articles' intended audience as "advanced," and the education level of the intended audience for the summaries as "lower secondary - education." -

      - -
    2. - -
    3. - -

      - - Medical information for members of the public. - -

      - -

      A medical school operates a Web site that explains recent medical and scientific discoveries. + education." +

      Medical information for members of the public
      +
      A medical school operates a Web site that explains recent medical and scientific discoveries. The articles on the site are written for people without medical training. Each article uses the Dublin Core metadata specification to identify the education level of the intended audience as "lower secondary education" and includes the Flesch Reading Ease score for the article. A link on each page displays the education level and other metadata. No supplemental content is required because people who read at the lower - secondary education level can read the articles. -

      - -
    4. - -
    5. - -

      - - An e-learning application. - -

      - -

      An on-line course about Spanish cultural history includes a unit on Moorish architecture. + secondary education level can read the articles. +

      An e-learning application
      +
      An on-line course about Spanish cultural history includes a unit on Moorish architecture. The unit includes text written for students with different reading abilities. Photographs and drawings of buildings illustrate architectural concepts and styles. Graphic organizers are used to illustrate complex relationships, and an audio version using synthetic speech is available. The metadata for each version describes the academic level of the content and includes a readability score based on formulas developed for Spanish-language text. The learning application uses this metadata and metadata about the students - to provide versions of instructional content that match the needs of individual students. -

      - -
    6. - -
    7. - -

      - - Science information that requires a reading ability at the lower secondary education - level. - - -

      - + to provide versions of instructional content that match the needs of individual students. +
      Science information that requires a reading ability at the lower secondary education level
      +

      The text below (116 words total) requires a reading ability of grade 4.2 in the United States according to the Flesch-Kincaid formula. In the US, grade 4.2 is at the primary - education level. -

      - + education level.

      Science is about testing — and about looking closely. Some scientists use microscopes - to take a close look. We're going to use a simple piece of paper. -

      - + to take a close look. We're going to use a simple piece of paper.

      Here's what you do: Print this page and cut out the square to make a "window" one - inch square. (It's easiest to fold the page in half before you cut.) -

      - + inch square. (It's easiest to fold the page in half before you cut.)

      Choose something interesting: a tree trunk, a leaf, flower, the soil surface, or a - slice of soil from a shovel. -

      - -

      Put your window over the thing and look at it closely. Take your time — this is not - a race. -

      - + slice of soil from a shovel.

      +

      Put your window over the thing and look at it closely. Take your time — this is not a race.

      To help you see more details, draw a picture of what's inside your square.

      -

      Now let's think about what you've found.

      - -

      - (Source: Howard Hughes Medical Institute "CoolScience for Kids" Project) - -

      - -
    8. - -
    +

    (Source: Howard Hughes Medical Institute "CoolScience for Kids" Project)

    + +
    @@ -282,77 +221,56 @@

    Resources for Reading Level

    diff --git a/understanding/20/resize-text.html b/understanding/20/resize-text.html index eb05e91aff..2fc1cadaf2 100644 --- a/understanding/20/resize-text.html +++ b/understanding/20/resize-text.html @@ -2,44 +2,53 @@ - Understanding Resize text - + Understanding Resize Text + -

    Understanding Resize text

    +

    Understanding Resize Text

    +
    +

    In brief

    +
    +
    Goal
    Text can be enlarged.
    +
    What to do
    Ensure text can be doubled in size.
    +
    Why it's important
    Some people can only read text when it is bigger.
    +
    + +
    -

    Intent of Resize text

    - - +

    Intent of Resize Text

    +

    The intent of this Success Criterion is to ensure that visually rendered text, including - text-based controls (text characters that have been displayed so that they can be - seen [vs. text characters that are still in data form such as ASCII]) can be scaled - successfully so that it can be read directly by people with mild visual disabilities, - without requiring the use of assistive technology such as a screen magnifier. Users - may benefit from scaling all content on the Web page, but text is most critical. + controls and labels using text, can be made larger so that it can be read more easily by + people with milder visual impairments, without requiring the use of assistive technology + (such as a screen magnifier). Users may benefit from scaling all content on the Web page, + but text is most critical.

    The scaling of content is primarily a user agent responsibility. User agents that satisfy - UAAG 1.0 Checkpoint 4.1 allow users to configure text scale. The author's responsibility is to create Web - content that does not prevent the user agent from scaling the content effectively. + UAAG 1.0 Checkpoint 4.1 + allow users to configure text scale through a number of mechanisms - including zoom (of the entire page's content), + magnification, text-only resizing, and allowing the user to configure a size for rendered text. + The author's responsibility is to create Web content that does not prevent the user agent from scaling the content effectively. Authors may satisfy this Success Criterion by verifying that content does not interfere with user agent support for resizing text, including text-based controls, or by providing direct support for resizing text or changing the layout. An example of direct support might be via server-side script that can be used to assign different style sheets.

    + +

    Content satisfies the Success Criterion if it can be scaled up to 200% using at least one text scaling + mechanism supported by user agents.

    -

    The author cannot rely on the user agent to satisfy this Success Criterion for HTML - content if users do not have access to a user agent with zoom support. For example, - if they work in an environment that requires them to use IE 6. -

    -

    If the author is using a technology whose user agents do not provide zoom support, - the author is responsible to provide this type of functionality directly or to provide - content that works with the type of functionality provided by the user agent. If the - user agent doesn't provide zoom functionality but does let the the user change the +

    If the author is using a technology whose user agents do not provide support for specific text scaling mechanisms, + the author is responsible for providing this type of functionality directly, or providing + content that works with the type of functionality provided by the user agent. For instance, if the + user agent doesn't provide full-page zoom functionality, but does let the the user change the + text size, the author is responsible for ensuring that the content remains usable when the text is resized.

    @@ -58,7 +67,7 @@

    Intent of Resize text

    can be accessed, is provided to the user in some way besides the fact that it is truncated.

    -

    Content satisfies the Success Criterion if it can be scaled up to 200%, that is, up +

    Content satisfies the Success Criterion if it can be scaled up to 200% - that is, up to twice the width and height. Authors may support scaling beyond that limit, however, as scaling becomes more extreme, adaptive layouts may introduce usability problems. For example, words may be too wide to fit into the horizontal space available to them, @@ -73,7 +82,7 @@

    Intent of Resize text

    a minimum magnification of 200%. Above 200%, zoom (which resizes text, images, and layout regions and creates a larger canvas that may require both horizontal and vertical scrolling) may be more effective than text resizing. Assistive technology dedicated - to zoom support would usually be used in such a situation and may provide better accessibility + to zoom support would usually be used in such a situation, and may provide better accessibility than attempts by the author to support the user directly.

    @@ -83,275 +92,162 @@

    Intent of Resize text

    we suggest using text wherever possible. It is also harder to change foreground and background contrast and color combinations for images of text, which are necessary for some users. -

    + +
    +

    As with most other Success Criteria, this criterion applies to each variation of the page that is automatically presented for various screen sizes (e.g. media query variations in a responsive site). In an implementation where text does not consistently increase its size as people zoom in (such as when it is transformed based on a media query to adapt to small-screen usage), it must still be possible to get to 200% enlargement in order to satisfy the criterion.

    +

    For example, if at the default browser setting of 100% zoom, text is set at 20px when the window is 1280 CSS pixels wide, at 200% zoom it will visually appear at twice the size. After zooming by 400% the page reflows to fit within the 320 CSS pixel viewport, the author may decide to set the page's text size to 10px. The text is now half the original size in CSS pixels, but as it has been enlarged to 400%, it is still displayed at twice the size compared to the default browser setting at 100% zoom. It is not required to achieve 200% text enlargement while remaining inside a specific breakpoint (as zooming may result in the variation for a new breakpoint becoming active), but it should still be possible to get 200% text enlargement in some way compared to the default 100% zoom.

    +

    See also 1.4.3: Visual Presentation.

    -
    -

    Benefits of Resize text

    - +

    Benefits of Resize Text

      -
    • This Success Criterion helps people with low vision by letting them increase text size in content so that they can read it. -
    • -
    -
    -

    Examples of Resize text

    - - +

    Examples of Resize Text

    +
      -
    • A user with vision impairments increases the text size on a Web page in a browser from 1 em to 1.2 ems. While the user could not read the text at the smaller size, - she can read the larger text. All the information on the page is still displayed when + they can read the larger text. All the information on the page is still displayed when the larger font is used for the text. -
    • -
    • A Web page contains a control for changing the scale of the page. Selecting different settings changes the layout of the page to use the best design for that scale. -
    • -
    • - A user uses a zoom function in his user agent to change the scale of the content. - All the content scales uniformly, and the user agent provides scroll bars, if necessary. - + A user changes the scale of the content with the browser's full-page zoom function. + All the content scales uniformly, and the browser provides scroll bars, if necessary.
    • -
    -
    -

    Resources for Resize text

    - - +

    Resources for Resize Text

    + -
    -

    Techniques for Resize text

    - - +

    Techniques for Resize Text

    +

    Sufficient Techniques for Resize text

    - -
      - -
    1. - - Using a technology that has commonly-available user agents that support zoom - -
    2. -
    3. - - - + Using a technology that has commonly-available user agents that support zoom
    4. -
    5. - - - -
    6. - -
    7. -

      Ensuring that text containers resize when the text resizes AND using measurements that are relative to other measurements in the content by using one or more of the following techniques:

      - -
    8. -
    9. - - Providing controls on the Web page that incrementally change the size of the text - + Providing controls on the Web page that incrementally change the size of the text -
    10. -
    11. - - Ensuring that there is no loss of content or functionality when the text resizes and + Ensuring that there is no loss of content or functionality when the text resizes and text containers do not resize -
    12. - -
    - +
    -

    Additional Techniques (Advisory) for Resize text

    - - +

    Additional Techniques (Advisory) for Resize Text

    -
    -

    Failures for Resize text

    - - +

    Failures for Resize Text

    -
    diff --git a/understanding/20/section-headings.html b/understanding/20/section-headings.html index ba92e59ae0..ba8b3d5b0b 100644 --- a/understanding/20/section-headings.html +++ b/understanding/20/section-headings.html @@ -3,11 +3,20 @@ Understanding Section Headings - +

    Understanding Section Headings

    +
    +

    In brief

    +
    +
    Goal
    Users understand how content is organized in sections.
    +
    What to do
    Where content is organized in sections, provide section headings.
    +
    Why it's important
    People can orient themselves, especially those with cognitive or visual disabilities.
    +
    + +

    Intent of Section Headings

    @@ -15,9 +24,8 @@

    Intent of Section Headings

    The intent of this Success Criterion is to provide headings for sections of a Web page, when the page is organized into sections. For instance, long documents are often - divided into a variety of chapters, chapters have subtopics and subtopics are divided - into various sections, sections into paragraphs, etc. When such sections exist, they - need to have headings that introduce them. This clearly indicates the organization + divided into a variety of chapters, chapters have subtopics, etc. When such sections exist, + they need to have headings that introduce them. This clearly indicates the organization of the content, facilitates navigation within the content, and provides mental "handles" that aid in comprehension of the content. Other page elements may complement headings to improve presentation (e.g., horizontal rules and boxes), but visual presentation @@ -109,21 +117,21 @@

    Techniques for Section Headings

    Sufficient Techniques for Section Headings

    -
      +
    +
    diff --git a/understanding/20/seizures.html b/understanding/20/seizures.html index 047f48bd6d..886fd18bf8 100644 --- a/understanding/20/seizures.html +++ b/understanding/20/seizures.html @@ -3,7 +3,7 @@ Understanding Seizures - +

    Understanding Seizures

    diff --git a/understanding/20/sensory-characteristics.html b/understanding/20/sensory-characteristics.html index c4ca649181..c987e975a4 100644 --- a/understanding/20/sensory-characteristics.html +++ b/understanding/20/sensory-characteristics.html @@ -3,16 +3,24 @@ Understanding Sensory Characteristics - +

    Understanding Sensory Characteristics

    +
    +

    In brief

    +
    +
    Goal
    Instructions are understandable by more people.
    +
    What to do
    Describe controls by name, not just by appearance or location.
    +
    Why it's important
    People who are blind or have low vision need non-visual instructions.
    +
    + +

    Intent of Sensory Characteristics

    -

    The intent of this Success Criterion is to ensure that all users can access instructions for using the content, even when they cannot perceive shape or size or use information about spatial location or orientation. @@ -22,15 +30,13 @@

    Intent of Sensory Characteristics

    Some users with disabilities are not able to perceive shape or position due to the nature of the assistive technologies they use. This Success Criterion requires that additional information be provided to clarify - anything that is dependent on this kind of information. - + instructions that are dependent on this kind of information.

    Providing information using shape and/or location, however, is an effective method for many users including those with cognitive limitations. This provision should not discourage those types of cues as long as the information is also provided in other ways. -

    In some languages, it is commonly understood that "above" refers to the content previous @@ -38,7 +44,6 @@

    Intent of Sensory Characteristics

    such languages, if the content being referenced is in the appropriate place in the reading order and the references are unambiguous, statements such as "choose one of the links below" or "all of the above" would conform to this Success Criterion. -

    WCAG was designed to apply only to controls that were displayed on a web page. The @@ -48,8 +53,7 @@

    Intent of Sensory Characteristics

    (e.g. the arrow shaped key, the round key on the right side). This success criterion is not intended to prevent the use of tactile cues in instructions.

    - - +

    Benefits of Sensory Characteristics

    @@ -58,9 +62,10 @@

    Benefits of Sensory Characteristics

    • People who are blind and people who have low vision may not be able to understand - information if it is conveyed by shape and/or location. Providing additional information - other than shape and/or location will allow them to understand the information conveyed - by shape and/or alone. + instructions if they rely only on a description of the shape and/or location of content. + Providing additional information in any instructions other than shape and/or location + will allow users to understand the instructions even if they cannot perceive shape + and/or location.
    @@ -70,54 +75,24 @@

    Benefits of Sensory Characteristics

    Examples of Sensory Characteristics

    - -
      - -
    • - -

      - - - Example 1: A schedule of competitive events uses color and shape to distinguish the - time of each event - - - -

      - -

      - A table presents a list of times across the top row and a list of events in the first - vertical column. The cell corresponding to the time of a particular event has a specific - background color and diamond shaped glyph so it can be identified by color and shape. - - -

      - -
    • - -
    • - -

      - - - Example 2: An on-line multi-page survey - - - -

      - -

      - An on-line multi-page survey uses a link implemented as a green arrow icon placed +

      +
      Example 1: Instructions for interpreting a schedule of competitive events references + colored icons in different shapes to indicate the venue for each event
      +
      A table presents a list of times across the top row and a list of events in the first + vertical column and instructions are provided under the table: "Events marked with a + blue diamond are played on field A and events marked with a green circle are played + on field B." The instructions rely on color and shape only and result in a failure of + this criterion.
      +
      Example 2: An online multi-page survey
      +
      An online multi-page survey uses a link implemented as a green arrow icon placed in the lower right hand corner of the content to move from one survey page to the next. The arrow is clearly labeled with "Next" and the instructions state, "To move to the next section of the survey, select the green arrow icon labeled 'Next' in the - lower right corner below the last survey question." This example uses both positioning, - color and labeling to help identify the icon. -

      - -
    • - -
    + lower right corner below the last survey question." + The instruction uses positioning and color to help identify the icon; + the instruction does not rely on these sensory characteristics since it also refers to + the label, so it passes this criterion. +
    @@ -135,17 +110,17 @@

    Techniques for Sensory Characteristics

    Sufficient Techniques for Sensory Characteristics

    -
      +
    +
    @@ -162,14 +137,14 @@

    Failures for Sensory Characteristics

  • - Failure due to identifying content only by its shape or location + Failure due to identifying content only by its shape or location
  • - +
  • - - Failure due to using a non-text mark alone to convey information - + + Failure due to using a non-text mark alone to convey information +
  • diff --git a/understanding/20/sign-language-prerecorded.html b/understanding/20/sign-language-prerecorded.html index ce2b77cce9..ca1d30b6d3 100644 --- a/understanding/20/sign-language-prerecorded.html +++ b/understanding/20/sign-language-prerecorded.html @@ -3,11 +3,20 @@ Understanding Sign Language (Prerecorded) - +

    Understanding Sign Language (Prerecorded)

    +
    +

    In brief

    +
    +
    Goal
    Videos can be accompanied by sign language.
    +
    What to do
    Provide sign language interpretation for audio content in existing videos.
    +
    Why it's important
    People who are deaf or hard of hearing have more ways to understand multimedia content.
    +
    + +

    Intent of Sign Language (Prerecorded)

    @@ -51,25 +60,18 @@

    Examples of Sign Language (Prerecorded)

  • - Example 1. A corporation is making an important announcement to all of its employees. The meeting - will be held in the main headquarters and streamed to the Web. A sign language interpreter - is provided at the meeting location. The live video includes a full view of the sign - language interpreter as well as the person presenting. -
  • - -
  • - - Example 2. The same announcement described in example 1 is also Webcast to remote employees. - Since there is only one display available for this, the sign language interpreter - is shown in the corner of the display. + Example 1. A corporation is making an important announcement to all of its employees. The announcement + will be held in the main headquarters and later streamed to the Web. A sign language interpreter + is provided at the announcement location for the employees that are present in the meeting room. For the Web version of + the announcement, the sign language interpreter is shown/superimposed in the corner of the display.
  • - Example 3. A university is providing an on-line version of a particular lecture by creating + Example 2. A university is providing an online version of a particular lecture by creating a synchronized media presentation of the professor delivering the lecture. The presentation includes video of the professor speaking and demonstrating a science experiment. A - sign language interpretation of the lecture is created and presented on the Web with + sign language interpretation of the lecture is created after the lecture and presented on the Web with the synchronized media version.
  • @@ -136,11 +138,11 @@

    Techniques for Sign Language (Prerecorded)

    Sufficient Techniques for Sign Language (Prerecorded)

    -
      +
    +
    diff --git a/understanding/20/text-alternatives.html b/understanding/20/text-alternatives.html index 5f94408fbd..3e1390c4dc 100644 --- a/understanding/20/text-alternatives.html +++ b/understanding/20/text-alternatives.html @@ -3,7 +3,7 @@ Understanding Text Alternatives - +

    Understanding Text Alternatives

    diff --git a/understanding/20/three-flashes-or-below-threshold.html b/understanding/20/three-flashes-or-below-threshold.html index 20e30c5642..9fa345e15f 100644 --- a/understanding/20/three-flashes-or-below-threshold.html +++ b/understanding/20/three-flashes-or-below-threshold.html @@ -3,11 +3,20 @@ Understanding Three Flashes or Below Threshold - +

    Understanding Three Flashes or Below Threshold

    +
    +

    In brief

    +
    +
    Goal
    Content does not trigger seizures.
    +
    What to do
    Avoid content that flashes, or keep it under thresholds.
    +
    Why it's important
    Flashing content can cause migraines, dizziness, nausea, and seizures.
    +
    + +

    Intent of Three Flashes or Below Threshold

    @@ -20,8 +29,8 @@

    Intent of Three Flashes or Below Threshold

    Individuals who have photosensitive seizure disorders can have a seizure triggered by content that flashes at certain frequencies for more than a few flashes. People are even more sensitive to red flashing than to other colors, so a special test is - provided for saturated red flashing. These guidelines are based on guidelines for - the broadcasting industry as adapted for computer screens, where content is viewed + provided for saturated red flashing. These guidelines were originally based on guidelines for + the broadcasting industry as adapted for desktop monitors, where content is viewed from a closer distance (using a larger angle of vision).

    @@ -38,12 +47,21 @@

    Intent of Three Flashes or Below Threshold

    did not allow any flashing (even of a single pixel) within a broad frequency range (3 to 50 Hz). This Success Criterion is based on existing specifications in use in the UK and by others for television broadcast and has been adapted for computer display - viewing. The 1024 x 768 screen is used as the reference screen resolution for the + viewing. In WCAG 2.0, a 1024 x 768 screen was used as the reference screen resolution for the evaluation. The 341 x 256 pixel block represents a 10 degree viewport at a typical viewing distance. (The 10 degree field is taken from the original specifications and represents the central vision portion of the eye, where people are most susceptible to photo stimuli.)

    +

    With the proliferation of devices of varying screen sizes (from small hand-helds to large living room displays), as well as the adoption of CSS pixels as a density-independent unit of measurement, the prior assessment criteria may seem outdated. However, an image of a consistent size uses up relatively the same percentage of a user's visual field on any device. On a large screen, the image takes up less size, but the large screen takes up a larger part of the visual field. On a mobile screen, the image may take up most or all of the screen; however, the mobile screen itself takes up a smaller portion of the user's visual field. So the same dimension of the flashing content, represented in CSS pixels can still provide a consistent means of assessment. Substituting CSS pixels for the original pixel block means that the combined area of flashing becomes 341 x 256 CSS pixels, or a flashing area of 87,296 CSS pixels.

    + +

    Content should be analyzed at the largest scale at which a user may view the content, and at the standard zoom level of the user agent. For example, with a video that may play in an area of a web page and also at full screen, the video should be analyzed for risks at full screen.

    + +

    Where video content is provided in color spaces other than sRGB, the version provided with the highest dynamic range should be tested. In such cases the industry standard definition of a general flash is a change in luminance of 20 cd/m2 or more where the darker image is below 160 cd/m2. (ITU-R BT.1702.) This is applicable for standard dynamic range (SDR) and high dynamic range (HDR) content. For HDR content when the darker state is 160 cd/m2 or more, a general flash is one where the Michelson contrast is 1/17 or greater — where the Michelson contrast is calculated as (LHigh - LLow) / (LHigh + LLow), and where LHigh and LLow are the luminance of the high and low luminance states, respectively.

    + +

    For short clips that might be looped (such as GIF animations), the content should be analyzed while looping.

    + +

    The specification cannot account for the actual viewing distance that a person chooses. Users that are closer to their screens than the idealized viewing distance will be affected by flashing areas that normatively pass. The same problem applies to users who rely on zoom or screen magnification. Conversely, users who are further away from the screen than the idealized distance should be able to tolerate flashing areas that are larger than the threshold.

    The combined area of flashes occurring concurrently and contiguously means the total area that is actually flashing at the same time. It is calculated by adding up the @@ -73,6 +91,26 @@

    Intent of Three Flashes or Below Threshold

    + +
    +

    The new (in WCAG 2.2) working definition in the field for "pair of opposing transitions involving a saturated red" is a pair of opposing transitions where, one transition is either to or from a state with a value R/(R + G + B) that is greater than or equal to 0.8, and the difference between states is more than 0.2 (unitless) in the CIE 1976 UCS chromaticity diagram. [ISO 9241-391]

    +

    The chromaticity difference is calculated as:

    +
      +
    • SQRT( (u'1 - u'2)^2 + (v'1 - v'2)^2 )
    • +
    +

    where u'1 and v'1 are chromaticity coordinates of State 1 and u'2 and v'2 are chromaticity coordinates of State 2. The 1976 UCS chromaticity coordinates of u' and v' are calculated as:

    +
      +
    • u' = 4 * X / (X + 15 * Y + 3 * Z)
    • +
    • v' = 9 * Y / (X + 15 * Y + 3 * Z)
    • +
    +

    where X, Y, and Z are the tristimulus values of a color in the CIE XYZ colorspace, which can be calculated as:

    +
      +
    • X = 0.4124564 * R + 0.3575761 * G + 0.1804375 * B
    • +
    • Y = 0.2126729 * R + 0.7151522 * G + 0.0721750 * B
    • +
    • Z = 0.0193339 * R + 0.1191920 * G + 0.9503041 * B
    • +
    +

    where R, G, & B are values that range from 0-1 as specified in “relative luminance” definition.

    +
    @@ -123,19 +161,19 @@

    Resources for Three Flashes or Below Threshold

  • - Harding FPA Web Site + 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
  • @@ -147,16 +185,10 @@

    Resources for Three Flashes or Below Threshold

  • - Epilepsy Foundation + Epilepsy Foundation - Photosensitivity and Seizures
  • - -
  • - - ITC Guidance Note for Licensees on Flashing Images and Regular Patterns in Television - -
  • - +
    @@ -169,11 +201,11 @@

    Techniques for Three Flashes or Below Threshold

    Sufficient Techniques for Three Flashes or Below Threshold

    -
      +
    + diff --git a/understanding/20/three-flashes.html b/understanding/20/three-flashes.html index 7fb27e3c51..b81365fe93 100644 --- a/understanding/20/three-flashes.html +++ b/understanding/20/three-flashes.html @@ -3,12 +3,22 @@ Understanding Three Flashes - +

    Understanding Three Flashes

    +
    +

    In brief

    +
    +
    Goal
    Content does not trigger seizures.
    +
    What to do
    Do not flash content more than 3 times a second.
    +
    Why it's important
    Flashing content can cause migraines, dizziness, nausea, and seizures.
    +
    + +
    +

    Intent of Three Flashes

    @@ -89,19 +99,19 @@

    Resources for Three Flashes

  • - Harding FPA Web Site + 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
  • @@ -113,13 +123,7 @@

    Resources for Three Flashes

  • - Epilepsy Foundation - -
  • - -
  • - - ITC Guidance Note for Licensees on Flashing Images and Regular Patterns in Television + Epilepsy Foundation - Photosensitivity and Seizures
  • @@ -135,17 +139,17 @@

    Techniques for Three Flashes

    Sufficient Techniques for Three Flashes

    -
      +
    +
    diff --git a/understanding/20/time-based-media.html b/understanding/20/time-based-media.html index a63e06debc..eb6642d50c 100644 --- a/understanding/20/time-based-media.html +++ b/understanding/20/time-based-media.html @@ -3,7 +3,7 @@ Understanding Time-Based Media - +

    Understanding Time-Based Media

    diff --git a/understanding/20/timing-adjustable.html b/understanding/20/timing-adjustable.html index 978d6f9043..088983cb0a 100644 --- a/understanding/20/timing-adjustable.html +++ b/understanding/20/timing-adjustable.html @@ -3,11 +3,20 @@ Understanding Timing Adjustable - +

    Understanding Timing Adjustable

    +
    +

    In brief

    +
    +
    Goal
    Users have adequate time to complete tasks.
    +
    What to do
    Let users turn off, adjust, or extend time limits.
    +
    Why it's important
    People with disabilities may need more time to complete activities.
    +
    + +

    Intent of Timing Adjustable

    @@ -34,16 +43,14 @@

    Intent of Timing Adjustable

    a user to react to a request for input.

    -

    It also includes content that is advancing or updating at a rate beyond the user's - ability to read and/or understand it. In other words, animated, moving or scrolling - content introduces a time limit on a users ability to read content. -

    - -

    In some cases, however, it is not possible to change the time limit (for example, - for an auction or other real-time event) and exceptions are therefore provided for - those cases. -

    +

    It also includes content that is advancing or updating at a rate beyond the user's ability to read and/or understand it. In other words, animated, moving or scrolling content introduces a time limit on a users ability to read content.

    + +

    This success criterion is generally not applicable when the content repeats or is synchronized with other content, so long as the information and data is adjustable or otherwise under the control of the end user. Examples of time limits for which this success criterion is not applicable include scrolling text that repeats, captioning, and carousels. These are situations which do include time limits, but the content is still available to the user because it has controls for accessing it, as specified in 2.2.2 Pause, Stop, Hide.

    + +

    In some cases, however, it is not possible to change the time limit (for example, for an auction or other real-time event) and exceptions are therefore provided for those cases.

    +

    Content that operates on a timer does not need to be time adjustable if there is an alternative that does not rely on a timer. For example, a web application such as an email client provides notification of new email arriving with a temporary message (such as a 'toast' message) in the lower right-hand side of the interface, and the message disappears after 5 seconds. Users are able to identify the arrival of email through other means, such as viewing the Inbox, so the disappearance of the message does not set a time limit on the their ability to determine if new mail has arrived. If the user has no other means of discovering the same information (or performing the same function), then each message would need to meet this Success Criterion in order to provide users with sufficient time to access the information.

    +

    Notes regarding server time limits @@ -109,7 +116,7 @@

    Intent of Timing Adjustable

    See also - 2.2.1: No Timing. + 2.2.3: No Timing.

    @@ -170,7 +177,7 @@

    Examples of Timing Adjustable

    bid. Since the time limit applies to all users who want to bid on a particular item, it would be unfair to extend the time limit for any one particular user. Therefore, a time limit is required for this type of activity and no extension, adjustment, or - deactivation of the time limit is required by this Success Criteria. + deactivation of the time limit is required by this Success Criterion.
  • @@ -213,11 +220,11 @@

    Sufficient Techniques for Timing Adjustable

    Situation A: If there are session time limits:

    -
      +
    + @@ -238,17 +245,17 @@

    Situation A: If there are session time limits:

    Situation B: If a time limit is controlled by a script on the page:

    -
      +
    + @@ -294,35 +281,35 @@

    Situation B: If a time limit is controlled by a script on the page:

    Situation C: If there are time limits on reading:

    -
      +
    + @@ -341,7 +328,7 @@

    Failures for Timing Adjustable

  • - Failure due to using meta redirect with a time limit + Failure due to using meta redirect with a time limit @@ -349,7 +336,7 @@

    Failures for Timing Adjustable

  • - Failure due to using meta refresh with a time limit + Failure due to using meta refresh with a time limit @@ -357,7 +344,7 @@

    Failures for Timing Adjustable

  • - Failure due to using server-side techniques to automatically redirect pages after + Failure due to using server-side techniques to automatically redirect pages after a time limit diff --git a/understanding/20/understanding-metadata.html b/understanding/20/understanding-metadata.html index f3dbda0ca3..78ba9cea84 100644 --- a/understanding/20/understanding-metadata.html +++ b/understanding/20/understanding-metadata.html @@ -1,8 +1,8 @@ - + Understanding Metadata - +

    Understanding Metadata

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

    Understanding Metadata

    In conjunction with WCAG, metadata can play a number of roles including:

    -
      +
      • Metadata can be used to associate conforming alternate versions of Web pages with Web pages which do not conform, in order to allow users to find the conforming alternate @@ -45,7 +45,7 @@

        Understanding Metadata

        which one would best meet the user's needs.
      • -
    +
    diff --git a/understanding/20/unusual-words.html b/understanding/20/unusual-words.html index 99adb35c13..e2cb48fe00 100644 --- a/understanding/20/unusual-words.html +++ b/understanding/20/unusual-words.html @@ -3,11 +3,20 @@ Understanding Unusual Words - +

    Understanding Unusual Words

    +
    +

    In brief

    +
    +
    Goal
    Users can identify and learn what unusual words mean.
    +
    What to do
    Provide definitions for technical jargon and unusual terms.
    +
    Why it's important
    More people, especially those with cognitive disabilities, can understand the meaning of content.
    +
    + +

    Intent of Unusual Words

    @@ -56,56 +65,20 @@

    Benefits of Unusual Words

    Examples of Unusual Words

    -
      - -
    • - -

      - - Text that includes a definition for a word used in an unusual way. - -

      - -

      Organize the list or "cascade" of dictionaries and other resources so that the definition +

      +
      Text that includes a definition for a word used in an unusual way
      +
      Organize the list or "cascade" of dictionaries and other resources so that the definition search will find the intended definitions instead of displaying definitions from other sources in the "cascade." (The "cascade" lists the dictionaries and other reference materials in the order most likely to bring up the right definition. This controls - the order to follow when searching for definitions.) -

      - -
    • - -
    • - -

      - - Including definitions in the glossary. - -

      - -

      WCAG 2.0 uses the word "text" in a specific way. Thus, when the word "text" is used + the order to follow when searching for definitions.) +

      Including definitions in the glossary
      +
      WCAG 2.0 uses the word "text" in a specific way. Thus, when the word "text" is used within WCAG 2.0 it is linked to the definition of "text" provided in a glossary within - the same Web page. -

      - -
    • - -
    • - -

      - - The specific definition of a word is provided at the bottom of the page. - -

      - -

      The internal link from the word to the corresponding definition is also provided within - the page. - -

      - -
    • - -
    + the same Web page. +
    The specific definition of a word is provided at the bottom of the page
    +
    The internal link from the word to the corresponding definition is also provided within the page.
    +
    @@ -157,13 +130,13 @@

    Sufficient Techniques for Unusual Words

    Situation A: If the word or phrase has a unique meaning within the Web page:

    -
      +
    +
    @@ -283,13 +244,13 @@

    Situation A: If the word or phrase has a unique meaning within the Web page:

    Situation B: If the word or phrase means different things within the same Web page:

    -
      +
    + diff --git a/understanding/20/use-of-color.html b/understanding/20/use-of-color.html index b3888cd814..2f913938dd 100644 --- a/understanding/20/use-of-color.html +++ b/understanding/20/use-of-color.html @@ -1,19 +1,28 @@ - + Understanding Use of Color - +

    Understanding Use of Color

    +
    +

    In brief

    +
    +
    Goal
    Color is not the only way of distinguishing information.
    +
    What to do
    Use information in addition to color, such as shape or text, to convey meaning.
    +
    Why it's important
    Not everyone sees colors or sees them the same way.
    +
    + +

    Intent of Use of Color

    -

    The intent of this Success Criterion is to ensure that all users can access information +

    The intent of this Success Criterion is to ensure that all sighted users can access information that is conveyed by color differences, that is, by the use of color where each color has a meaning assigned to it. If the information is conveyed through color differences in an image (or other non-text format), the color may not be seen by users with color @@ -21,10 +30,10 @@

    Intent of Use of Color

    another visual means ensures users who cannot see color can still perceive the information.

    -

    Color is an important asset in design of Web content, enhancing its aesthetic appeal, +

    Color is an important asset in the design of Web content, enhancing its aesthetic appeal, its usability, and its accessibility. However, some users have difficulty perceiving color. People with partial sight often experience limited color vision, and many older - users do not see color well. In addition, people using text-only, limited-color or + users do not see color well. In addition, people using limited-color or monochrome displays and browsers will be unable to access information that is presented only in color.

    @@ -36,15 +45,84 @@

    Intent of Use of Color

    of prompting a response would be: using highlighting on form fields to indicate that a required field had been left blank.

    - +
    -

    This should not in any way discourage the use of color on a page, or even color coding - if it is redundant with other visual indication. +

    This should not in any way discourage the use of color on a page, or even color coding if it is complemented by other visual indication.

    - + + +
    + +

    If content is conveyed through the use of colors that differ not only in their hue, + but that also have a significant difference in lightness, then this counts as an additional + visual distinction, as long as the difference in relative luminance between the colors leads + to a contrast ratio of 3:1 or greater. + For example, a light green and a dark red differ both by color (hue) + and by lightness, so they would pass if the contrast ratio is at least 3:1. + Similarly, if content is distinguished by inverting an element's foreground and background colors, + this would pass (again, assuming that the foreground and background colors have a sufficient contrast). +

    +

    However, if content relies on the user's ability to accurately perceive or differentiate a particular color + an additional visual indicator will be required regardless of the contrast ratio between those colors. For example, + knowing whether an outline is green for valid or red for invalid. +

    + +
    + +
    + +

    This criterion does not apply to situations where color has not been used to convey information, indicate an action, + prompt a response or distinguish a visual element. For instance, a hyperlink which has been styled to appear no different than neighboring + static text would not fail this success criterion, as there would be no color differentiation between the actionable hyperlink text + and the adjacent static text. Such lack of styling differentiation could result in poor usability for anyone looking at the interface, regardless of disability. +

    + +
    + +
    + +

    This criterion does not directly address the needs of users with assistive technologies. + It aims to ensure that sighted users who cannot distinguish between some colors can still + understand content. + How information is conveyed to assistive technology users is covered separately in other + criteria, including (but not limited to) + 1.1.1 Non-text Content, + 1.3.1 Info and Relationships, and + 4.1.2 Name, Role, Value. +

    +

    Conversely, even if information that is conveyed by color differences is appropriately conveyed + to assistive technologies, it does not necessarily pass this criterion, as sighted users who cannot + distinguish between certain color may not necessarily be using any assistive technologies. This + criterion requires a visible alternative to color. +

    + +
    + +
    + +

    Most user agents provide users with a color-only cue that a link has been previously activated by them ("visited"). However, several technical constraints result in authors having very limited control over these color-only indications of visited links. The technical constraints are as follows:

    + +
      +
    • + User agents constrain the exposure of a link's visited state due to privacy concerns. Author queries to user agents will indicate all links have not been visited. +
    • +
    • + Any available information on the visited state of a link would be inaccurate since it is both user and browser-dependent. Even if an author could accurately get information on previously activated links by a certain user, the author would be constrained to the current browser's preserved history, and would be unable to determine if the user had visited the page using a different browser (or if the history was not preserved, either from cache clearing or use of private sessions). +
    • +
    • + Authors can only use color to modify the :visited CSS pseudoclass style. The technology constrains any non-color styling. Due to palette limitations, an author cannot use color alone to achieve 3:1 contrast between link and non-link text as well as between visited and unvisited links while also achieving 4.5:1 contrast for all link and non-link text. +
    • +
    • + Authors also cannot set the visited state of links. The anchor element does not include a "visited" attribute; therefore the author has no ability to alter the state through an attribute setting. As such, authors cannot achieve 1.3.1 Info and Relationships or + 4.1.2 Name, Role, Value in regard to visited links. +
    • +
    + +

    For these reasons, setting or conveying a link's visited status is not an author responsibility. Where color alone distinguishes between visited and unvisited links, it does not result in a failure of this Success Criterion, even where the contrast between the two link colors is below 3:1. Note that authors must continue to ensure that all text links meet contrast minimums against the page background (SC 1.4.3).

    +
    @@ -61,7 +139,7 @@

    Benefits of Use of Color

    in other visual ways.
  • -
  • People using text-only, limited color, or monochrome displays may be unable to access +
  • People using limited color monochrome displays may be unable to access color-dependent information.
  • @@ -69,10 +147,6 @@

    Benefits of Use of Color

    cues. -
  • People using Braille displays or other tactile interfaces can detect text cues by - touch. -
  • - @@ -80,67 +154,20 @@

    Benefits of Use of Color

    Examples of Use of Color

    - -
      - -
    • - -

      - - A form that uses color and text to indicate required fields - -

      - -

      A form contains both required and optional fields. Instructions at the top of the - form explain that required fields are labeled with red text and also with an icon - whose text alternative says, "Required." Both the red text and the icon are programmatically - associated with the appropriate form fields so that assistive technology users can - determine the required fields. - -

      - -
    • - -
    • - -

      - - An examination. - -

      - -

      Students view an SVG image of a chemical compound and identify the chemical elements - present based on the colors and numbers used in the diagram. The text alternatives - associated with each element name the color of the element and indicate the element's - position in the diagram. Students who cannot perceive color have the same information - about the compound as their classmates. (This technique also satisfies - Guideline 1.1 Level A.) -

      - -
    • - -
    • - -

      - - Disabled Form elements. - -

      - -

      - Form elements which are disabled via markup or scripting, are greyed out and made - inactive by the user agent. When in the disabled state these elements do not receive - focus. Assistive technologies can programmatically determine the state of disabled - elements and will provide this information to the user as the elements are encountered - on the page. The change in color and loss of focus provides redundant, visual information - about the state of the control. - - -

      - -
    • - -
    +
    +
    A form that uses color and text to indicate required fields
    +
    A form contains both required and optional fields. Instructions at the top of the + form explain that required fields are labeled with red text and also with an icon. + Users who cannot perceive the difference between the optional field labels and the + red labels for the required fields will still be able to see the icon next to the + red labels.
    +
    An examination
    +
    Students view an SVG image of a chemical compound and identify the chemical elements + present based both on the colors used, as well as numbers next to each + element. A legend shows the color and number for each type of element. Sighted users who + cannot perceive all the color differences can still understand the image by relying on + the numbers.
    +
    @@ -152,7 +179,7 @@

    Resources for Use of Color

  • - Vischeck + Vischeck
  • @@ -170,7 +197,7 @@

    Resources for Use of Color

  • - Microsoft: Can Color-Blind Users See Your Site? + Microsoft: Verify that a page is usable by people with color blindness
  • @@ -182,16 +209,16 @@

    Resources for Use of Color

  • - How to make figures and presentations that are friendly to Colorblind people + How to make figures and presentations that are friendly to Colorblind people
  • - The Color Tutor application + The Color Tutor application
  • - + @@ -210,23 +237,23 @@

    Situation A: If the color of particular words, backgrounds, or other content to indicate information:

    -
      +
    + @@ -248,21 +275,21 @@

    Situation A: If the color of particular words, backgrounds, or other content

    Situation B: If color is used within an image to convey information:

    -
      +
    + @@ -276,7 +303,7 @@

    Additional Techniques (Advisory) for Use of Color

  • - + Using CSS to change the presentation of a user interface component when it receives focus
  • @@ -292,7 +319,7 @@

    Failures for Use of Color

  • - Failure due to having a text alternative that does not include information that is + Failure due to having a text alternative that does not include information that is conveyed by color in the image @@ -300,7 +327,7 @@

    Failures for Use of Color

  • - Failure of Success Criterion 1.4.1 due to creating links that are not visually evident + Failure of Success Criterion 1.4.1 due to creating links that are not visually evident without color vision @@ -308,7 +335,7 @@

    Failures for Use of Color

  • - Failure of 1.4.1 due to identifying required or error fields using color differences + Failure of 1.4.1 due to identifying required or error fields using color differences only diff --git a/understanding/20/visual-presentation.html b/understanding/20/visual-presentation.html index 88fe6f0e50..e3c7cc7f4c 100644 --- a/understanding/20/visual-presentation.html +++ b/understanding/20/visual-presentation.html @@ -3,16 +3,24 @@ Understanding Visual Presentation - +

    Understanding Visual Presentation

    - +
    +

    In brief

    +
    +
    Goal
    Text appearance can be altered by users to meet preferences.
    +
    What to do
    Meet text display requirements or allow users to adjust them.
    +
    Why it's important
    Some text formats are more readable for people with cognitive disabilities and low vision.
    +
    + +
    +

    Intent of Visual Presentation

    -

    The intent of this Success Criterion is to ensure that visually rendered text is presented in such a manner that it can be perceived without its layout interfering with its readability. People with some cognitive, language and learning disabilities @@ -59,13 +67,12 @@

    Intent of Visual Presentation

    together, so that it is difficult for them to locate word boundaries.

    -

    The resizing provision ensures that visually rendered text (text characters that have - been displayed so that they can be seen [vs. text characters that are still in data - form such as ASCII]) can be scaled successfully without requiring that the user - scroll left and right to see all of the content. When the content has been authored - so that this is possible, the content is said to reflow. This permits people with - low vision and people with cognitive disabilities to increase the size of the text - without becoming disoriented. +

    The resizing provision ensures that visually rendered text, including + controls and labels using text, can be made larger without requiring the user to then + scroll left and right to see all of the content. When the content has been authored + so that this is possible, the content is said to reflow. This permits people with + low vision and people with cognitive disabilities to increase the size of the text + without becoming disoriented.

    The scaling of content is primarily a user agent responsibility. User agents that @@ -73,7 +80,7 @@

    Intent of Visual Presentation

    responsibility is to create Web content that does not prevent the user agent from scaling the content and that allows the reflow of the content within the current width of the viewport. See - 1.4.2: Resize text for additional discussion of resizing text. + 1.4.4: Resize Text for additional discussion of resizing text.

    The horizontal scrolling requirement is not intended to apply to small-screen devices @@ -101,12 +108,11 @@

    Intent of Visual Presentation

    -
    +

    Benefits of Visual Presentation

    - - +

    This Success Criterion helps low vision users by letting them see text without distracting presentational features. It lets them configure text in ways that will be easier for them to see by letting them control the color and size of blocks of text. @@ -117,413 +123,243 @@

    Benefits of Visual Presentation

      -
    • People with some cognitive disabilities can read text better when they select their own foreground and background color combinations.
    • -
    • People with some cognitive disabilities can track their locations more easily when blocks of text are narrow and when they can configure the amount of space between lines and paragraphs.
    • -
    • People with some cognitive disabilities can read text more easily when the spacing between words is regular.
    • -
    -

    Examples of Visual Presentation

    - -

    The following images show examples of single-spacing, space-and-a-half and double-spaced - text in a paragraph. -

    - - - - +
    +
    The following images show examples of single-spacing, space-and-a-half and double-spaced text in a paragraph.
    + Example of single-spaced text. (no space between each line of text) + Example of space-and-a-half text. (a space equal to half the height of a line of text line) + Example of double-spaced text. (a space equal to the height of a line of text between each line) +
    +

    Examples of glyphs include "A", "→" (an arrow symbol), and "さ" (a Japanese character).

    -

    Resources for Visual Presentation

    - - -

    Techniques for Visual Presentation

    - -

    Sufficient Techniques for Visual Presentation

    - -

    - Instructions: Since this is a multi-part success criterion, you must satisfy one of the numbered items for each of the requirements below.

    - - -
      - +
    - +
    -
    - - -
      - +
    - +
    -
    - - -
      - +
    - +
    -
    - - -
      - +
    - +
    -
    - - -
      - +
    - +
    -

    Additional Techniques (Advisory) for Visual Presentation

    - -

    Failures for Visual Presentation

    - - -
    diff --git a/understanding/21/accessible-authentication.html b/understanding/21/accessible-authentication.html deleted file mode 100644 index bf5d9b2b63..0000000000 --- a/understanding/21/accessible-authentication.html +++ /dev/null @@ -1,99 +0,0 @@ - - - - - WCAG 2.0 Understanding Page - - - -

    Understanding Accessible Authentication

    -
    -

    Intent

    -

    The intent of this success criterion is to ensure that, that users do not encounter a barrier that prevents them from accessing content that they could otherwise use.

    -

    Most user interfaces are designed to help users complete tasks. However, traditionally, web security and privacy technologies intentionally introduce barriers to task completion. They require users to perceive more and to do more to complete tasks.

    -

    Web security and privacy technologies often block people with cognitive and/or physical disabilities who may not be able to:

    -
      -
    • discern text they are required to enter and submit;
    • -
    • recall text or instructions they have seen or heard;
    • -
    • follow multi-step procedures.
    • -
    -

    The scope of the problem is vast because, for examples, people with disabilities:

    -
      -
    • are prevented from purchasing goods and registering for services on the millions of websites that employ web security and privacy technologies;
    • -
    • may circumvent web security and privacy technologies with insecure techniques/methods;
    • -
    • may become so frustrated working through web security and privacy technologies that they relinquish their efforts, and thereby are thwarted from purchasing goods and registering for services;
    • -
    • may be unable to become accustomed to a web security and privacy technology because there are multiple versions of it across websites.
    • -
    • may be afraid to trust a web site, thus causing them to cancel a transaction.
    • -
    -

    Many user authentication methods rely upon trying to differentiate between a human, and software (bots) that try to pose as a human. The most common way of trying to make this distinction is by the setting of tasks that rely upon human abilities, and that are almost impossible for software (bots) to perform. These methods can frequently be quite challenging for people who have a high level of cognitive ability. For people who have  a disability or cognitive disability such as dementia, an authentication task often presents an insurmountable barrier.

    -
    -
    -

    Benefits

    -

    The benefit of this success criteria is it allows people with cognitive and learning disabilities to use many  important sites. Long changing passwords and  other difficult authentication procedures prevent many people from using critical services. For example,  people cannot make doctors appointments by themselves and often put off making a doctor appointment as not to be a burden to other people.. This may be partly responsible for the reduced life expectancy of people with learning and cognitive disabilities.

    -

    With this success criterion, people who are able to use a primary user authentication method will be able to successfully complete a user authentication procedure almost irrespective of the level of their cognitive abilities. Those who have to use an alternative method will be able to successfully complete a user authentication even though they have limited levels of the cognitive abilities specified in the success criterion.

    -
    -
    -

    Examples

    -
      -
    1. As a user who has memory impairments and often forgets passwords, I need to be able to use a site, without remembering or copying passwords and usernames, so that I can use this service.
    2. -
    3. As a user who has impairments, I need to be able to use a site without being required to copy items in the correct sequence.
    4. -
    5. As a user who has weak executive function, I need the login process to be simple, and not multi-step, so that I can use it.
    6. -
    7. As a symbol user, I need a login process I can use.
    8. -
    -
    -
    -

    Resources

    - -
    -
    -

    Techniques

    -
    -

    Sufficient

    -
      -
    • Allowing the user to reset a password by pressing a link sent to them in an SMS or email.sms, which brings the user to a page that displays either the:
        -
      • current username and/or password; OR
      • -
      • suggested new username and/or password; OR
      • -
      • opportunity to create a new username and/or password
      • -
      -
    • -
    • Compiling to https://www.w3.org/TR/webauthn/ and allowing one component method such as biometrics or tokens (Possibly reword this to be more clear)
    • -
    • Automatic user authentication based upon the use of a trusted device (to which the user has already logged in with their own identity);
    • -
    • Security tokens, some of which are hardware devices, can be used to make authentication easier. Security tokens are used instead of, or in addition to, other forms of authentication such as passwords. Security-token hardware devices:
        -
      • include key fobs, rings, or small keypads;
      • -
      • can store and/or generate a digital signature, a PIN, or biometric data;
      • -
      • can transmit such data via a USB connector, RFID, Bluetooth wireless, or NFC.
      • -
      • -
      -
    • -
    • biometrics;
    • -
    • being already logged in to third-party authentication services (e.g., OAuth, Facebook, etc.).
    • -
    • Fast IDentity Online (FIDO), password-free standards for typical and two-factor authentication.
        -
      • FIDO relies upon user authentication based upon a user's device (e.g., phone, tablet, computer).
      • -
      • A user's device registers the user, to a server, via a public key.
      • -
      • Upon a challenge from the server, the user's device responds with a private key.
      • -
      • The device's keys are unlocked by the user biometrically (e.g., fingerprint scanner) or by a button press, not by a password.
      • -
      -
    • -
    -
    -
    - - diff --git a/understanding/21/animation-from-interactions.html b/understanding/21/animation-from-interactions.html index af10ee5ade..d5b51b9378 100644 --- a/understanding/21/animation-from-interactions.html +++ b/understanding/21/animation-from-interactions.html @@ -1,37 +1,47 @@ - + Understanding Animation from Interactions - +

    Understanding Animation from Interactions

    + +
    +

    In brief

    +
    +
    Goal
    Users are not harmed or distracted by motion.
    +
    What to do
    Support user preferences for motion, and eliminate unnecessary motion effects.
    +
    Why it's important
    People can get sick from motion effects.
    +
    + +
    +

    Intent

    The intent of this Success Criterion is to allow users to prevent animation from being displayed on Web pages. Some users experience distraction or nausea from animated content. For example, if scrolling a page causes elements to move (other than the essential movement associated with scrolling) it can trigger vestibular disorders. Vestibular (inner ear) disorder reactions include dizziness, nausea and headaches. Another animation that is often non-essential is parallax scrolling. Parallax scrolling occurs when backgrounds move at a different rate to foregrounds. Animation that is essential to the functionality or information of a web page is allowed by this Success Criterion.

    -

    "Animation from interactions" applies when a user’s interaction initiates non-essential animation. In contrast, 2.2.2 Pause, Stop, Hide applies when the web page initiates animation.

    +

    "Animation from interactions" applies when a user’s interaction initiates non-essential animation. In contrast, 2.2.2 Pause, Stop, Hide applies when the web page initiates animation.

    The impact of animation on people with vestibular disorders can be quite severe. Triggered reactions include nausea, migraine headaches, and potentially needing bed rest to recover.

    -

    How can a website reduce the chances of triggering a vestibular disorder? Choose any one of the following solutions. Avoid using unnecessary animation. Provide a control for users to turn off non-essential animations from user interaction. Take advantage of the reduce motion feature in the user-agent or operating system.

    +

    How can a website reduce the chances of triggering a vestibular disorder? Choose any one of the following solutions. Avoid using unnecessary animation. Provide a control for users to turn off non-essential animations from user interaction. Take advantage of the reduce motion feature in the user agent or operating system.

    What about movement caused by a user scrolling a page? Moving new content into the viewport is essential for scrolling. The user controls the essential scrolling movement so it is allowed. Only add non-essential animation to the scrolling interaction in a responsible way. Always give users the ability to turn off unnecessary movement.

    - -
    -

    Benefits

    -
      -
    • Vestibular Disorder -
        -
      • People with vestibular disorders need control over movement triggered by interactions. Non-essential movement can trigger vestibular disorder reactions. Vestibular (inner ear) disorder reactions include distraction, dizziness, headaches and nausea.
      • -
      • Persona Quote: "Stop that extra movement! You are making me so dizzy I cannot concentrate. Now I have to turn off my computer and go lie down."
      • -
      -
    • -
    -
    +
    +

    Benefits

    +
      +
    • Vestibular Disorder +
        +
      • People with vestibular disorders need control over movement triggered by interactions. Non-essential movement can trigger vestibular disorder reactions. Vestibular (inner ear) disorder reactions include distraction, dizziness, headaches and nausea.
      • +
      • Persona Quote: "Stop that extra movement! You are making me so dizzy I cannot concentrate. Now I have to turn off my computer and go lie down."
      • +
      +
    • +
    +

    Examples

    - diff --git a/understanding/21/character-key-shortcuts.html b/understanding/21/character-key-shortcuts.html index 19bb9858c0..d5a2fe6f88 100644 --- a/understanding/21/character-key-shortcuts.html +++ b/understanding/21/character-key-shortcuts.html @@ -1,85 +1,84 @@ - + WCAG 2.0 Understanding Page - +

    Understanding Character Key Shortcuts

    + +
    +

    In brief

    +
    +
    Goal
    Reduce accidental activation of keyboard shortcuts.
    +
    What to do
    Ensure character-only shortcut keys can be turned off or modified.
    +
    Why it's important
    Character-key shortcuts are easy to accidentally trigger, especially with speech input.
    +
    +
    +

    Intent

    -

    Character key shortcuts work well for many keyboard users, but are inappropriate and frustrating for speech input users — whose means of input is strings of letters — and for keyboard users who are prone to accidentally hitting keys. -As a result, users must be able to turn off or reconfigure shortcuts made up of a single character key, or two or more successive character keys. -

    -

    This success criterion is becoming increasingly important in the mobile realm as growing number of apps more fully enable keyboard controls.

    -

    Note that this success criterion doesn’t affect components such as listboxes and drop-down menus that contain words that may be selected by one or more character keys, since the shortcuts are only active when the components have focus. Similarly, components such as menus may be accessed or opened with an initial, non-single character shortcut (e.g., “ALT” or “ALT+F”). This makes the full path to invoking a menu a two-step shortcut that includes a non-printable key.

    -

    Note that Accesskeys are not affected because they include modifier keys.

    -

    Background on the mechanics of speech input:

      -

    Speech Input users generally work in a single mode where they can use a mix of dictation and speech commands. This works well because the user knows to pause before and after commands, and commands are usually at least two words long. So, for instance, a user might say a bit of dictation, such as "the small boat", then pause, and say a command to delete that dictation, such as "Delete Line". In contrast, if the user were to say the two phrases together without a pause, the whole phrase would come out as dictation (i.e., "the small boat delete line"). Although speech input programs often include modes that listen only for dictation or only for commands, most speech users use the all-encompassing mode all the time because it is a much more efficient workflow. It could increase command inefficiency by 300% if users were to change to command mode and back before and after issuing a command.

    -

    Speech users can also speak most keyboard commands (e.g., "press Control Foxtrot") without any problems. If the website or app is keyboard enabled, the speech user can also write a native speech macro that calls the keyboard command, such as "This Print" to carry out Ctrl+P.

    -

    Single-key shortcuts are the exception. While using single letter keys as controls might be appropriate and efficient for many keyboard users, single-key shortcuts are disastrous for speech users. The reason for this is that when only a single key is used to trip a command, a spoken word can become a barrage of single-key commands if the cursor focus happens to be in the wrong place.

    -

    For example, if the cursor focus is in the main window of a web mail application that uses common keyboard shortcuts to navigate ("k"), archive ("y") and mute messages ("m"), and someone enters an office and says "Hey Kim" and the speech user's microphone picks that up, "y" archives the current message. "k" moves down one conversation and "m" mutes a message or thread. Or, if the speech user looks up and says "Hey Mike" without remembering to turn off the microphone, the same three things happen in a different sequence. A user interacting with a webpage or web app that doesn't use single-character shortcuts doesn't have this problem. A speech user filling in a text input form may find that a phrase that is accidentally picked up by the speech microphone results in stray text being entered into the field, but that is easily seen and undone. To see a video of these types of issues, go to the Resources section of this page.

    -
    -

    Benefits

    -
      -
    • Speech users will be able to turn off single-key shortcuts so they can avoid accidentally firing batches of them at once. This will allow speech users to make full use of programs that offer single-key shortcuts to keyboard users.
    • -
    • Keyboard-only users who have dexterity challenges can also be prone to accidentally hitting keys. Those users would be able to avoid problematic single character shortcuts by turning them off or modifying them to include at least one non-character key.
    • -
    -
    +

    The intent of this Success Criterion is to reduce accidental activation of keyboard shortcuts. Character key shortcuts work well for many keyboard users. However, they can be inappropriate and frustrating for speech input users, whose dictation is interpreted as strings of letters, and for keyboard users who are prone to accidentally hit keys. To rectify this issue, authors need to allow users to turn off or reconfigure shortcuts that are made up of only character keys.

    +
    +

    Even though this Success Criterion refers to character keys, note that it's not relevant whether a shortcut can be activated using a single physical key on a keyboard, or if it requires a combination of keys to be pressed. For instance, on most full-size US and UK keyboard, the ? (question mark) symbol is accessed using Shift+/ (forward slash key next to the right-hand Shift key). On a UK keyboard, in Windows, the é (lowercase "e" with an acute accent) requires the use of AltGr+e. The specific key combination required for certain characters will also vary depending on the user's keyboard layout. However, shortcuts that use these characters still fall under the requirements of this Success Criterion. What matters is that a shortcut relies on a printable character (letters, punctuation, numbers, symbol characters), and not the number of physical keyboard keys that users need to press to trigger it.

    +
    +
    +

    The Success Criterion also applies to situations where a shortcut is based on a sequence of character keys – for example, pressing G and then A in quick succession to trigger an action. While the individual character key presses don't immediately trigger the action, overall these types of shortcuts still rely on a series of character keys.

    +
    +

    This success criterion doesn't affect components such as listboxes and drop-down menus. Although these components contain values (words) that may be selected by one or more character keys, the shortcuts are only active when the components have focus. Other components such as menus may be accessed or opened with a single non-character shortcut (e.g., Alt or Alt+F) before pressing a single character key to select an item. This makes the full path to invoking a menu a two-step shortcut that includes a non-printable key. Accesskeys are also not affected because they are generally (depending on the user agent) activated using modifier keys.

    +

    Background on the mechanics of speech input

    +

    Speech input users generally work in a single mode where they can use a mix of dictation and speech commands. This works well because the user knows to pause before and after commands, and commands are usually at least two words long. So, for instance, a user might say a bit of dictation, such as "the small boat", then pause, and say a command to delete that dictation, such as "Delete Line". In contrast, if the user were to say the two phrases together without a pause, the whole phrase would come out as dictation (i.e., "the small boat delete line"). Although speech input programs often include modes that listen only for dictation or only for commands, most speech users use the all-encompassing mode all the time because it is a much more efficient workflow. It could decrease command efficiency significantly if users were to change to command mode and back before and after issuing each command.

    +

    Speech users can also speak most keyboard commands (e.g., "press Control Foxtrot") without any problems. If the website or app is keyboard enabled, the speech user can also write a native speech macro that calls the keyboard command, such as "This Print" to carry out Ctrl+P.

    +

    Single-key shortcuts are the exception. While using single letter keys as controls might be appropriate and efficient for many keyboard users, single-key shortcuts are disastrous for speech users. The reason for this is that when only a single key is used to trip a command, a spoken word can become a barrage of single-key commands if the cursor focus happens to be in the wrong place.

    +

    For example, a speech-input user named Kim has her cursor focus in the main window of a web mail application that uses common keyboard shortcuts to navigate (k), archive (y) and mute messages (m). A coworker named Mike enters her office and says "Hey Kim" and her microphone picks that up. The Y of "hey" archives the current message. K in "Kim" moves down one conversation and M mutes a message or thread. And, if Kim looks up and says "Hey Mike" without remembering to turn off the microphone, the same three things happen in a different sequence.

    +

    A user interacting with a webpage or web app that doesn't use single-character shortcuts doesn't have this problem. Inadvertent strings of characters from the speech application are not interpreted as shortcuts if a modifier key is required. A speech user filling in a text input form may find that a phrase that is accidentally picked up by the speech microphone results in stray text being entered into the field, but that is easily seen and undone. The Resources section of this page contains links to videos demonstrating these types of issues.

    +
    +

    Benefits

    +
      +
    • Speech users will be able to turn off single-key shortcuts so they can avoid accidentally firing batches of them at once. This will allow speech users to make full use of programs that offer single-key shortcuts to keyboard users.
    • +
    • Keyboard-only users who have dexterity challenges can also be prone to accidentally hitting keys. Those users would be able to avoid problematic single character shortcuts by turning them off or modifying them to include at least one non-character key.
    • +
    • Allowing all shortcut keys to be remapped can help users with some cognitive disabilities, since the same shortcuts can be assigned to perform the same actions across different applications.
    • +
    +

    Examples

    - -

    Example 1: Disable Shortcuts

    -

    A mechanism is provided to allow users to disable character-key shortcuts. The character key shortcuts are not the only way to carry out these commands. A speech user disables the shortcuts and can prevent words that are picked up by the microphone from triggering single-key shortcuts.

    +

    Disable Shortcuts

    +

    A mechanism is provided to allow users to disable character-key shortcuts. The character key shortcuts are not the only way to carry out these commands. A speech user disables the shortcuts and can prevent words that are picked up by the microphone from triggering single-key shortcuts.

    - -

    Example 2: Alternate Control

    -

    A mechanism is provided to allow users to change character-key shortcuts

    -

    A keyboard-only user is in a long issues thread. While reading the thread she accidentally hits the “s” key, which moves focus to the search bar at the top of the document. This causes her to lose her place and her train of thought. She changes the shortcut to include another key so she can avoid future interruptions.

    +

    Alternate Control

    +

    Keyboard-only users are in a long issues thread. While reading the thread they accidentally hit the S key, which moves focus to the search bar at the top of the document. This causes them to lose their place and train of thought. However, a mechanism is provided to allow users to change character-key shortcuts. They change the shortcut to include another key so they can avoid future interruptions.

    -
    -

    Example 3: Shared Alternate Control

    -

    A mechanism is provided to allow users to change character-key shortcuts in such a way that the changes can be saved and shared with other users.

    - -
    -
    +

    Resources

    Web apps that use character-key shortcuts and allow users to disable and/or change these shortcuts:

    -
      -
    • Gmail
    • -
    • WordPress
    • -
    -

    Videos of speech user trouble with single character key shortcuts:

    - -
    +
      +
    • Gmail
    • +
    • WordPress
    • +
    +

    Videos of speech user trouble with single character key shortcuts:

    + +

    Techniques

    Sufficient

    - -
      -
    • Users have a way to turn off single-key shortcuts
    • -
    • A mechanism is provided to allow users to change character-key shortcuts. The remapping mechanism includes non-printing characters. The alternative shortcuts could be longer strings of up to 25 characters that would directly serve as native speech commands for any speech engine.
    • -
    -
    -
    -

    Advisory

    - +

    Failure

      -
    • Failure of Success Criteria 2.1.4 due to a webpage or web app that includes single-key shortcuts not including a control that allows users to turn the shortcuts off or a control that allows users to change the shortcuts to key combinations that include keys that are not upper or lower-case letters, punctuation, number, or symbol characters.
    • -
    - +
  • Failure of Success Criterion 2.1.4 due to implementing character key shortcuts that cannot be turned off or remapped
  • +
    diff --git a/understanding/21/concurrent-input-mechanisms.html b/understanding/21/concurrent-input-mechanisms.html index e3080bec04..eae3199d8e 100644 --- a/understanding/21/concurrent-input-mechanisms.html +++ b/understanding/21/concurrent-input-mechanisms.html @@ -1,12 +1,23 @@ - + WCAG 2.0 Understanding Page - +

    Understanding Concurrent Input Mechanisms

    + +
    +

    In brief

    +
    +
    Goal
    Users can choose different ways of inputting content.
    +
    What to do
    Do not prevent users from switching their mode of input.
    +
    Why it's important
    People may not be able to work using just one input method.
    +
    + +
    +

    Intent

    The intent of this Success Criterion is to ensure that people can use and switch between different modes of input when interacting with web content. Users may employ a variety of input mechanisms when interacting with web content. These may be a combination of mechanisms such as a keyboard or keyboard-like interfaces and pointer devices like a mouse, stylus or touchscreen.

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

    Intent

    Note: A touch-typing web application, which teaches users how to touch-type on a keyboard and/or measures their proficiency and speed, would be an example of an essential limitation to a particular input mechanism.

    -

    Benefits

    +

    Benefits

    • Users can interact with web content with whichever input mechanism is preferred and available to them.
    • Users may switch between input mechanisms when they desire or the circumstances require it.
    • @@ -25,7 +36,7 @@

      Benefits

      Examples

        -
      • A user with mobility impairment pairs a mouse and keyboard to her mobile phone with a touchscreen. The phone can thereafter be operated by those input devices and the content does not accept the touchscreen as the only input mechanism.
      • +
      • A user with mobility impairment pairs a mouse and keyboard to a mobile phone with a touchscreen. The phone can thereafter be operated by those input devices and the content does not accept the touchscreen as the only input mechanism.
      • On a touch-enabled laptop with coarse precision, people who have difficulty activating a small target because of hand tremors, limited dexterity or other reasons are still able to interact with content using their keyboard and trackpad.
      • A user starts interacting with a page using a desktop keyboard, and then attaches a secondary touch-enabled monitor. Content can be operated using this newly added input mechanism and does not assume that the keyboard, the first input mechanism it detected, is the only one in use.
      • A speech input user navigates content using voice commands which translate to simulate mouse (and keyboard) commands. When talking with a colleague, however, the user turns speech recognition off and uses the mouse instead.
      • @@ -47,15 +58,14 @@

        Techniques

        Sufficient

          -
        • Only using high-level, input-agnostic event handlers (focus, blur, click) in Javascript (operating systems/UAs fire these events for all input mechanisms).
        • -
        • Registering event handlers for keyboard/keyboard-like and pointer inputs simultaneously in Javascript (see Example 1 in Pointer Events Level 2)
        • +
        • Only using high-level, input-agnostic event handlers, such as focus, blur, click, in Javascript (Potential future technique).
        • +
        • Registering event handlers for keyboard/keyboard-like and pointer inputs simultaneously in Javascript; see Example 1 in Pointer Events Level 2 (Potential future technique)

        Failure

          -
        • Restricting event handlers based on the presence of a detected input mechanism.
        • -
        • Using CSS Media Queries Level 4 Interaction Media Features to determine what the UA deems to be the "primary" input mechanism and assuming no other input mechanisms are present/may be added/may be used.
        • +
        • F98
      diff --git a/understanding/21/content-on-hover-or-focus.html b/understanding/21/content-on-hover-or-focus.html index 87027b3614..cdca887970 100644 --- a/understanding/21/content-on-hover-or-focus.html +++ b/understanding/21/content-on-hover-or-focus.html @@ -1,20 +1,30 @@ - + Understanding Content on Hover or Focus - +

      Understanding Content on Hover or Focus

      + +
      +

      In brief

      +
      +
      Goal
      More users can perceive and dismiss non-persistent content.
      +
      What to do
      If hover or focus causes content changes, ensure interaction is predictable.
      +
      Why it's important
      Unpredictable temporary content can be hard for some to consume and may disrupt others.
      +
      +
      +

      Intent

      Additional content that appears and disappears in coordination with keyboard focus or pointer hover often leads to accessibility issues. Reasons for such issues include:

      -
        -
      1. the user may not have intended to trigger the interaction
      2. -
      3. the user may not know new content has appeared
      4. -
      5. the new content may intefere with a user's ability to do a task
      6. -
      +
        +
      • the user may not have intended to trigger the interaction
      • +
      • the user may not know new content has appeared
      • +
      • the new content may intefere with a user's ability to do a task
      • +

      Examples of such interactions can include custom tooltips, sub-menus and other nonmodal popups which display on hover and focus. The intent of this success criterion is to ensure that authors who cause additional content to appear and disappear in this manner must design the interaction in such a way that users can:

        @@ -29,19 +39,18 @@

        Intent

      • persistent

      Each of these is discussed in a separate section.

      -

      This SC covers content that appears in addition to the triggering component itself. Therefore, a non-visible component, like a Skip to Main link, that is made visible on keyboard focus (with no additional content beyond the trigger becoming visible) is not covered by the SC. -

      Dismissable

      -

      The intent of this condition is to ensure that the additional content does not interfere with viewing or operating the page's original content. When magnified, the portion of the page visible in the viewport can be signficantly reduced. Mouse users frequently move the pointer to pan the magnified viewport and display another portion of the screen. However, almost the entire portion of the page visible in this restricted viewport may trigger the additional content, making it difficult for a user to pan without re-triggering the content. A keyboard means of dismissing the additional content provides a workaround.

      -

      Alternatively, low vision users who can only navigate via the keyboard do not want the small area of their magnified viewport cluttered with trivial hover text. They need a keyboard method of dismissing something that is obscuring the current focal area.

      -

      Two methods may be used to satisfy this condition and prevent such interference:

      +

      The intent of this condition is to ensure that the additional content does not interfere with viewing or operating the page's original content. When magnified, the portion of the page visible in the viewport can be significantly reduced. Mouse users frequently move the pointer to pan the magnified viewport and display another portion of the screen. However, almost the entire portion of the page visible in this restricted viewport may trigger the additional content, making it difficult for a user to pan without re-triggering the content. A keyboard means of dismissing the additional content provides a workaround.

      +

      Alternatively, low vision users who can only navigate via the keyboard do not want the small area of their magnified viewport cluttered with hover text. They need a keyboard method of dismissing something that is obscuring the current focal area.

      +

      Two methods may be used to satisfy this condition and prevent such interference:

        -
      1. Position the additional content so that it does not obscure any other content including the trigger, with the exception of white space and purely decorative content, such as a background graphic which provides no information.
      2. -
      3. Provide a mechanism to easily dismiss the additional content, such as by pressing Escape or selecting a close button.
      4. +
      5. Position the additional content so that it does not obscure any other content including the trigger, with the exception of white space and purely decorative content, such as a background graphic which provides no information.
      6. +
      7. Provide a mechanism to easily dismiss the additional content, such as by pressing Escape.

      For most triggers of relatively small size, it is desirable for both methods to be implemented. If the trigger is large, noticing the additional content may be of concern if it appears away from the trigger. In those cases, only the second method may be appropriate.

      +

      The success criterion allows for input error messages to persist as there are cases that require attention, explicit confirmation or remedial action.

      Hoverable

      @@ -52,52 +61,52 @@

      Hoverable

      Persistent

      The intent of this condition is to ensure users have adequate time to perceive the additional content after it becomes visible. Users with disabilities may require more time for many reasons, such as to change magnification, move the pointer, or simply to bring the new content into their visual field. Once it appears, the content should remain visible until:

        -
      • The user removes hover or focus from the trigger and the additional content, consistent with the typical user experience;
      • -
      • The user dismisses the additional content via the mechanism provided to satisfy the Dismissable condition; or
      • -
      • The information conveyed by the additional content becomes invalid, such as a 'busy' message that is no longer valid.
      • +
      • The user removes hover or focus from the trigger and the additional content, consistent with the typical user experience;
      • +
      • The user dismisses the additional content via the mechanism provided to satisfy the Dismissable condition; or
      • +
      • The information conveyed by the additional content becomes invalid, such as a 'busy' message that is no longer valid.

      Additional Notes

        -
      • This criterion does not attempt to solve such issues when the appearance of the additional content is completely controlled by the user agent. A prominent example is the common behavior of browsers to display the title  attribute in HTML as a small tooltip.
      • -
      • Modal dialogs are out of scope for this criterion because they must take keyboard focus and thus should not appear on hover or focus. Refer to Success Criterion 3.2.1, On Focus.
      • -
      • Content which can be triggered via pointer hover should also be able to be triggered by keyboard focus. Refer to Success Criterion 2.1.1, Keyboard.
      • +
      • This criterion does not attempt to solve such issues when the appearance of the additional content is completely controlled by the user agent. A prominent example is the common behavior of browsers to display the title  attribute in HTML as a small tooltip.
      • +
      • Modal dialogs are out of scope for this criterion because they must take keyboard focus and thus should not appear on hover or focus. Refer to Success Criterion 3.2.1, On Focus.
      • +
      • Content which can be triggered via pointer hover should also be able to be triggered by keyboard focus. Refer to Success Criterion 2.1.1, Keyboard.
      - -
      + +

      Benefits

        -
      • Users with low vision who view content under magnification will be better able to view content on hover or focus without reducing their desired magnification.
      • -
      • Users who increase the size of mouse cursors via platform settings or assistive technology will be able to employ a technique to view obscured content on hover.
      • -
      • Users with low vision or cognitive disabilities will have adequate time to perceive additional content appearing on hover or focus and to view the trigger content with less distraction.
      • -
      • users with low pointer accuracy will be able to more easily dismiss unintentionally-triggered additional content
      • +
      • Users with low vision who view content under magnification will be better able to view content on hover or focus without reducing their desired magnification.
      • +
      • Users who increase the size of mouse cursors via platform settings or assistive technology will be able to employ a technique to view obscured content on hover.
      • +
      • Users with low vision or cognitive disabilities will have adequate time to perceive additional content appearing on hover or focus and to view the trigger content with less distraction.
      • +
      • users with low pointer accuracy will be able to more easily dismiss unintentionally-triggered additional content
      - +

      Examples

      - +

      Example 1: Dismissable Tooltip

      -
      - Screenshot of a button with a mouse pointer over it, and a tooltip displayed  below the button - Screenshot of a button with a mouse pointer over it, and no tooltip +
      + Screenshot of a button with a mouse pointer over it, and a tooltip displayed  below the button + Screenshot of a button with a mouse pointer over it, and no tooltip
      A tooltip is displayed below a LVTF button on hover so as not to obscure the button itself. It does however obscure content below the button (the next red button, called ~comment-zoom-content). To meet the Dismissible requirement, a user can press the Escape key to clear the tooltip without moving the mouse, as demonstrated in the second image.
      -
      - Screenshot of a button with a focus indicator on it, and no tooltip +
      + Screenshot of a button with a focus indicator on it, and no tooltip
      The button's tooltip also appears on focus and can be removed with the Escape key. The screen shot shows the same LVTF button with focus, but the tooltip has been dismissed and is no longer visible.
      - +

      Example 2: Hoverable Tooltip

      -
      - Screenshot of a button with a large mouse pointer over it, and a tooltip displayed  below the button which is obscured by the large pointer - Screenshot of a button with a tooltip below it, and a large mouse pointer at the bottom of the tooltip +
      + Screenshot of a button with a large mouse pointer over it, and a tooltip displayed  below the button which is obscured by the large pointer + Screenshot of a button with a tooltip below it, and a large mouse pointer at the bottom of the tooltip
      A button's tooltip is displayed directly below it on mouse hover which can easily be obscured by a large pointer. The tooltip itself is able to be hovered so the mouse pointer can be moved down to its bottom edge in order to view the tooltip text.
      @@ -106,17 +115,18 @@

      Example 2: Hoverable Tooltip

      Resources

      - +

      Techniques

      Sufficient

      @@ -189,7 +327,7 @@

      Graphical Objects

      Not every graphical object needs to contrast with its surroundings - only those that are required for a user to understand what the graphic is conveying. Gestalt principles such as the "law of continuity" can be used to ignore minor overlaps with other graphical objects or colors.

      - +
      @@ -198,35 +336,35 @@

      Graphical Objects

      - - + - + - - + + A line chart of votes across a region, with 4 lines of different colors tracking over time. - - + - + @@ -26,12 +47,12 @@

      Dinosaur conference workshops timetable Thursday, 14. & Friday, 15. March 2

      - + - +
      Image
      An orange circle with a white telephone icon in the middle.

      The phone icon is a simple shape within the orange circle. The meaning can be understood from that icon alone, the background behind the circle is irrelevant. The orange background and the white icon have a contrast ration greater than 3:1, which passes.

      +
      An orange circle with a white telephone icon in the middle.

      The phone icon is a simple shape within the orange (#E3660E) circle. The meaning can be understood from that icon alone, the background behind the circle is irrelevant. The orange background and the white icon have a contrast ratio greater than 3:1, which passes.

      The graphical object is the white phone icon.

      A red magnet with grey tips and a black outline.A red magnet with grey tips and a black outline.

      A magnet can be understood by the "U" shape with lighter colored tips. Therefore to understand this graphic you should be able to discern the overall shape (against the background) and the lighter colored tips (against the rest of the U shape and the background).

      -

      The graphical objects are the "U" shape (by outline or by the solid red color), and each tip of the magnet.

      +

      The graphical objects are the "U" shape (by outline or by the solid red color #D0021B), and each tip of the magnet.

      A yellow arrow pointing down with a pound sign (currency) in the middle.

      The low-currency symbol can be understood with recognition of the shape (down arrow) and the currency symbol (pound icon with the shape). To understand this graphic you need to discern the arrow shape against the white background, and the pound icon against the yellow background.

      +
      A yellow arrow pointing down with a pound sign (currency) in the middle.

      The symbol to show a currency (the £) going down can be understood with recognition of the shape (down arrow) and the currency symbol (pound icon with the shape which is part of the graphic). To understand this graphic you need to discern the arrow shape against the white background, and the pound icon against the yellow background (#F5A623).

      The graphical objects are the shape and the currency symbol.

      - A line chart of votes across a region, with 4 lines of different colors tracking over time.

      In order to understand the graph you need to discern the lines and shapes for each condition. Therefore each line and colored shape is a ‘graphical object’ in the graph and should be over 3:1 against the white background. Most of them have good contrast except the green triangles.

      +

      In order to understand the graph you need to discern the lines and shapes for each condition. To perceive the values of each line along the chart you need to discern the grey lines marking the graduated 100 value increments.

      The graphical objects are the lines in the graph, including the background lines for the values, and the colored lines with shapes.

      -

      The lines should have 3:1 contrast against their background, but as there is little overlap with other lines they do not need to contrast with each other. (See the testing principles below.)

      +

      The lines should have 3:1 contrast against their background, but as there is little overlap with other lines they do not need to contrast with each other or the graduated lines. (See the testing principles below.)

      A pie chart with small gaps between each slice showing the white background, and a dark outline around light colored slices.A pie chart with small gaps between each slice showing the white background, and a dark outline around light colored slices.

      To understand the pie chart you have to discern each slice of the pie chart from the others.

      The graphical objects are the slices of the pie (chart).

      Note: If the values of the pie chart slices were also presented in a conforming manner (see the Pie Charts example for details), the slices would not be required for understanding.

      @@ -237,9 +375,9 @@

      Graphical Objects

      Taking the magnet image above as an example, the process for establishing the graphical object(s) is to:

        -
      • Assess what part of each image is needed to understand what it represents.
        +
      • Assess what part of each image is needed to understand what it represents.
        The magnet's "U" shape can be conveyed by the outline or by the red background (either is acceptable). The white tips are also important (otherwise it would be a horseshoe), which needs to contrast with the red background.
      • -
      • Assume that the user could only see those aspects. Do they contrast with the adjacent colors?
        +
      • Assume that the user could only see those aspects. Do they contrast with the adjacent colors?
        The outline of the magnet contrasts with the surrounding text (black/white), and the red and white between the tips also has sufficient contrast.
      @@ -250,7 +388,10 @@

      Required for Understanding

      The term "required for understanding" is used in the Success Criterion as many graphics do not need to meet the contrast requirements. If a person needs to perceive a graphic, or part of a graphic (a graphical object) in order to understand the content it should have sufficient contrast. However, that is not a requirement when:

        -
      • A graphic with text embedded or overlayed conveys the same information, such as labels and values on charts.
      • +
      • +

        A graphic with text embedded or overlayed conveys the same information, such as labels and values on a chart.

        +

        Text within a graphic must meet 1.4.3 Contrast (Minimum).

        +
      • The graphic is for aesthetic purposes that does not require the user to see or understand it to understand the content or use the functionality.
      • The information is available in another form, such as in a table that follows the graph, which becomes visible when a "Long Description" button is pressed.
      • The graphic is part of a logo or brand name (which is considered "essential" to its presentation).
      • @@ -260,17 +401,18 @@

        Required for Understanding

        Gradients

        Gradients can reduce the apparent contrast between areas, and make it more difficult to test. The general principles is to identify the graphical object(s) required for understanding, and take the central color of that area. If you remove the adjacent color which does not have sufficient contrast, can you still identify and understand the graphical object?

        -
        Two versions of a blue circle with an 'i' indicating information. The first example has a blue gradient background, the second is missing the upper half of the background which obscures the i. +
        + Two versions of a blue circle with an 'i' indicating information. The first example has a blue gradient background, the second is missing the upper half of the background which obscures the i.
        Removing the background which does not have sufficient contrast highlights that the graphical object (the "i") is not then understandable.

        Dynamic Examples

        -

        Some graphics may have interactions that either vary the contrast, or display the information as text when you mouseover/tap/focus each graphical object. In order for someone to discern the graphics exist at all, there must be contrasting colors or text in order to find the graphics. Within that area, information available by a conforming method (e.g., focusable elements) can be used to make that information available dynamically as text, or dynamically increase the contrast.

        +

        Some graphics may have interactions that either vary the contrast, or display the information as text when you mouseover/tap/focus each graphical object. In order for someone to discern the graphics exist at all, the unfocused default version must already have sufficiently contrasting colors or text. For the area that receives focus, information can then be made available dynamically as pop-up text, or be foregrounded dynamically by increasing the contrast.

        -
        - A pie chart with one slice highlighted and a box hovering next to it that shows the data and indicates the source in the key. +
        + A pie chart with one slice highlighted and a box hovering next to it that shows the data and indicates the source in the key.
        A dynamic chart where the current 'slice' is hovered or focused, which activates the associated text display of the values and highlights the series
        @@ -282,15 +424,25 @@

        Infographics

        Infographics often fail to meet several WCAG level AA criteria including:

        -

        An infographic can use text which meets the other criteria to minimise the number of graphical objects required for understanding. For example, using text with sufficient contrast to provide the values in a chart. A long description would also be sufficient because then the infograph is not relied upon for understanding.

        +

        An infographic can use text which meets the other criteria to minimise the number of graphical objects required for understanding. For example, using text with sufficient contrast to provide the values in a chart. A long description would also be sufficient because then the infographic is not relied upon for understanding.

        + + +
        +

        Symbolic text characters

        +

        When text characters are used as symbols – used for their visual appearance, rather than expressing something in human language – they fall under the definition of non-text content.

        +
        + A button using an uppercase 'X' and a button with a greater-than character +
        Even though the two buttons use text characters — an uppercase X, often used for "Close" buttons, and a > character, to act as a right-pointing arrow — they count as non-text characters/symbols. Their contrast ratio of just above 3:1 passes this Success Criterion.
        +
        +

        Essential Exception

        @@ -310,7 +462,7 @@

        Essential Exception

        Testing Principles

        -

        A summary of the high-level process for finding and assessing non-text graphics on a web page:

        +

        A summary of the high-level process for finding and assessing non-text content on a web page:

        • Identify each user-interface component (link, button, form control) on the page and:
            @@ -318,17 +470,17 @@

            Testing Principles

          • Test those contrast indicators in each state.
        • -
        • Identify each graphic on the page that includes information required for understanding the content (i.e. excluding graphics which have visible text for the same information, or are decorative) and: +
        • Identify each graphic on the page that includes information required for understanding the content (i.e., excluding graphics which have visible text for the same information, or are decorative) and:
          • Check the contrast of the graphical object against its adjacent colors;
          • -
          • If there are multiple colors and/or a gradient, chose the least contrasting area to test;
          • +
          • If there are multiple colors and/or a gradient, choose the least contrasting area to test;
          • If it passes, move to the next graphical object;
          • If the least-contrasting area is less than 3:1, assume that area is invisible, is the graphical object still understandable?
          • If there is enough of the graphical object to understand, it passes, else fail.
        -

        The techniques below each have testing criteria, and the related criteria for Focus visible (2.4.7), Use of color (1.4.1), and Contrast minimum also have techniques.

        +

        The techniques below each have testing criteria, and the related criteria for Focus visible (2.4.7), Use of color (1.4.1), and Contrast minimum also have techniques.

        @@ -339,7 +491,7 @@

        Testing Principles

        Benefits

        People with low vision often have difficulty perceiving graphics that have insufficient contrast. This can be exacerbated if the person has a color vision deficiency that lowers the contrast even further. Providing a relative luminance (lightness difference) of 3:1 or greater can make these items more distinguishable when the person does not see a full range of colors.

        - +

        Graphical Object Examples

          @@ -349,21 +501,21 @@

          Graphical Object Examples

        Pie Charts

        -

        Pie charts make a good case study for the graphical objects part of this success criteria, the following pie charts are intended to convey the proportion of market share each browser has. Please Note: The actual figures are made up, these are not actual market shares.

        -
        - Failing pie chart +

        Pie charts make a good case study for the graphical objects part of this success criterion, the following pie charts are intended to convey the proportion of market share each browser has. Please Note: The actual figures are made up, these are not actual market shares.

        +
        + Failing pie chart

        Fail: The pie chart has labels for each slice (so passes 1.4.1 Use of Color), but in order to understand the proportions of the slices you must discern the edges of the slices (the graphical objects conveying essential information), and the contrast between the slices is not 3:1 or greater.

        -
        - Not applicable pie chart +
        + Not applicable pie chart

        Not applicable: The pie chart has visible labels and values that convey equivalent information to the graphical objects (the pie slices).

        -
        - Passing pie chart +
        + Passing pie chart

        Pass: The pie chart has visible labels, and sufficient contrast around and between the slices of the pie chart (the graphical objects). A darker border has been added around the yellow slice in order to achieve the contrast level.

        @@ -371,15 +523,15 @@

        Pie Charts

        Infographics

        -
        - An infographic showing lightly colored circles of various sizes to indicate the size of five different social networks +
        + An infographic showing lightly colored circles of various sizes to indicate the size of five different social networks

        Fail: Discerning the circles is required to understand the size of network and discerning the icons in each circle is required to identify which network it shows.

        The graphical objects are the circles (measured against the background) and the icons in each circle (measured against the circle's background).

        -
        - The same infographic with contrasting text, dark borders around the circles, and contrasting icons. +
        + The same infographic with contrasting text, dark borders around the circles, and contrasting icons.

        Pass: The circles have contrasting borders and the icons are a contrasting dark color against the light circle backgrounds.

        @@ -402,39 +554,31 @@

        Techniques

        Sufficient

        -

        User Interface Component contrast

        - -
        -
        -

        Graphics with sufficient contrast

        - +

        Situation A: Color is used to identify user interface components or used to identify user interface component states

        +
        -

        Text in or over graphics

        +

        Situation B: Color is required to understand graphical content

        -
        + +

        Failures

        diff --git a/understanding/21/orientation.html b/understanding/21/orientation.html index 163ba80c97..33f6c2b967 100644 --- a/understanding/21/orientation.html +++ b/understanding/21/orientation.html @@ -1,55 +1,67 @@ - + WCAG 2.1 Understanding Orientation - +

        Orientation -
        +
        Understanding SC 2.6.2

        + +
        +

        In brief

        +
        +
        Goal
        Devices can be used in any orientation.
        +
        What to do
        Don't lock content to either portrait or landscape presentation.
        +
        Why it's important
        Wheelchair users and others may have devices mounted in a fixed orientation.
        +
        + +
        +

        Intent of this Success Criterion

        The intent of this Success Criterion is to ensure that content displays in the orientation (portrait or landscape) preferred by the user. Some websites and applications automatically set and restrict the screen to a particular display orientation and expect that users will respond by rotating their device to match, but this can create problems. Some users have their devices mounted in a fixed orientation (e.g. on the arm of a power wheelchair). Therefore, websites and applications need to support both orientations - by not restricting the orientation. Changes in content or functionality due to the size of display are not covered by this criteria which is focused on restrictions of orientation.

        + by not restricting the orientation. Changes in content or functionality due to the size of display are not covered by this criterion which is focused on restrictions of orientation.

        -

        Historically, devices tended to have a fixed-orientation display, and all content was created to match that display orientation. Today, most handhelds and many other devices (e.g., monitors) have a hardware-level ability to dynamically adjust default display orientation based on sensor information. The goal of this Success Criterion is that authors should never restrict content's orientation, thus ensuring that it always match the device display orientation.

        +

        Historically, devices tended to have a fixed-orientation display, and all content was created to match that display orientation. Today, most handhelds and many other devices (e.g., monitors) have a hardware-level ability to dynamically adjust default display orientation based on sensor information. The goal of this Success Criterion is that authors should never restrict content's orientation, thus ensuring that it always match the device display orientation.

        -

        Locking a device to an orientation

        +

        Locking a device to an orientation

        -

        It is important to distinguish between an author's responsibility not to restrict content to a specific orientation, and device-specific settings governing the locking of display orientation.

        +

        It is important to distinguish between an author's responsibility not to restrict content to a specific orientation, and device-specific settings governing the locking of display orientation.

        -

        Many hand-held devices offer a mechanical switch or a system setting (or both) to allow the user to lock the device display to a specific orientation. Where a user decides to lock their entire device to an orientation, all applications are expected to pick up that setting and to display content accordingly.

        +

        Many hand-held devices offer a mechanical switch or a system setting (or both) to allow the user to lock the device display to a specific orientation. Where a user decides to lock their entire device to an orientation, all applications are expected to pick up that setting and to display content accordingly.

        -

        This Success Criterion complements device "lock orientation" settings. A web page that does not restrict its display orientation will always support the system-level orientation setting, since the system setting is picked up by the user agent. Alternatively, where a device-level orientation lock is not in place, the user agent should display the page according to the orientation of the device (either its default, or the current orientation determined by any device sensors).

        - -
        -

        Benefits

        -
          -
        • Users with dexterity impairments, who have a mounted device will be able to use the content in their fixed orientation.
        • -
        • Users with low-vision will be able to view content in the orientation that works best for them, for example to increase the text size by viewing content in landscape.
        • -
        -
        +

        This Success Criterion complements device "lock orientation" settings. A web page that does not restrict its display orientation will always support the system-level orientation setting, since the system setting is picked up by the user agent. Alternatively, where a device-level orientation lock is not in place, the user agent should display the page according to the orientation of the device (either its default, or the current orientation determined by any device sensors).

        + +

        The exception for things considered essential is aimed at situations where the content would only be understood in a particular orientation, or where the technology restricts the possible orientations. If content is aimed at a specific environment which is only available in one orientation (such as a television) then the content can restrict the orientation. Technologies such as virtual reality use screens within goggles that cannot change orientation relative to the user's eyes.

        +
        +
        +

        Benefits

        +
          +
        • Users with dexterity impairments, who have a mounted device will be able to use the content in their fixed orientation.
        • +
        • Users with low-vision will be able to view content in the orientation that works best for them, for example to increase the text size by viewing content in landscape.
        • +

        Examples

          -
        • Example 1: Online video site
          +
        • Example 1: Online video site
          A video is shown in either portrait or in landscape based on the user's chosen orientation.
        • -
        • Example 2: Messaging website
          +
        • Example 2: Messaging website
          A messaging website can display messages in both portrait and landscape orientations.
        • -
        • Example 3: eReader web app
          +
        • Example 3: eReader web app
          An eReader web app can display the contents of a book in both portrait and landscape orientation.
        • -
        • Example 4: Check deposit in banking app
          +
        • Example 4: Check deposit in banking app
          An example where orientation is essential could be a banking app that requires the device be in landscape mode to easily and accurately capture an image of a check for deposit. These paper forms are typically about twice as wide as they are high.
        • -
        • Example 5: Piano app
          +
        • Example 5: Piano app
          An example where orientation is essential could be a piano app that requires the device to be in landscape mode to allow room for enough of the piano keys to be functionally usable. Since a piano app is emulating a physical piano keyboard that needs to retain relative physical characteristics between keys, either too few keys would be available, or the keys would be much too narrow.
        @@ -70,14 +82,14 @@

        Techniques

        Sufficient

          -
        • Using CSS to set the orientation to allow both landscape and portrait.
        • -
        • Use of show/hide controls to allow access to content in different orientations.
        • +
        • G214

        Failure

          -
        • Locking the orientation.
        • +
        • F97
        • +
        • F100
        diff --git a/understanding/21/pointer-cancellation.html b/understanding/21/pointer-cancellation.html index 21d3e1b454..78519394d1 100644 --- a/understanding/21/pointer-cancellation.html +++ b/understanding/21/pointer-cancellation.html @@ -1,12 +1,22 @@ - + Understanding Pointer Cancellation - +

        Understanding Pointer Cancellation

        + +
        +

        In brief

        +
        +
        Goal
        Reduce accidental activation of controls by mouse or touch.
        +
        What to do
        Make pointer cancellation predictable and consistent.
        +
        Why it's important
        Make it easier for anyone to recover from something they didn’t mean to do.
        +
        + +

        Intent

        The intent of this success criterion is to make it easier for users to prevent accidental or erroneous pointer input. People with various disabilities can inadvertently initiate touch or mouse events with unwanted results. Each of the following subsections roughly aligns with the bullets of this Success Criterion, and outlines a means of allowing users to cancel pointer operations.

        @@ -28,7 +38,7 @@

        Up-Event Abort or Undo

      • moved to a new location, while still being depressed, and
      • released (up-event) to conclude the drop action.
      • -

        In such a complex action, the need for an Abort or Undo function increases. Designers may elect to confirm the move through something like a confirmation dialog or an undo button, giving the user the ability to Undo the process just completed. Alternatively, the ability to Abort the action can be acheived if, before completing step 3, the user returns the selected item to its original location and concludes the process there. If other parts of the screen disallow a move, the user can conclude the drag and drop there, effectively nullifying the operation.

        +

        In such a complex action, the need for an Abort or Undo function increases. Designers may elect to confirm the move through something like a confirmation dialog or an undo button, giving the user the ability to Undo the process just completed. Alternatively, the ability to Abort the action can be achieved if, before completing step 3, the user returns the selected item to its original location and concludes the process there. If other parts of the screen disallow a move, the user can conclude the drag and drop there, effectively nullifying the operation.

        Up Reversal

        @@ -46,13 +56,13 @@

        Down-Event

      -
      -

      Benefits

      -
        -
      • Makes it easier for all users to recover from hitting the wrong target.
      • -
      • Helps people with visual disabilities, cognitive limitations, and motor impairments by reducing the chance that a control will be accidentally activated or an action will occur unexpectedly, and also ensures that where complex controls are activated, a means of Undoing or Aborting the action is available.
      • -
      • Individuals who are unable to detect changes of context are less likely to become disoriented while navigating a site.
      • -
      +
      +

      Benefits

      +
        +
      • Makes it easier for all users to recover from hitting the wrong target.
      • +
      • Helps people with visual disabilities, cognitive limitations, and motor impairments by reducing the chance that a control will be accidentally activated or an action will occur unexpectedly, and also ensures that where complex controls are activated, a means of Undoing or Aborting the action is available.
      • +
      • Individuals who are unable to detect changes of context are less likely to become disoriented while navigating a site.
      • +

      Examples

      @@ -62,29 +72,27 @@

      Examples

    • A drag-and-drop interface allows users to sort vertically stacked cards by picking up one card with the pointer (down-event), move it to a new position, and insert it at the new location when the pointer is released (up-event). Releasing the pointer outside the drop target area reverts the action, i.e., it moves the card back to the old position before the interaction started.
    • -
      -

      Resources

      -
        -
      • Resource
      • -
      -

      Techniques

      Sufficient

      +
    • G210
    • +
    • G212
    • +
    • Touch events are only triggered when touch is removed from a control (Potential future technique)
    • +
      -
      +

      Failure

      +
    • Failure of Success Criterion 2.5.2 due to activating a control on the down-event
    • +
      diff --git a/understanding/21/pointer-gestures.html b/understanding/21/pointer-gestures.html index 498c596b52..1d935f749d 100644 --- a/understanding/21/pointer-gestures.html +++ b/understanding/21/pointer-gestures.html @@ -1,68 +1,118 @@ - + WCAG 2.0 Understanding Page - + -

      Pointer Gestures
      Understanding SC 2.5.1

      - +

      Pointer Gestures
      Understanding SC 2.5.1

      + +
      +

      In brief

      +
      +
      Goal
      Let users operate touchscreens with one finger and reduced gestures.
      +
      What to do
      Provide single-point operation for all functions.
      +
      Why it's important
      Not everyone can perform complex and multi-touch gestures.
      +
      + +
      +

      Intent of this Success Criterion

      -

      The intent of this Success Criterion is to ensure that content can be operated using simple inputs on a wide range of pointing devices. This is important for users who cannot perform complex gestures, such as multi-point or path-based gestures, in a precise manner, either because they may lack the accuracy necessary to carry them out or because they use a pointing method that lacks the capability or accuracy.

      -

      A path-based gesture involves a user interaction where the gesture's success is dependent on the path of the user's pointer movement and not just the endpoints. Examples include swiping (which relies on the direction of movement) the dragging of a slider thumb, or gestures which trace a prescribed path, as in the drawing of a specific shape. Such paths may be drawn with a finger or stylus on a touchscreen, on a graphics tablet or trackpad, or with a mouse, joystick, or similar pointer device.

      -

      A user may find it difficult or impossible to accomplish these if they have impaired fine motor control, or if they use a specialized or adapted input device such as a head pointer, eye-gaze system, or speech-controlled mouse emulation.

      -

      Note that free-form drag and drop actions are not considered path-based gestures for the purposes of this Success Criterion.

      -

      Examples of multi-point gestures include a two-finger pinch zoom, a split tap where one finger rests on the screen and a second finger taps, or a two or three finger tap or swipe. A user may find it difficult or impossible to accomplish these if they type and point with a single finger or stick, in addition to any of the causes listed above.

      -

      Authors must ensure that their content can be operated without such complex gestures. When they implement multi-point or path-based gestures, they must ensure that the functionality can also be operated via single-point activation. Examples of single-point activation on a touchscreen or touchpad include taps, double taps, and long presses. Examples for a mouse, trackpad, head-pointer, or similar device include single clicks, click-and-hold and double clicks.

      -

      The success criterion applies to author-created gestures, as opposed to gestures defined on the level of operating system or user agent. An example for gestures provided on the operating system level would be swiping down to see system notifications, and gestures for built-in assistive technologies (AT) to focus or activate content, or to call up AT menus. An example of user agent-implemented gestures would be horizontal swiping implemented by browsers for navigating within the page history, or vertical swiping to scroll page content.

      -

      While some operating systems may provide ways to define "macros" to replace complex gestures, content authors cannot rely on such a capability because is not pervasive on all touch-enabled platforms. Moreover, this may work for standard gestures that a user can predefine, but may not work for other author-defined gestures.

      -

      This Success Criterion does not require all functionality to be available through pointing devices, but that which is must be available to users who use the pointing device but cannot perform complex gestures. While content authors may provide keyboard commands or other non-pointer mechanisms that perform actions equivalent to complex gestures (see Success Criterion 2.1.1 Keyboard), this is not sufficient to conform to this success criterion. That is because some users rely entirely on pointing devices, or find simple pointer inputs much easier than alternatives. For example, a user relying on a head-pointer would find clicking a control to be much more convenient than activating an on-screen keyboard to emulate a keyboard shortcut, and a person who has difficulty memorizing a series of keys (or gestures) may find it much easier to simply click on a labeled control. Therefore, if one or more pointer-based mechanisms are supported, then their benefits should be afforded to users through simple, single-point actions alone.

      -

      An exception is made for functionality that is inherently and necessarily based on complex paths or multi-point gestures. For example, entering one's signature may be inherently path-based (although acknowledging something or confirming one's identity need not be).

      - -
      -

      Benefits

      -
        -
      • Users who cannot (accurately) perform complex pointer gestures will have alternative means for operating the content.

      • -
      • The availability of user interface elements provided as a fallback for complex gestures helps users who may often be unaware of the support for complex pointer gestures. This can be beneficial especially for users with cognitive or learning disabilities.

      • -
      -
      +

      The intent of this Success Criterion is to ensure that content can be controlled with a range of pointing devices, abilities, and assistive technologies. Some people cannot perform gestures in a precise manner, or they may use a specialized or adapted input device such as a head pointer, eye-gaze system, or speech-controlled mouse emulator. Some pointing methods lack the capability or accuracy to perform multipoint or path-based gestures.

      + +

      A path-based gesture involves an interaction where not just the endpoints matter, but how the pointer moves between these points.

      + +

      If the gesture is only recognised if the user moves in a (mostly) straight line from the start point to the end point, it is an example of a path-based gesture.

      + +
      + Hand showing a starting touch, 1. Moving in a straight line to a second point, 2. +
      A path-based gesture where pointer movement is only allowed in a straight line from the start-point to the end-point. If the user strays from the straight directional path, the gesture is not recognised, has no effect, or is aborted.
      +
      + +

      If going through an intermediate point (usually near the start of the gesture) affects its meaning, then it is a path-based gesture. The user engages a pointer (starting point), carries out a movement that goes through at least one intermediate-point before disengaging the pointer (end point). The intermediate point defines the gesture as requiring a specific path, even if the complete path is not defined.

      + +
      + Hand showing a starting touch, 1. Moving through a second point, 2. Going to one of several points,3. +
      A path-based gesture involves starting a pointer movement that goes through at least one intermediate point before the end-point. The end-point may be a continuation, or allow for various movements.
      +
      + +

      Examples of path-based gestures include swiping, sliders and carousels dependent on the direction of interaction, and other gestures which trace a prescribed path such as drawing a specific shape. Such paths may be drawn with a finger or stylus on a touchscreen, graphics tablet, or trackpad, or with a mouse, joystick, or similar pointer device.

      + +

      The difference between Pointer Gestures and Dragging

      +

      Dragging is a movement where the user picks up an object with a pointer (such as mouse cursor or a finger) and moves it to some other position. This movement from start point to end point does not require the user to follow any particular path or direction. Dragging is therefore not path-based. In contrast, a path-based pointer gesture requires the traversal of an intermediate point, which is a technical way of expressing that the directionality and possibly speed of the gesture communicates a particular command to the system. Dragging motions are covered in Success Criterion 2.5.7: Dragging Movements.

      + +
      + Hand showing a starting touch, 1. Going to a second point, 2. It follows a very random path. +
      A free-form gesture does not require any particular path before the end-point, only the start and (optionally) the end point matter. This is not path-based
      +
      + +

      Challenges for people with disabilities

      +

      Any movement of a pointer could be difficult or impossible to use for someone who cannot perform precise movements, therefore alternative forms of interaction are always recommended. This success criterion is scoped to path-based gestures as it may be difficult or impossible to provide an alternative for free-form gestures.

      + +

      Examples of multipoint gestures include a two-finger pinch zoom, a split tap where one finger rests on the screen and a second finger taps, or a two- or three-finger tap or swipe. Users may find it difficult or impossible to accomplish these if they type and point with a single finger or stick.

      + +

      Authors must ensure that their content can be operated without multipoint or path-based gestures. Multipoint or path-based gestures can be used so long as the functionality can also be operated by another method, such as a tap, click, double tap, double click, long press, or click & hold.

      + +

      This Success Criterion applies to gestures in the author-provided content, not gestures defined by the operating system, user agent, or assistive technology. Examples of operating system gestures would be swiping down to see system notifications and gestures for built-in assistive technologies (AT). Examples of user agent-implemented gestures would be horizontal swiping implemented by browsers for navigating within the page history, or vertical swiping to scroll page content.

      + +

      There are times when a component requires a path-based gesture for touch screen devices but not with a mouse. Taking an example of a generic slider:

      +
        +
      • Using a mouse: If the user clicks on the thumb control of the slider and moves vertically, the slider will respond by moving to the right or left, even if the movement is mostly upwards. There will be no page scrolling as a result of the vertical movement as long as they drag with focus on the slider. Therefore, the slider does not require a path-based gesture with mouse pointer.
      • +
      • Using a touch-screen: If the user puts their finger on the thumb control of the slider and moves upwards more than sideways, the slider may not respond because the browser takes control of the swipe and interprets it as a scroll, and will move the page up and down. Moving left or right on the slider thumb engages the slider and then the user can vary their vertical movement. This implementation has the 3-point requirement to work with a finger on a touch screen device so is a path-based gesture.
      • +
      +

      As touch screen devices can apply default gestures it is important to test with them if you are unsure whether a particular component does require a path-based gesture.

      + +

      Browsers on a touch screen device generally provide some default gestures that impact whether a path-based gesture is needed. For example, a web browser on a touch-screen devices might detect a vertical gesture and scroll the page. If a user places their finger on a slider thumb and moves up (to scroll down) that might not activate the slider (depending on implementation). If the user moves horizontally first then the slider could capture that gesture and ignore vertical movement, resulting in a path-based gesture. If you include touch-screen devices as accessibility supported then these types of interaction need testing with a touch screen as using a mouse in a similar way would not trigger the same browser behavior.

      + +

      This Success Criterion does not require all functionality to be available through pointing devices, but if it is available to pointer devices then it should not require path-based gestures. While content authors generally need to provide keyboard commands or other non-pointer mechanisms that perform actions equivalent to complex gestures (see Success Criterion 2.1.1 Keyboard), this is not sufficient to conform to this Success Criterion. That is because some users rely entirely on pointing devices, or find simple pointer inputs much easier to perform and understand than alternatives. For example, a user relying on a head-pointer would find clicking a control to be much more convenient than activating an on-screen keyboard to emulate a keyboard shortcut, and a person who has difficulty memorizing a series of keys (or gestures) may find it much easier to simply click on a labeled control. Therefore, if one or more pointer-based mechanisms are supported, then their benefits should be afforded to users through simple, single-point actions alone.

      + +

      Single pointer operations include taps and clicks, double-taps and double-clicks, long presses, swiping, dragging, and path-based gestures. Gestures such as "pinch to zoom" or two-finger swipes are multipoint gestures, as they require two or more pointer inputs - in this case, two fingers on a touchscreen.

      + +

      An exception is made for functionality that is inherently and necessarily based on complex paths or multipoint gestures. For example, entering your signature may be inherently path-based (although acknowledging something or confirming your identity need not be).

      + +

      This Success Criterion does not apply to gestures that involve dragging in any direction because only the start and end points matter in a dragging operation. However, such gestures do require fine motor control. Authors are encouraged to provide non-dragging methods, for instance, a drag and drop operation could also be achieved by selecting an item (with a tap or keyboard interaction) and then selecting its destination as a second step.

      +
      +
      +

      Benefits

      +
        +
      • Users who cannot (accurately) perform path-based pointer gestures - on a touchscreen, or with a mouse - will have alternative means for operating the content.

      • +
      • Users who cannot perform multi-pointer gestures on a touchscreen (for instance, because they are operating the touchscreen with an alternative input such as a head pointer) will have a single-pointer alternative for operating the content.

      • +
      • Users who may not understand the custom gesture interaction intended by the author will be able to rely on simple, frequently used gestures to interact. This can be especially beneficial for users with cognitive or learning disabilities.

      • +

      Examples

      -
        -
      • A web site includes a map view that supports the pinch gesture to zoom into the map content, and drag gestures to move the visible area. User interface controls offer the operation via [+] and [-] buttons to zoom in and out, and arrow buttons to pan stepwise in all directions.

      • -
      • A news site has a horizontal content slider with hidden news teasers that can moved into the viewport via horizontal swiping. It also offers forward and backward arrow buttons for single-point activation to navigate to adjacent slider content.

      • -
      • A mortgage lending site has a slider control for setting the amount of credit required. The slider can be operated by dragging the thumb, but also by a single tap or click anywhere on the slider groove in order to set the thumb to the chosen position.

      • -
      • A slider control can be operated by dragging the thumb. Buttons on both sides of the slider increment and decrement the selected value and update the thumb position.

      • -
      • A kanban widget with several vertical areas representing states in a defined process allows the user to right- or left-swipe over elements to move them to an adjacent silo. The user can also accomplish this by selecting the element with a single tap or click, and then activating an arrow button to move the selected element.

      • -
      +
        +
      • A web site includes a map view that supports the pinch gesture to zoom into the map content. User interface controls offer the operation using plus and minus buttons to zoom in and out.

      • +
      • A web site includes a map view that supports the pinch gesture to zoom into the map content. As an single-pointer alternative, the map also allows users to double-tap, hold, and then move the pointer up or down to zoom in or out.

      • +
      • A news site has a horizontal content slider with hidden news teasers that can moved into the viewport via a fast horizontal swipe/flicking motion. It also offers forward and backward arrow buttons for single-point activation to navigate to adjacent slider content.

      • +
      • A kanban widget with several vertical areas representing states in a defined process allows the user to right- or left-swipe elements to move them to an adjacent silo. The user can also accomplish this by selecting the element with a single tap or click, and then activating an arrow button to move the selected element.

      • +
      • A custom slider requires movement in a strict left/right direction when operated by dragging the thumb control. Buttons on both sides of the slider increment and decrement the selected value and update the thumb position.

      • +

      Resources

      -
      -

      Techniques for SC 2.5.1 - Pointer Gestures

      -

      Sufficient Techniques

      -
        -
      • GXXX: Do not rely on path-based gestures

      • -
      • GXXX: Do not rely on multi-point gestures

      • -
      • GXXX: Provide controls that do not require complex gestures and perform the same function as complex gestures

      • -
      • GXXX: Single-point activation for spatial positioning and manipuation

      • -
      - +

      Techniques

      +
      +

      Sufficient

      +
      - +

      Advisory

      Failure

        -
      • Functionality can be operated by pointer input but not with single-point activation alone
      • -
      +
    • F105
    • +
      diff --git a/understanding/21/reflow.html b/understanding/21/reflow.html index 98d8fa59c6..a03d1f481f 100644 --- a/understanding/21/reflow.html +++ b/understanding/21/reflow.html @@ -1,84 +1,100 @@ - + Understanding Reflow - +

      Understanding Reflow

      + +
      +

      In brief

      +
      +
      Goal
      Content can be enlarged without increasing line length.
      +
      What to do
      Make lines of text reflow within the viewport.
      +
      Why it's important
      People who need bigger text find it difficult if they must scroll to read long lines.
      +
      + +

      Intent of this Success Criterion

      The intent of this Success Criterion is to support people with low vision who need to enlarge text and read it in a single column. When the browser zoom is used to scale content to 400%, it reflows - i.e., it is presented in one column so that scrolling in more than one direction is not necessary.

      -

      For people with low vision, enlarged text with reflow enables reading. It is critical. Enlargement enables perception of characters. Reflow enables tracking. Tracking is following along lines of text, including getting from the end of one line to the beginning of the next line.

      +

      For people with low vision, both enlarging and reflowing text are critical to reading. Enlarging text enables the perception of characters. Reflowing text enables users to track from the end of one line to the beginning of the next line.

      Avoiding the need to scroll in the direction of reading in order to reveal lines that are cut off by the viewport is important, because such scrolling significantly increases the effort required to read. It is also important that content is not hidden off-screen. For example, zooming into a vertically scrolling page should not cause content to be hidden to one side.

      -
      +

      How reflow works

      -

      User agents for technologies such as HTML/CSS, PDF, and ePub have methods for reflowing content to fit the width of the window (viewport). When appropriately authored, page content can reflow (wrap) to stay within the window's boundaries (viewport) when users zoom in to enlarge the size of content. Spatial relationships of content may change when users zoom, but all information and functionality should continue to be available.

      +

      User agents for technologies such as HTML/CSS, PDF, and ePub have methods for reflowing content to fit the width of the window (viewport). When appropriately authored, page content can reflow (wrap) to stay within the window's boundaries (viewport) when users zoom in to enlarge the size of content. Spatial relationships of content may change when users zoom, but all information and functionality should continue to be available.

      Supporting the reflow of content is also known as 'Responsive Web Design'. It is enabled by CSS media queries which reformat the web content for different viewport widths (at particular break points) in order to provide optimised layouts for mobile devices such as tablets or smartphones. Importantly, these breakpoints are not only triggered by narrower viewports, but also when users employ the browser zoom function to zoom into the page.

      In a desktop browser at 100% (default) scale, typical web pages that support reflow display content in two, three or more columns. Zooming in will at some point trigger a change of layout, so content will now be displayed in fewer columns. At a higher magnification scale of 200% or more, content will usually be rendered in a single column. Parts of content that were in the marginal columns, like a navigation menu or supplementary content, will now typically appear on top of or below the main content.

      -
      -
      +
      +

      Viewing distance and display resolution

      -

      The value of 320 CSS pixels was chosen as a reasonable minimum size that authors can achieve. This value lines up with the reported viewport width of small displays of common mobile devices. The width of 320 CSS pixels exactly corresponds to a desktop browser window set to a width of 1280px and zoomed in to 400%. It should be noted that 400% applies to the dimension, not the area. It means four times the default width and four times the default height.

      -
      Diagram showing the size of character needed by viewing distance to make the same image on the retina with small screen devices close, large screen devices further away. -
      Fig. 1: A letter of the same CSS pixel size on different displays with different resolutions
      +

      The value of 320 CSS pixels was chosen as a reasonable minimum size that authors can achieve. This value lines up with the reported viewport width of small displays of common mobile devices. The width of 320 CSS pixels exactly corresponds to a desktop browser window set to a width of 1280px and zoomed in to 400%. It should be noted that 400% applies to the dimension, not the area. It means four times the default width and four times the default height.

      +
      Diagram showing the size of character needed by viewing distance to make the same image on the retina with small screen devices close, large screen devices further away. +
      A letter of the same CSS pixel size on different displays with different resolutions

      When we read, the size of the print is not as important as the image it projects on the retina of our eye. Phones are designed for close viewing while desktops are designed for viewing farther away. As a consequence 16px print on a phone is physically smaller than 16px print on a desktop. This is not a problem because both print sizes cast the same image on our retina if they are viewed at their intended distance.

      -
      -
      +
      +

      Visibility and availability of content

      How much of the content is visible may change at different scales. For example, navigation menus that are fully visible in the desktop layout are often collapsed into fewer items, or even into a single menu button (the 'hamburger' icon pattern) so they take up less screen space.

      The Success Criterion is met as long as all content and functionality are still fully available - either directly, or revealed via accessible controls, or accessible via direct links.

      -
      -
      +
      +

      Content exceptions for reflow

      -

      Content which requires two-dimensional layout for usage or meaning cannot reflow without losing meaning, and is therefore out of scope of this Success Criterion. For example, graphics and video are by their nature two-dimensional. Cutting up an image and stacking the blocks would render the content unusable so that is out of scope. However, it is possible to have these elements stay within the bounds of viewport at zoom levels to 400% (see advisory techniques).

      -

      Complex data tables have a two-dimensional relationship between the headings and data cells. This relationship is essential to convey the content. This Success Criterion therefore does not apply to data tables.

      -

      Interfaces which provide toolbars to edit content need to show both the content and the toolbar in the viewport. Depending on the number of toolbar buttons, the toolbar may need to scroll in the direction of text (e.g., horizontally in a vertically scrolling page). This Success Criterion therefore does not apply to interfaces which provide toolbars.

      -
      -
      -

      Browsers in mobile operating systems

      -

      The layout method of most common browsers in mobile operating systems does not offer reflow in the same way as on desktop browsers. In these browsers, content can be magnified in different ways, for example, by using a pinch gesture to scale up content, or a double tap on a particular column to make it fill the viewport width. This means that currently, mobile browsers usually exhibit horizontal scrolling regardless of what an author does.

      -

      In principle, mobile user agents can equally offer reflow when users zoom into content, as evidenced by the Dolphin browser for Android. The lack of reflow support in mobile operating systems can therefore be regarded as a user agent support issue.

      -
      -
      +

      Content which requires two-dimensional layout for usage or meaning cannot reflow without loss of meaning, and is therefore excepted from the need to be presented without two-dimensional scrolling. For example, graphics and video are by their nature two-dimensional. Cutting up an image and stacking the blocks would render the content unusable. However, it is possible to have these elements stay within the bounds of viewport even as other content zooms to 400% (see advisory techniques).

      +

      Data tables have a two-dimensional relationship between the headings and data cells. This relationship is essential to convey the content. This Success Criterion therefore exempts data tables from needing to display without scrolling in the direction of text (e.g., horizontally in a vertically scrolling page). However, cells within data tables are not excepted unless the cell contains types of content that also requires two-dimensional layout for usage or meaning.

      +

      Interfaces which provide toolbars to edit content need to show both the content and the toolbar in the viewport. Depending on the number of toolbar buttons, the toolbar may need to scroll in the direction of text.

      +
      +

      Responsive web design and other ways to meet this Success Criterion

      Using the responsive web design approach is the most effective method of achieving the goal of allowing people to zoom in to 400%. Each variation (CSS break point) of the page at the same URL should conform (compare Conformance for WCAG 2.1).

      For organisations which are using legacy systems or are not able to update their layout methods for some reason, an alternative conforming version could be a mobile site which has a fixed 320px wide layout. The user should be able to find that version from the default website.

      -
      -
      -

      Avoiding scrolling in horizontally and vertically written languages

      -

      The success Criterion applies to both horizontally and verticaly written languages. Zooming the page for horizontally written languages where pages scroll vertically by default (e.g. English) should not require horizontal scrolling. Zooming the page for vertically written languages which scroll horizontally by default should not require vertical scrolling.

      -
      +
      +
      +

      Avoiding scrolling in horizontally and vertically written languages

      +

      The success Criterion applies to both horizontally and vertically written languages. Zooming the page for horizontally written languages where pages scroll vertically by default (e.g. English) should not require horizontal scrolling. Zooming the page for vertically written languages which scroll horizontally by default should not require vertical scrolling.

      +
      +
      +

      The relation of Reflow to the Success Criterion 1.4.4 Resize Text

      +

      The focus of the Reflow Success Criterion is to enable users to zoom in without having to scroll in two directions. Success Criterion 1.4.4 Resize Text also applies, so it should be possible to increase the size of all text up to 200% while simultaneously meeting the reflow requirement. For most implementations, the text is expected to continue to enlarge as the magnification increases, so that users can magnify text up to (and beyond) 400%. In an implementation where text does not consistently increase its size as people zoom in (such as when it is transformed based on a media query to adapt to small-screen usage), it must still be possible to get to 200% enlargement in order to satisfy the Resize Text criterion.

      +

      For example, if at the default browser setting of 100% zoom, text is set at 20px when the window is 1280 CSS pixels wide, at 200% zoom it will visually appear at twice the size. After zooming by 400% the page reflows to fit within the 320 CSS pixel viewport, the author may decide to set the page's text size to 10px. The text is now half the original size in CSS pixels, but as it has been enlarged to 400%, it is still displayed at twice the size compared to the default browser setting at 100% zoom. It is not required to achieve 200% text enlargement while remaining inside a specific breakpoint (as zooming may result in the variation for a new breakpoint becoming active), but it should still be possible to get 200% text enlargement in some way compared to the default 100% zoom.

      +
      -

      The relation of Reflow to the Success Criterion 1.4.4 Resize Text

      -

      The focus of the Reflow Success Criterion is to enable users to zoom in without having to scroll in two directions. Success Criterion 1.4.4 Resize Text also applies, so it should be possible to increase the size of all text to at least 200% while simultaneously meeting the reflow requirement. If text is reduced in size when people zoom in (or for small-screen usage), it should still be possible to get to 200% enlargement. For example, if text is set at 20px when the window is 1280px wide, at 200% zoom it should be at least 20px (so 200% of the default size), but at 400% zoom it could be set to 10px (therefore still 200% of the default 100% view). It is not required to achieve 200% enlargement at every breakpoint, but it should be possible to get 200% enlargement in some way.

      +

      Browsers on mobile operating systems

      +

      Most browsers on mobile operating systems do not combine reflow and zoom in the same way as on desktop browsers. These mobile browsers normally support reflow when changing the orientation of the device -- content will be adjusted to the new viewport width. However, these mobile browsers can only magnify content to achieve 1.4.4. Resize Text in manners which do not constrain reflow to a single dimension, for example by using a pinch gesture to scale up content or a double tap on a particular column to make it fill the viewport width. This means that zoomed content in most mobile browsers involves two-dimensional scrolling regardless of what an author does.

      +

      Mobile user agents can offer reflow when users zoom into content, as evidenced by the Dolphin browser for Android. The lack of magnified reflow support in browsers on mobile operating systems can therefore be regarded as a user agent support issue.

      - +
      -

      Specific Benefits of Success Criterion 1.4.10

      +

      Benefits

        -
      • One column view in responsive design
        A site uses responsive design. When a person zooms in to over 300%, the layout is reflowed to one column. The user can read the content easily and does not have to scroll sideways to read.
      • -
      • PDF offering reflow
        In a PDF created to conform to PDF/Universal Accessibility (ISO 14289), the content can be reflowed and zoomed in to make reading possible for someone with low-vision.
      • +
      • This Success Criterion helps people with low vision who require text enlargement by enabling them to read the content seamlessly, eliminating the necessity to scroll in multiple directions.
      - +

      Examples

      -
      -

      Example 1: Responsive Design

      -

      -

      Note that as the zoom percentage increases, the navigation changes first to hide options behind a "More" dropdown menu. As zooming continues, most navigation options are eventually behind a "hamburger" menu button. All the information and functionality is still available from this web page. There is no horizontal scrolling.

      -
      +
        +
      • + One column view in responsive design +

        +

        Note that as the zoom percentage increases, the navigation changes first to hide options behind a "More" dropdown menu. As zooming continues, most navigation options are eventually behind a "hamburger" menu button. All the information and functionality is still available from this web page. There is no horizontal scrolling.

        +
      • +
      • + PDF offering reflow +

        In a PDF created to conform to PDF/Universal Accessibility (ISO 14289), the content can be reflowed and zoomed in to make reading possible for someone with low-vision.

        +
      • +

      Resources

      Advisory Techniques

      -
        -
      • C34
      • -
      • CSS, Fitting images to the viewport;
      • -
      • @@ CSS, Reflowing simple data tables.
      • -
      • @@ CSS, Fitting data cells within the width of the viewport.
      • -
      • @@ Mechanism to allow mobile view at any time
      • -
      - +
        +
      • C34
      • +
      • CSS, Fitting images to the viewport;
      • +
      • CSS, Reflowing simple data tables (Potential future technique)
      • +
      • CSS, Fitting data cells within the width of the viewport (Potential future technique)
      • +
      • Mechanism to allow mobile view at any time (Potential future technique)
      • +

      Failures

      diff --git a/understanding/21/seizures-and-physical-reactions.html b/understanding/21/seizures-and-physical-reactions.html index 475c714788..431eb6ed2f 100644 --- a/understanding/21/seizures-and-physical-reactions.html +++ b/understanding/21/seizures-and-physical-reactions.html @@ -1,13 +1,11 @@ - + Understanding Seizures - +

      Understanding Seizures

      -
      SC text
      -

      Intent of Seizures

      diff --git a/understanding/21/status-messages.html b/understanding/21/status-messages.html index 6d98d7b290..f202bbd64e 100644 --- a/understanding/21/status-messages.html +++ b/understanding/21/status-messages.html @@ -1,49 +1,60 @@ - + WCAG 2.0 Understanding Page - + -

      Status Messages
      +

      Status Messages
      Understanding SC 3.2.6

      + +
      +

      In brief

      +
      +
      Goal
      Make users aware of important changes in content.
      +
      What to do
      Let assistive technology notify users about status changes that don't take focus.
      +
      Why it's important
      People who do not see messages need to be informed about them.
      +
      + +
      +

      Intent of this Success Criterion

      The intent of this Success Criterion is to make users aware of important changes in content that are not given focus, and to do so in a way that doesn't unnecessarily interrupt their work.

      The intended beneficiaries are blind and low vision users of assistive technologies with screen reader capabilities. An additional benefit is that assistive technologies for users with cognitive disabilities may achieve an alternative means of indicating (or even delaying or supressing) status messages, as preferred by the user.

      -

      The scope of this Success Criterion is specific to changes in content that involve status messages. A status message is a defined term in WCAG. There are two main criteria that determine whether something meets the definition of a status message:

      -
        +

        The scope of this Success Criterion is specific to changes in content that involve status messages. A status message is a defined term in WCAG. There are two main criteria that determine whether something meets the definition of a status message:

        +
        • the message provides information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors;
        • the message is not delivered via a change in context.
        • -
      -

      Information can be added to pages which does not meet the definition of a status message. For example, the list of results obtained from a search are not considered a status update and thus are not covered by this Success Criterion. However, brief text messages displayed about the completion or status of the search, such as "Searching...", "18 results returned" or "No results returned" would be status updates if they do not take focus. Examples of status messages are given in the section titled Status Message Examples below.

      + +

      Information can be added to pages which does not meet the definition of a status message. For example, the list of results obtained from a search are not considered a status update and thus are not covered by this Success Criterion. However, brief text messages displayed about the completion or status of the search, such as "Searching...", "18 results returned" or "No results returned" would be status updates if they do not take focus. Examples of status messages are given in the section titled Status Message Examples below.

      -

      This Success Criterion specifically addresses scenarios where new content is added to the page without changing the user's context. Changes of context, by their nature, interrupt the user by taking focus. They are already surfaced by assistive technologies, and so have already met the goal to alert the user to new content. As such, messages that involve changes of context do not need to be considered and are not within the scope of this Success Criterion. Examples of scenarios that add new content by changing the context are given in the section titled Examples of Changes That Are Not Status Messages below.

      - -
      -

      Benefits

      +

      This Success Criterion specifically addresses scenarios where new content is added to the page without changing the user's context. Changes of context, by their nature, interrupt the user by taking focus. They are already surfaced by assistive technologies, and so have already met the goal to alert the user to new content. As such, messages that involve changes of context do not need to be considered and are not within the scope of this Success Criterion. Examples of scenarios that add new content by changing the context are given in the section titled Examples of Changes That Are Not Status Messages below.

      +
      +
      +

      Benefits

        -
      • When appropriate roles or properties are assigned to status messages, the new content is spoken by screen readers in such a way as to assist blind and low vision users. Most sighted users can observe text peripherally added to the viewport. Such content provides additional information without affecting the user's current point of regard. The ability of an assistive technology to announce such new important text content allows more users to benefit from an awareness of the information in an equivalent manner.
      • -
      • Assigning proper roles or properties to status messages provides possible future uses and personalization opportunities, such as the potential to be exploited by assistive technologies created for users with some cognitive disabilities. Where page authors elect to design additions to the screen which do not change the user's context (i.e., take focus), the information is arguably of less importance than something presented using a modal dialog, which must be acknowledged by the user. As such, depending on the user's preferences, an assistive technology may choose to delay, suppress, or transform such messages so a user is not unnecessarily interrupted; or conversely the assistive technology may highlight such messages where the user finds it optimal to do so.
      • -
      -
      +
    • When appropriate roles or properties are assigned to status messages, the new content is spoken by screen readers in such a way as to assist blind and low vision users. Most sighted users can observe text peripherally added to the viewport. Such content provides additional information without affecting the user's current point of regard. The ability of an assistive technology to announce such new important text content allows more users to benefit from an awareness of the information in an equivalent manner.
    • +
    • Assigning proper roles or properties to status messages provides possible future uses and personalization opportunities, such as the potential to be exploited by assistive technologies created for users with some cognitive disabilities. Where page authors elect to design additions to the screen which do not change the user's context (i.e., take focus), the information is arguably of less importance than something presented using a modal dialog, which must be acknowledged by the user. As such, depending on the user's preferences, an assistive technology may choose to delay, suppress, or transform such messages so a user is not unnecessarily interrupted; or conversely the assistive technology may highlight such messages where the user finds it optimal to do so.
    • +

      Examples of Success Criterion 3.2.6

      -
      -

      Status Message Examples

      -
        -
      1. After a user presses a Search button, the page content is updated to include the results of the search, which are displayed in a section below the Search button. The change to content also includes the message "5 results returned" near the top of this new content. This text is given an appropriate role for a status message. A screen reader announces, "Five results returned".
      2. -
      3. After a user presses an Add to Shopping Cart button, a section of content near the Shopping Cart icon adds the text "5 items". A screen reader announces "Five items" or "Shopping cart, five items".
      4. -
      5. After a user enters incorrect text in an input called Postal Code, a message appears above the input reading "Invalid entry". The screen reader announces, "Invalid entry" or "Postal code, invalid entry".
      6. -
      7. After a user activates a process, an icon symbolizing 'busy' appears on the screen. The screen reader announces "application busy".
      8. -
      9. An application displays a progressbar to indicate the status of an upgrade. The element is assigned a suitable role. The screen reader provides intermittent announcements of the progress.
      10. -
      11. After a user submits a form, text is added to the existing form which reads, "Your form was successfully submitted." The screen reader announces the same message.
      12. -
      13. After a user unsuccessfully fills in a form because some of the data is in the incorrect format, text is added to the existing form which reads "5 errors on page". The screen reader announces the same message.
      14. -
      15. After a user puts a photo in an album in an online photo app, a snackbar displays the message "Saved in 'Wedding' album", which is also read by a screen reader.
      16. -
      +
      +

      Status Message Examples

      + +
        +
      • After a user presses a Search button, the page content is updated to include the results of the search, which are displayed in a section below the Search button. The change to content also includes the message "5 results returned" near the top of this new content. This text is given an appropriate role for a status message. A screen reader announces, "Five results returned".
      • +
      • After a user presses an Add to Shopping Cart button, a section of content near the Shopping Cart icon adds the text "5 items". A screen reader announces "Five items" or "Shopping cart, five items".
      • +
      • After a user enters incorrect text in an input called Postal Code, a message appears above the input reading "Invalid entry". The screen reader announces, "Invalid entry" or "Postal code, invalid entry".
      • +
      • After a user activates a process, an icon symbolizing 'busy' appears on the screen. The screen reader announces "application busy".
      • +
      • An application displays a progressbar to indicate the status of an upgrade. The element is assigned a suitable role. The screen reader provides intermittent announcements of the progress.
      • +
      • After a user submits a form, text is added to the existing form which reads, "Your form was successfully submitted." The screen reader announces the same message.
      • +
      • After a user unsuccessfully fills in a form because some of the data is in the incorrect format, text is added to the existing form which reads "5 errors on page". The screen reader announces the same message.
      • +
      • After a user puts a photo in an album in an online photo app, a snackbar displays the message "Saved in 'Wedding' album", which is also read by a screen reader.
      • +

      Examples of Status Messages that Do Not Add New Text to the Screen

      @@ -75,8 +86,8 @@

      Non-textual status content

      -
      -

      Examples of Changes That Are Not Status Messages

      +
      +

      Examples of Changes That Are Not Status Messages

      The following examples identify situations where no additional author action is necessary. All cases are excepted from this Success Criterion since they do not meet the definition of "status messages."

        @@ -89,20 +100,18 @@

        Examples of Changes That Are Not Status Messages

      • -

        After a user completes an input that indicates they are unhappy, a series of new inputs are added to the page about customer satisfaction.

        +

        After a user completes a survey question which indicates they are unhappy, a series of new questions are added to the page about customer satisfaction.

        The new inputs do not meet the definition of status message. They do not "provide information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process or on the existence of errors," and so are not required to meet this Success Criterion.

        -

        Creating a status message about these inputs being added, or notifying the user in advance that content changes may take place based on the user's response, are best practices but are not requirements in this scenario.

        +

        Creating a status message about these questions being added, or notifying the user in advance that content changes may take place based on the user's response, are best practices but are not requirements in this scenario.

      -

      Other uses of live regions

      +

      Other uses of live regions or alerts

      -

      There are a number of considerations for content changes which are relevant to this Success Criterion, but which fall outside its scope. There are a number of situations where a short off screen message may be appropriate for screen reader users. For example:

      -
      • A form field asks “How many children do you have?” and when the user responds with the number 5, five 'child name' fields are added to the form. Offscreen text may announce “5 form fields added”
      • -
      • A list of 15 products are on a page with a “See More” button at the bottom. When the user clicks the button, offscreen text announces, “15 products added to the page”
      -

      Several Advisory Techniques are incorporated into this Understanding document.

      +

      Live regions and alerts can be usefully applied in many situations where a change of content takes place which does not constitute a status message, as defined in this Success Criterion. However, there is a risk of making an application too "chatty" for a screen reader user. User testing should be carried out to ensure the appropriate level of feedback is achieved. The Advisory Techniques provide examples of how alerts or live regions can enhance the user experience.

      +

      The purpose of this success criterion is not to force authors to generate new status messages. Its intent is to ensure that when status messages are displayed, they are programmatically identified in a way that allows assistive technologies to present them to the user.

      @@ -116,9 +125,9 @@

      Sufficient

      Situation A: If a status message advises on the success or results of an action, or the state of an application:

      @@ -160,19 +169,19 @@

      Situation C: If a status message conveys information on the progress of a pr

      Advisory

      Failure

        +
      • F103
      • Using role="alert" or aria-live="assertive" on content which is not important and time-sensitive (future link)
      • -
      • Using a visibilitychange event to hide or display a document without switching the document's live regions between active and inactive (future link)
      diff --git a/understanding/21/target-size-enhanced.html b/understanding/21/target-size-enhanced.html index 8b7e7f8e5a..6690225d7c 100644 --- a/understanding/21/target-size-enhanced.html +++ b/understanding/21/target-size-enhanced.html @@ -1,84 +1,110 @@ - - WCAG 2.0 Understanding Page - + + Understanding Target Size (Enhanced) + -

      Understanding SC 2.5.4 Target Size (Enhanced)

      -
      -

      Intent

      -

      The intent of this success criterion is to help users who may have trouble activating a small target because of hand tremors, limited dexterity or other reasons. If the target is too small, it may be difficult to aim at the target. Mice and similar pointing devices can be hard to use for these users, and a larger target will help them greatly in having positive outcomes on the web page.

      -

      Touch is particularly problematic as it is an input mechanism with coarse precision. Users lack the same level of fine control as on inputs such as a mouse or stylus. A finger is larger than a mouse pointer, and generally obstructs the user's view of the precise location on the screen that is being touched/activated.

      -

      The issue can be further complicated on for responsive/mobile which need to accommodate different types of fine and coarse inputs (e.g. a site that can be accessed both on a traditional desktop/laptop with a mouse, as well as on a tablet or mobile phone with a touch screen).

      -

      While this criterion defines a minimum target size, it is recommended that larger sizes are used to reduce the possibility of unintentional actions. This is particularly relevant if any of the following are true:

      -
        -
      • the control is used frequently;
      • -
      • the result of the interaction cannot be easily undone;
      • -
      • the control is positioned where it will be difficult to reach, or is near the edge of the screen;
      • -
      • the control is part of a sequential task.
      • -
      -
      -

      Benefits

      -
        -
      • Users who use a mobile device where touch screen is the primary mode of interaction
      • -
      • Users with mobility impairments, such as hand tremors
      • -
      • Users who find fine motor movements difficult
      • -
      • Users who access a device using one hand
      • -
      • Users with large fingers, or who are operating the device with only a part of their finger or knuckle
      • -
      • Users who have low vision may better see the target
      • -
      -
      +

      Understanding SC 2.5.5 Target Size (Enhanced)

      +
      +

      In brief

      +
      +
      Goal
      Controls can be operated more easily, especially on touch screens.
      +
      What to do
      Make custom targets at least 44 by 44 pixels.
      +
      Why it's important
      Some people cannot tap small objects.
      +
      +
      +
      +

      Intent

      +

      The intent of this success criterion is to help users who may have trouble activating a small target because of hand tremors, limited dexterity or other reasons. If the target is too small, it may be difficult to aim at the target. Mice and similar pointing devices can be hard to use for these users, and a larger target will help them greatly in having positive outcomes on the web page.

      +

      Touch is particularly problematic as it is an input mechanism with coarse precision. Users lack the same level of fine control as on inputs such as a mouse or stylus. A finger is larger than a mouse pointer, and generally obstructs the user's view of the precise location on the screen that is being touched/activated.

      +

      The issue can be further complicated for responsive/mobile sites which need to accommodate different types of fine and coarse inputs (e.g. a site that can be accessed both on a traditional desktop/laptop with a mouse, as well as on a tablet or mobile phone with a touch screen).

      +

      While this criterion defines a minimum target size, it is recommended that larger sizes are used to reduce the possibility of unintentional actions. This is particularly relevant if any of the following are true:

      +
        +
      • the control is used frequently;
      • +
      • the result of the interaction cannot be easily undone;
      • +
      • the control is positioned where it will be difficult to reach, or is near the edge of the screen;
      • +
      • the control is part of a sequential task.
      • +
      +

      The targets on a screen can have different purposes and uses, and this Success Criterion specifies how each is to be handled.

      +

      Equivalent targets: If there is more than one target on a screen that performs the same action, only one of the targets need to meet the target size of 44 by 44 CSS pixels.

      +

      Inline: Content displayed can often be reflowed based on the screen width available. This is known as responsive design and makes it easier to read since you do not need to scroll both horizontally and vertically. In reflowed content, the targets can appear anywhere on a line and can change position based on the width of the available screen. Since targets can appear anywhere on the line, the size cannot be larger than the available text and spacing between the sentences or paragraphs, otherwise the targets could overlap. It is for this reason targets which are contained within one or more sentences are excluded from the target size requirements.

      +
      +

      If the target is the full sentence and the sentence is not in a block of text, then the target needs to be at least 44 by 44 CSS pixels.

      +
      +
      +

      A footnote or an icon within or at the end of a sentence is considered to be part of a sentence and therefore are excluded from the minimum target size.

      +
      +

      User Agent Control: If the size of the target is not modified by the author through CSS or other size properties, then the target does not need to meet the target size of 44 by 44 CSS pixels.

      +

      Essential: If the target is required to be a particular target size and cannot be provided in another way, while changing it would essentially change the information or functionality of the content, then the target does not need to meet the target size of 44 by 44 CSS pixels.

      -
      -

      Examples

      -
        -
      • Example 1: Buttons
        - Three buttons are on-screen and the touch target area of each button is 44 by 44 CSS pixels.
      • +
        +

        Benefits

        +
          +
        • Users who use a mobile device where touch screen is the primary mode of interaction
        • +
        • Users with mobility impairments, such as hand tremors
        • +
        • Users who use a mobile device in environments where they are exposed to shaking such as public transportation
        • +
        • Users who find fine motor movements difficult
        • +
        • Users who access a device using one hand
        • +
        • Users with large fingers, or who are operating the device with only a part of their finger or knuckle
        • +
        • Users who have low vision may better see the target
        -
        -
        -
        -

        Resources

        -

        - -
        -
        -

        Techniques

        -

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

        -
        -

        Sufficient

        -

        Techniques that are sufficient to meet the Guideline or Success Criterion.

        -
        -
          -
        • Ensuring that touch targets are at least 44 by 44 CSS pixels.
        • -
        • Ensuring inline links provide sufficiently large activation target.
        • -
        -
        -
        -
        -

        Advisory

        -

        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.

        -
          -
        • none documented
        • -
        -
        -
        -

        Failure

        -

        The following are common mistakes that are considered failures of Success Criterion 2.5.3 by the WCAG Working Group.

        -
          -
        • Failure of success criterion 2.5.3 and 2.5.4 due to touch target being less than 44 by 44 CSS pixels.
        • -
        -
        -
        - +
      +
      +

      Examples

      +
      +
      Example 1: Buttons
      +
      Three buttons are on-screen and the touch target area of each button is 44 by 44 CSS pixels.
      +
      Example 2: Equivalent target
      +
      Multiple targets are provided on the page that perform the same function. One of the targets is 44 by 44 CSS pixels. The other targets do not have a minimum touch target of 44 by 44 CSS pixels.
      +
      Example 3: Anchor Link
      +
      The target is an in-page link and the target is less than 44 by 44 CSS pixels.
      +
      Example 4: Text Link in a paragraph
      +
      Links within a paragraph of text have varying touch target dimensions. Links within + paragraphs of text do no need to meet the 44 by 44 CSS pixels requirements.
      +
      Example 5: Text Link in a sentence
      +
      A text link that is in a sentence is excluded and does not need to meet the 44 by 44 CSS pixel requirement. If the text link is the full sentence, then the text link target touch area does need to meet the 44 by 44 CSS pixels.
      +
      Example 6: Footnote
      +
      A footnote link at the end of a sentence does not need to meet the 44 by 44 CSS pixels requirements. The footnote at the end of the sentence is considered to be part of the sentence.
      +
      Example 7: Help icon
      +
      A help icon within or at the end of a sentence does not need to meet the 44 by 44 CSS pixels requirements. The icon at the end of the sentence is considered to be part of the sentence.
      +
      +
      +
      +

      Resources

      + +
      +
      +

      Techniques

      +

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

      +
      +

      Sufficient

      +
      +
        +
      • Ensuring that targets are at least 44 by 44 CSS pixels.
      • +
      +
      +
      +
      +

      Advisory

      +
        +
      • Ensuring inline links provide sufficiently large activation target.
      • +
      +
      +
      +

      Failure

      +
        +
      • Failure of Success Criterion 2.5.5 due to target being less than 44 by 44 CSS pixels.
      • +
      +
      +
      + diff --git a/understanding/21/target-size.html b/understanding/21/target-size.html deleted file mode 100644 index 1481b2acb1..0000000000 --- a/understanding/21/target-size.html +++ /dev/null @@ -1,98 +0,0 @@ - - - - - WCAG 2.0 Understanding Page - - - -

      Understanding SC 2.5.3 Target Size

      -
      -

      Intent

      -

      The intent of this success criteria is to ensure that target sizes are large enough for users to easily activate them, even if the user is accessing content on a small handheld touch screen device, has limited dexterity, or has trouble activating small targets for other reasons. For instance, mice and similar pointing devices can be hard to use for these users, and a larger target will help them activate the target.

      -

      Touch is particularly problematic as it is an input mechanism with coarse precision. Users lack the same level of fine control when using inputs such as a mouse or stylus. A finger is larger than a mouse pointer, and generally obstructs the user's - view of the precise location on the screen that is being touched/activated.

      -

      The issue can even be further complicated with responsive layouts on small screens like mobile, which need to accommodate different types of fine and coarse inputs. Both input types must be supported for a site that can be accessed both on a traditional - desktop/laptop with a mouse, as well as on a tablet or mobile phone with a touch screen.

      -

      While this criterion defines a minimum target size, as a best practice it is recommended that larger sizes are used to reduce the possibility of unintentional activations. This is particularly relevant if any of the following are true:

      -
        -
      • A control is used frequently;
      • -
      • Results of the interaction cannot be easily undone;
      • -
      • The control is positioned where it will be difficult to reach, e.g. is near the edge of the screen;
      • -
      • The control is part of a sequential task.
      • -
      -

      The targets on a screen can have different purposes and uses, and this Success Criterion specifies how each is to be handled.

      -

      Equivalent targets: If there is more than one target on a screen that performs the same action, only one of the targets need to meet the target size of 44 by 44 CSS pixels.

      -

      Inline: Content displayed can often be reflowed based on the screen width available. This is known as responsive design and makes it easier to read since you do not need to scroll both horizontally and vertically. In reflowed content, - the targets can appear anywhere on a line and can change position based on the width of the available screen. Since targets can appear anywhere on the line, the size cannot be larger than the available text and spacing between the sentences or paragraphs, - otherwise the targets could overlap. It is for this reason targets which are contained within one or more sentences are excluded from the target size requirements.

      -

      If the target is the full sentence and the sentence is not in a block of text, then the target needs to be at least 44 by 44 CSS pixels.

      -

      A footnote or an icon within or at the end of a sentence is considered to be part of a sentence and therefore are excluded from the minimum target size.

      -

      User Agent Control: If the size of the target is not modified by the author through CSS or other size properties, then the target does not need to meet the target size of 44 by 44 CSS pixels.

      -

      Essential: If the target is required to be a particular target size and cannot be provided in another way, while changing it would essentially change the information or functionality of the content, then the target does not need to - meet the target size of 44 by 44 CSS pixels.

      -
      -

      Benefits

      -
        -
      • Users who use a mobile device where touch screen is the primary mode of interaction;
      • -
      • Users with mobility impairments such as hand tremors;
      • -
      • Users who use a mobile device in environments where they are exposed to shaking such as public transportation;
      • -
      • Users who have difficulty with fine motor movements;
      • -
      • Users who access a device using one hand;
      • -
      • Users with large fingers, or who are operating the device with only a part of their finger or knuckle;
      • -
      • Users who have low vision may better see the target.
      • -
      -
      -
      -
      -

      Examples

      -
        -
      • Example 1: Buttons
        Three buttons are on-screen and the touch target area of each button is 44 by 44 CSS pixels.
      • -
      • Example 2: Equivalent target
        Multiple targets are provided on the page that perform the same function. One of the targets is 44 by 44 CSS pixels. The other targets do not have a minimum touch target of 44 by 44 CSS pixels.
      • -
      • Example 3: Anchor Link
        The target is an in-page link and the target is less than 44px by 44px. Users can scroll the screen using browser functions so target size does not need to be met.
      • -
      • Example 4: Text Link in a paragraph
        Links within a paragraph of text have varying touch target dimensions. Links within paragraphs of text do no need to meet the 44 by 44 CSS pixels requirements.
      • -
      • Example 5: Text Link in a sentence
        A text link that is in a sentence is excluded and does not need to meet the 44 by 44 CSS pixel requirement. If the text link is the full sentence, then the text link target touch area does - need to meet the 44 x 44 CSS pixels.
      • -
      • Example 6: Footnote
        A footnote link at the end of a sentence does not need to meet the 44 by 44 CSS pixels requirements. The footnote at the end of the sentence is considered to be part of the sentence.
      • -
      • Example 7: Help icon
        A help icon within or at the end of a sentence does not need to meet the 44 by 44 CSS pixels requirements. The icon at the end of the sentence is considered to be part of the sentence.
      • -
      -
      -
      -
      -

      Resources

      -

      - -
      -
      -

      Techniques

      -
      -

      Sufficient

      -
        -
      • Ensuring that touch targets are at least 44 by 44 CSS pixels.
      • -
      • Providing a mechanism to change the size of the target independent of magnification.
      • -
      -
      -
      -

      Advisory

      -
        -
      • Ensuring inline links provide sufficiently large activation target.
      • -
      -
      -
      -

      Failure

      -
        -
      • Failure of success criterion 2.5.3 due to target size being less than 44 by 44 CSS pixels.
      • -
      • Failure of success criterion 2.5.3 due to target size of a paragraph that is also a link being less than 44 x 44 CSS pixels.
      • -
      -
      -
      - - diff --git a/understanding/21/text-spacing.html b/understanding/21/text-spacing.html index 9ca0d22baf..77b6c1f708 100644 --- a/understanding/21/text-spacing.html +++ b/understanding/21/text-spacing.html @@ -1,147 +1,170 @@ - - - Understanding Text Spacing - - - -

      Understanding Text Spacing

      -
      -

      Intent

      -

      The intent of this Success Criterion (SC) is to ensure that people can override text spacing to improve their reading experience. Each of the requirements stipulated in the SC's four bullets helps ensure text styling can be adapted by the user to suit their needs.

      -

      This SC focuses on the ability to increase spacing between lines, words, letters, and paragraphs. Any combination of these may assist a user with effectively reading text. As well, ensuring users can override author settings for spacing also signficantly increases the likelihood other style preferences can be set by the user. For example, a user may need to change to a wider font family than the author has set in order to effectively read text.

      -
      -

      Author Responsibility

      -

      This SC does not dictate that authors must set all their content to the specified metrics. Rather, it specifies that an author's content has the ability to be set to those metrics without loss of content or functionality. The author requirement is both to not interfere with a user's ability to override the author settings, and to ensure that content thus modified does not break content in the manners shown in figures 1 through 4 in Effects of Not Allowing for Spacing Override.

      -
      -

      Applicability

      -

      If the markup-based technologies being used are capable of overriding text to the Success Criterion's metrics, then this SC is applicable. For instance Cascading Style Sheet/HTML technologies are quite able to allow for the specified spacing metrics. Plugin technologies would need to have a built-in ability to modify styles to the specified metrics. Currently, this SC does not apply to PDF as it is not implemented using markup.

      -

      Examples of text that are typically not affected by style properties and not expected to adapt are:

      -
        -
      • Video captions embedded directly into the video frames and not provided as an associated caption file
      • -
      • Images of text
      • -
      -

      For this SC, canvas implementations of text are considered to be images of text.

      -
      -
      -
      -

      User Responsibility

      -

      The ability to read and derive meaning from the overridden spacing rests with the user. If the increased spacing impacts those abilities, the user will adjust or they will return to the default view. Regardless, the user needs the flexibility to adjust spacing within the bounds set in the SC. Such changes may be acheived via user stylesheet, bookmarklet, extension, or application.

      -
      + + + Understanding Text Spacing + + + +

      Understanding Text Spacing

      +
      +

      In brief

      +
      +
      Goal
      Users can adjust text spacing to make it easier to read.
      +
      Author task
      Ensure content adapts to user-defined text settings.
      +
      Why it's important
      Some people need text with different spacing or font characteristics.
      +
      +
      +
      +

      Intent

      +

      The intent of this Success Criterion (SC) is to ensure that when people override author specified text spacing to improve their reading experience, content is still readable and operable. Each of the requirements stipulated in the SC's four bullets helps ensure text styling can be adapted by the user to suit their needs.

      +

      The specified metrics set a minimum baseline. The values in between the author's metrics and the metrics specified in this SC should not have loss of content or functionality.

      +

      This SC focuses on the adaptability of content to an increase in spacing between lines, words, letters, and paragraphs. Any combination of these may assist a user with effectively reading text. As well, ensuring that content correctly adapts when users override author settings for spacing also significantly increases the likelihood other style preferences can be set by the user. For example, a user may need to change to a wider font family than the author has set in order to effectively read text.

      +
      +

      Author Responsibility

      +

      This SC does not dictate that authors must set all their content to the specified metrics, nor does the SC intend to imply that all users will adjust the specified metrics. Rather, it specifies that should a user choose to set any of these metrics they can do so without any loss of content or functionality. The author requirement is both to not interfere with a user's ability to override the author settings, and to ensure that content thus modified does not break content in the manners shown in figures 1 through 3 in Effects of Not Allowing for Spacing Override.

      -
      -

      Effects of Not Allowing for Spacing Override

      -

      The following images show some types of failures when authors do not take into consideration that users may override spacing to the metrics specified in this Success Criterion.

      -
      -

      Text Cut Off

      -

      The bottom portion of the words "Your Needs" is cut off in a heading making that text unreadable in Figure 1. It should read "We Provide a Mobile Application Service to Meet Your Needs."

      -
      -
      Figure 1: Vertical text cut off is a failure.
      - Heading text truncated vertically. -
      -

      In Figure 2 the last portion of text is cut off in 3 side-by-side headings. The 1st heading should read "A cog in the wheel." But it reads "A cog in the whe". Only half of the second "e" is visible and the letter "l" is completely missing. The 2nd heading should read "A penny for your thoughts". But it reads "A penny for your". The 3rd should read "Back to the drawing board." But it reads "Back to the drawi".

      -
      -
      Figure 2: Horizontal text cut off is a failure.
      - 3 side-by-side headings with truncated text. -
      -
      -
      -

      Text Overlap

      -

      In Figure 3 the last 3 words "Groups and Programs" of the heading "Technologists Seeking Input from Groups and Programs" overlap the following sentence. That sentence should read, "You are invited to share ideas and areas of interest related to the integration of technology from a group or program perspective." But the words "You are invited to share ideas" are obscured and unreadable.

      -
      -
      Figure 3: Overlapping text is a failure.
      - Heading text overlaps part of paragraph text. -
      -
      -
      - +

      In some human languages and scripts, some of the metrics specified by the SC are inapplicable. For example, languages such as Japanese do not use spacing following paragraphs, meaning that users are unlikely to make any paragraph spacing changes in practice. The exception in this SC allows authors to ignore text style properties which are inapplicable to the combination of language and script being used.

      + +

      It is beneficial for users if authors use any locally available guidance for improving readability in the local language or writing system. If the user chooses to go beyond the metrics specified, any resulting loss of content or functionality is the user's responsibility.

      + +

      Further, this SC is not concerned with how users change the line height and spacing metrics. It does not require that content implement its own mechanisms to allow users to do this. It is not a failure of the content if a user agent or platform does not provide a way for users to do this. Content does not fail this SC if the method chosen by the user - for instance, the use of an extension or bookmarklet - fails to correctly set the line height and spacing text properties on the content (provided that the content is not actively and purposely preventing the properties from being added).

      +
      +

      Applicability

      +

      If the markup-based technologies being used are capable of overriding text to the Success Criterion's metrics, then this SC is applicable. For instance Cascading Style Sheet/HTML technologies are quite able to allow for the specified spacing metrics. Plugin technologies would need to have a built-in ability to modify styles to the specified metrics. Currently, this SC does not apply to PDF as it is not implemented using markup.

      +

      Examples of text that are typically not affected by style properties and not expected to adapt are:

      +
        +
      • Video captions embedded directly into the video frames and not provided as an associated caption file
      • +
      • Images of text
      • +
      +

      For this SC, canvas implementations of text are considered to be images of text.

      + +
      +
      +

      Use of ellipses

      +

      There may be regions of a page where text containers cannot expand due to design constraints (such as a maximum width for the left navigation or table column headers). A common convention if text exceeds its space is to replace truncated text with an ellipsis. Where ellipses appear as a result of modifying text style properties, the page can still meet the Text Spacing requirements, so long as the content is still available. For example:

      +
        +
      • a mechanism is provided to reveal the truncated text on the page (for instance, the text appears on focus or on activation)
      • +
      • where the ellipsis is part of a section of content which includes a link, the truncated text is revealed on the linked page
      • +
      +

      Where text is not truncated but it is when text is spaced, if there is no mechanism to show the truncated text, it fails this Success Criterion.

      -
      -

      Benefits

      -
        -
      • People with low vision who require increased space between lines, words, and letters are able to read text.
      • -
      • People with dyslexia may increase space between lines, words, and letters to increase reading speed.
      • -
      • Although not required by this SC, white space between blocks of text can help people with cognitive disabilities discern sections and call out boxes.
      • -
      -
      -
      -

      Examples

      -

      When spacing is be overridden to the SC's metrics:

      -
        -
      1. Text fits within the bounds of its containing box without being cut off.
      2. -
      3. Text fits within the bounds of its containing box without overlapping other boxes.
      4. -
      +
      +
      +

      User Responsibility

      +

      The ability to read and derive meaning from the overridden spacing rests with the user. The user may choose to exceed the spacing adjustments in the SC. If the increased spacing causes loss of content or functionality, the user will adjust or return to the author’s original spacing or spacing within the bounds of the SC. Regardless, the user needs the flexibility to adjust spacing within the bounds set in the SC without loss of content or functionality. Such changes may be achieved via user stylesheet, bookmarklet, extension, or application.

      +
      + +
      +

      Effects of Not Allowing for Spacing Override

      +

      The following images show some types of failures when authors do not take into consideration that users may override spacing to the metrics specified in this Success Criterion.

      +
      +

      Text Cut Off

      +

      The bottom portion of the words "Your Needs" is cut off in a heading making that text unreadable in Figure 1. It should read "We Provide a Mobile Application Service to Meet Your Needs."

      +
      +
      Vertical text cut off is a failure.
      + Heading text truncated vertically. +
      +

      In Figure 2 the last portion of text is cut off in 3 side-by-side headings. The 1st heading should read "A cog in the wheel." But it reads "A cog in the whe". Only half of the second "e" is visible and the letter "l" is completely missing. The 2nd heading should read "A penny for your thoughts". But it reads "A penny for your". The 3rd should read "Back to the drawing board." But it reads "Back to the drawi".

      +
      +
      Horizontal text cut off is a failure.
      + 3 side-by-side headings with truncated text. +
      +
      +
      +

      Text Overlap

      +

      In Figure 3 the last 3 words "Groups and Programs" of the heading "Technologists Seeking Input from Groups and Programs" overlap the following sentence. That sentence should read, "You are invited to share ideas and areas of interest related to the integration of technology from a group or program perspective." But the words "You are invited to share ideas" are obscured and unreadable.

      +
      +
      Overlapping text is a failure.
      + Heading text overlaps part of paragraph text. +
      -
      -

      Resources

      -
      -

      Research

      -

      The grounds for this SC are based on research. The metrics chosen as measures are based on the McLeish study. She ran from .04 to .25 em tests. McLeish found an increasing curve in reading speed of actual materials up to .25, but it started to flatten at .20. Previous studies that reported no improvement started at .5em. Right at the flat point. Wayne E. Dick, Ph.D. analyzed the McLeish study and translated from points. Dr. Dick recommended the metrics that the Working Group adopted.

      -
      -

      Languages and Scripts

      -

      Roughly 480 different languages and scripts have been tested. Maximum spacing adjustments allowed by the SC were set on the following 3 pages:

      -
        -
      1. Languages in their own writing systems
      2. -
      3. Online Encyclopedia of writing systems and languages – language names
      4. -
      5. Universal Declaration of Human Rights (Article 1)
      6. -
      -
      -
      -

      Results

      -

      No adverse effects occurred. The following are the specific findings:

      -
      -
      Character Spacing
      -
      Individual characters in words remained intact though they were spaced a bit further apart.
      -
      Word Spacing
      -
      Words were spaced farther apart. In languages that do not have words (e.g. Japanese) applying word spacing had no effect. This is expected.
      -
      Line Height
      -
      Changing line height did not separate diacritics from characters, nor did it adversely impact ascenders or descenders.
      -
      -

      As previously discussed, the ability to read text with adjusted spacing is a user responsibility. This is true no matter the language.

      -

      The SC's exception addresses cases where a text style property is not used in a language or script. In such cases, authors are only required to ensure relevant properties do not break the layout.

      -
      -
      -
      -

      Other references

      - -
      +
      +
      +
      +

      Benefits

      +
        +
      • People with low vision who require increased space between lines, words, and letters are able to read text.
      • +
      • People with dyslexia may increase space between lines, words, and letters to increase reading speed.
      • +
      • Although not required by this SC, white space between blocks of text can help people with cognitive disabilities discern sections and call out boxes.
      • +
      +
      +
      +

      Examples

      +

      When spacing is being overridden to the SC's metrics:

      +
        +
      • Text fits within the bounds of its containing box without being cut off.
      • +
      • Text fits within the bounds of its containing box without overlapping other boxes.
      • +
      +
      +
      +

      Resources

      +
      +

      Research

      +

      The grounds for this SC are based on research. The metrics chosen as measures are based on the McLeish study. She ran from .04 to .25 em tests. McLeish found an increasing curve in reading speed of actual materials up to .25, but it started to flatten at .20. Previous studies that reported no improvement started at .5em. Right at the flat point. Wayne E. Dick, Ph.D. analyzed the McLeish study and translated from points. Dr. Dick recommended the metrics that the Working Group adopted.

      +
      +

      Languages and Scripts

      +

      Roughly 480 different languages and scripts have been tested. Maximum spacing adjustments allowed by the SC were set on the following 3 pages:

      +
      -
      -

      Techniques

      -
      -

      Sufficient

      - -
      -
      -

      Advisory

      - -
      -
      -

      Failure

      -
        -
      • Failure of Success Criterion 1.4.12 due to not allowing for spacing override. (Future technique)
      • -
      -
      +
      +

      Results

      +

      No adverse effects occurred. The following are the specific findings:

      +
      +
      Character Spacing
      +
      Individual characters in words remained intact though they were spaced a bit further apart.
      +
      Word Spacing
      +
      Words were spaced farther apart. In languages that do not have words (e.g. Japanese) applying word spacing had no effect. This is expected.
      +
      Line Height
      +
      Changing line height did not separate diacritics from characters, nor did it adversely impact ascenders or descenders.
      +
      +

      As previously discussed, the ability to read text with adjusted spacing is a user responsibility. This is true no matter the language.

      +

      The SC's exception addresses cases where a text style property is not used in a language or script. In such cases, authors are only required to ensure relevant properties do not break the layout.

      +
      +
      +
      +

      Other references

      + +
      +
      +
      +

      Techniques

      +
      +

      Sufficient

      + +
      - +
      +

      Advisory

      + +
      +
      +

      Failure

      +
        +
      • +
      +
      +
      + diff --git a/understanding/21/timeouts.html b/understanding/21/timeouts.html index 67c25421db..698906c613 100644 --- a/understanding/21/timeouts.html +++ b/understanding/21/timeouts.html @@ -1,21 +1,32 @@ - + WCAG 2.0 Understanding Page - +

      Understanding Timeouts

      + +
      +

      In brief

      +
      +
      Goal
      Users do not lose data due to unknown timeouts.
      +
      Author task
      Tell users how long their session can be inactive before they may lose information.
      +
      Why it's important
      People with disabilities may need more time to complete actions.
      +
      + +
      +

      Intent

      The intent of this Success Criterion is to ensure that when a timeout is used, users know what duration of inactivity will cause the page to time out and result in lost data. The use of timed events can present significant barriers for users with cognitive disabilities, as these users may require more time to read content or to perform functions, such as completing an online form.

      During the completion of an online process, such as to reserve a hotel room or purchase a plane ticket, a user with a cognitive impairment may become overwhelmed with lengthy instructions and data input required to complete the process. The user may not be able to complete the process in one sitting and may need to take a break. Users should be able to leave a process without losing their current place within the process, and without losing information that has already been entered. If users cannot take a break and check their work, many will often be unable to complete a task correctly.

      -

      This Success Criterion works in tandem with Success Criterion 2.2.1 Timing Adjustable, but is specifically focused on notification of timeouts related to user inactivity.

      -

      The best way to conform to this success criteria is to keep the user data for at least 20 hours. This enables the user with disabilities and the aging community to start and finish a task, taking breaks as needed. However, when it is not practical to save the user data the author must warn the user about the duration of inactivity which will result in a timeout. Timeouts should be displayed to the user once at the beginning of the related task or process and not at each step.

      -

      This success criterion only applies to timeouts that are within the content provider's knowledge or control. For example, if the user closes a web browser or device and loses content in an open page that has not yet been submitted, the success criteria has not been violated.

      - -
      +

      This Success Criterion works in tandem with Success Criterion 2.2.1 Timing Adjustable, but is specifically focused on notification of timeouts related to user inactivity.

      +

      The best way to conform to this success criterion is to keep the user data for at least 20 hours. This enables the user with disabilities and the aging community to start and finish a task, taking breaks as needed. However, when it is not practical to save the user data the author must warn the user about the duration of inactivity which will result in a timeout. Timeouts should be displayed to the user once at the beginning of the related task or process and not at each step.

      +

      This success criterion only applies to timeouts that are within the content provider's knowledge or control. For example, if the user closes a web browser or device and loses content in an open page that has not yet been submitted, the success criterion has not been violated.

      +

      Examples of privacy regulations mentioned in the Success Criterion note, and related compliance standards, are PCI DSS (Payment Card Industry Data Security Standard) and HIPAA (Health Insurance Portability and Accountability Act of 1996).

      +

      Benefits

      This Success Criterion helps users by ensuring they are notified about timeouts related to inactivity.

      diff --git a/understanding/22/accessible-authentication-enhanced.html b/understanding/22/accessible-authentication-enhanced.html new file mode 100644 index 0000000000..978c7385dd --- /dev/null +++ b/understanding/22/accessible-authentication-enhanced.html @@ -0,0 +1,116 @@ + + + + + Understanding Accessible Authentication (Enhanced) + + + +

      Understanding Accessible Authentication (Enhanced)

      + +
      +

      In brief

      +
      +
      Goal
      Make logins possible with less mental effort.
      +
      What to do
      Don't make people recognize objects or user-supplied images and media to login.
      +
      Why it's important
      Some people with cognitive disabilities can't do puzzles, including identifying objects and non-text information they previously supplied.
      +
      +
      + +
      +

      Intent of Accessible Authentication (Enhanced)

      + +

      The purpose of this Success Criterion is to ensure there is an accessible, easy-to-use, and secure method to log in, access content, and undertake tasks. This criterion is the same as Accessible Authentication (Minimum) but without the exceptions for objects and user-provided content.

      + +

      Any required step of the authentication process:

      +
        +
      • cannot display a selection of images, videos, or audio clips, where users must choose which image they provided;
      • +
      • cannot display a selection of images, where users must choose the images which contain a specific object, such as a car.
      • +
      + +
      +
      +

      Benefits of Accessible Authentication (Enhanced)

      + +

      The benefits of this Success Criterion are the same as Accessible Authentication (Minimum).

      + +

      People with cognitive issues relating to memory, reading (for example, dyslexia), numbers (for example, dyscalculia), or perception-processing limitations will be able to authenticate irrespective of the level of their cognitive abilities.

      + +
      + +
      +

      Examples of Accessible Authentication (Enhanced)

      + +

      The examples of this Success Criterion are very similar to the Accessible Authentication (Minimum) examples.

      + +
        +
      • A web site uses a properly marked up username (or email) and password fields as the login authentication (meeting Success Criterion 1.3.5 Input Purpose and Success Criterion 4.1.2: Name, Role, Value). The user's browser or integrated third-party password manager extension can identify the purpose of the inputs and automatically fill in the username and password.
      • +
      • A web site does not block paste functionality. The user is able to use a third-party password manager to store credentials, copy them, and paste them directly into a login form.
      • +
      • A web site uses WebAuthn so the user can authenticate with their device instead of username/password. The user's device could use any available modality. Common methods on laptops and phones are facial-scan, fingerprint, and PIN (Personal Identification Number). The web site is not enforcing any particular use; it is assumed a user will set up a method that suits them.
      • +
      • A web site offers the ability to login with a third-party provider using the OAuth method.
      • +
      • A web site that requires two-factor authentication allows for multiple options for the 2nd factor, including a USB-based method where the user simply presses a button to enter a time-based token.
      • +
      • A web site that requires two-factor authentication displays a QR code which can be scanned by an app on a user's device to confirm identity.
      • +
      • A web site that requires two-factor authentication sends a notification to a user's device. The user must use their device's authentication mechanism (for example, user-defined PIN, fingerprint, facial recognition) to confirm identity.
      • +
      + +
      + + +
      +

      Techniques for Accessible Authentication (Enhanced)

      + +
      +

      Sufficient Techniques

      + + +
      + +
      +

      Additional Techniques (Advisory) for Accessible Authentication (Enhanced)

      +
      + +
      +

      Failures for Accessible Authentication (Enhanced)

      + +
      + +
      +
      +

      Resources

      + + + +
      + + + diff --git a/understanding/22/accessible-authentication-minimum.html b/understanding/22/accessible-authentication-minimum.html new file mode 100644 index 0000000000..ceec50bf01 --- /dev/null +++ b/understanding/22/accessible-authentication-minimum.html @@ -0,0 +1,181 @@ + + + + + Understanding Accessible Authentication (Minimum) + + + +

      Understanding Accessible Authentication (Minimum)

      + +
      +

      In brief

      +
      +
      Goal
      Make logins possible with less mental effort.
      +
      What to do
      Don't make people solve, recall, or transcribe something to log in.
      +
      Why it's important
      Some people with cognitive disabilities cannot solve puzzles, memorize a username and password, or retype one-time passcodes.
      +
      +
      + +
      +

      Intent of Accessible Authentication (Minimum)

      + +

      The purpose of this Success Criterion is to ensure there is an accessible, easy-to-use, and secure method for users to authenticate when logging into an existing account. As the most prevalent form of authentication, Web sites commonly rely on usernames and passwords to log in. However, memorizing a username and password places a very high or impossible burden upon people with certain cognitive disabilities, as do additional steps often added to authentication processes. For instance, the need to transcribe a one-time verification code or requiring a puzzle to be solved.

      + +

      While Web sites can use the recognition of objects or of non-text content provided by the user to meet this Success Criterion, such techniques do not fully support the cognitive accessibility community and should be avoided if possible. Refer to Accessible Authentication (Enhanced) for guidance to be more inclusive and accessible.

      + +

      This Success Criterion is focused on authentication of existing users. It does not cover creation of a username or initiation of an account. For many Web sites, establishing an initial username and credentials may not differ greatly from logging in with that username. The techniques used to satisfy this criterion (particularly allowing pasting into inputs and not relying on transcription) can also reduce the cognitive burden in account creation. However, the focus of the Success Criterion is on reducing the ongoing need for users to recall previously supplied information each time they log in or otherwise authenticate to an account.

      + +
      +

      Cognitive Function Tests

      + +

      Remembering a site-specific password is a cognitive function test. Such tests are known to be problematic for many people with cognitive disabilities. Whether it is remembering random strings of characters, or a pattern gesture to perform on a touch screen, cognitive function tests will exclude some people. When a cognitive function test is used, at least one other authentication method must be available which is not a cognitive function test.

      + + +

      Some CAPTCHA systems have an audio alternative of the visible text. If the user needs to transcribe this audio, it cannot be used to meet the Alternative exception.

      + +

      If there is more than one step in the authentication process, such as with multi-factor authentication, all steps need to comply with this Success Criterion to pass. There needs to be a path through authentication that does not rely on cognitive function tests.

      + +

      Being able to recover or change the email and password is an important part of authentication. If the user is authenticating with alternative information in order to recover their account, there needs to be a method that is not a cognitive function test.

      + +

      Many organizations are required to use 2-factor authentication that combines independent sources to confirm a user's identity. These sources can consist of combining authentication through:

      + +
        +
      • knowledge (e.g., password, letters in a passphrase or memorized swipe path);
      • +
      • possession (e.g., a verification code generated or received on a device, or scanning of a QR code on an external device);
      • +
      • biometrics (e.g., fingerprint scanning, facial recognition or keystroke dynamics).
      • +
      + +

      Most knowledge-based authentication methods rely on a cognitive function test, so mechanisms to assist users must be available. When authentication relies on performing an action on a separate device, it should be possible to complete the action without the need to transcribe information. It may not be possible to know what device-based authentication methods are available to a user; offering a choice of methods can allow them to choose the path that most suits them.

      +
      + +
      +

      Authentication Approaches

      +

      Web sites can employ username (or email) and password inputs as an authentication method if the author enables the user agent (browsers and third-party password managers) to fill in the fields automatically. Generally, if the login form meets Success Criterion 1.3.5 Input Purpose, and the form controls have an appropriate accessible name in accordance with Success Criterion 4.1.2 Name, Role, Value, the user agent should be able to reliably recognize the fields and automatically fill them in. However, if the user agent is actively blocked from filling in the fields (for instance, by a script), then the page would not pass this criterion because it prevents the mechanism from working.

      +
      + +
      +

      Copy and paste

      +

      Copy and paste can be relied on to avoid transcription. Users can copy their login credentials from a local source (such as a standalone third-party password manager) and paste it into the username and password fields on a login form, or into a web-based command line interfaces asking for a password. Blocking people from pasting into authentication fields, or using a different format between the copied text and the input field (for example, "Enter the 3rd, 4th, and 6th character of your password"), would force the user to transcribe information and therefore fail this criterion, unless another method is available.

      +
      + +
      +

      Two-factor authentication systems (verification codes)

      +

      Beyond usernames and passwords, some sites may use two-factor authentication, asking the user to enter a verification code (also called a passcode or one-time password). A service that requires manual transcription of a verification code is not compliant. As with usernames and passwords, it must be possible for a user to at least paste the code (such as from a standalone third-party password manager, text message application, or software-based security key), or to allow user agents to fill in the fields automatically.

      +

      There are scenarios where a verification code must be received or generated on a secondary device. For example, authenticating in a web browser on a laptop requires a verification code that is sent as an SMS text message to a mobile phone. However, in most cases, it is possible for the code to then be sent directly to the primary device, where it can then be copied and pasted (for example, by copying the code on the secondary device and emailing it to the primary device, or through the use of a shared cross-device clipboard where copying content on the secondary device makes it available to paste on the primary device). Evaluating whether or not the code can be seamlessly transferred from the secondary device to the primary device is outside of the scope for this Success Criterion. For the purpose of evaluating Web content that relies on authentication using these types of secondary device systems, it is assumed that provisions are in place that make the code available in the user's clipboard. Evaluating this criterion therefore only requires verification that the web content does allow pasting the clipboard content in the related authentication challenge field.

      +

      Note that two-factor systems that do not rely on codes — including hardware authentication devices (such as YubiKey), secondary applications (either on the same primary device, or on a secondary device) that expect the user to confirm that it is indeed them trying to log in, and authentication methods provided by the user's operating system (such as Windows Hello, or Touch ID/Face ID on macOS and iOS) — are not a cognitive function test.

      +
      + +
      +

      Object Recognition

      +

      If a CAPTCHA is used as part of an authentication process, there must be a method that does not include a cognitive function test, unless it meets the exception. If the test is based on something the website has set such as remembering or transcribing a word, or recognizing a picture the website provided, that would be a cognitive functional test. Recognizing objects, or a picture the user has provided is a cognitive function test; however, it is excepted at the AA level.

      + +

      An object in this context means the general English definition ("a material thing that can be seen and touched") and can include vehicles and animals. If the test goes beyond recognition (e.g. multiply the number cats by the number of dogs), that does not meet the exception.

      + +

      Some forms of object recognition may require an understanding of a particular culture. For example, taxis can appear differently in different locales. This is an issue for many people, including people with disabilities, but it is not considered an accessibility-specific issue.

      + +

      Some CAPTCHAs and cognitive function tests used for authentication may only appear in certain situations, such as when ad blockers are present, or after repeated incorrect password entry. This criterion applies when these tests are used regardless of whether they are used every time or only triggered by specific scenarios.

      + +

      There are a number of technologies that can be employed to prevent scripted abuse of the authentication process.

      + + + +

      None of these systems are 100% effective. However, they may reduce the likelihood of a CAPTCHA being displayed.

      +
      + +
      +

      Personal Content

      +

      Personal content is sometimes used as a second factor for authentication. For example, as part of account creation the user would upload a picture, and when logging in they would be asked to select that picture from several possible alternatives. Care must be taken to provide adequate security in this case, since non-legitimate users might be able to guess the correct personal content when presented with a choice.

      + +

      Text-based personal content does not qualify for this exception as it relies on recall (rather than recognition), and transcription (rather than selecting an item). Whilst picture-based personal content will still be a barrier for some people, text based versions tend to be a much larger barrier.

      +
      + +
      +

      Hiding characters

      +

      Another factor that can contribute to cognitive load is hiding characters when typing. Although this criterion requires that users do not have to type in (transcribe) a password, there are scenarios where that is necessary such as creating a password to be saved by a password manager. Providing a feature to optionally show a password can improve the chance of success for some people with cognitive disabilities or those who have difficulties with accurately typing.

      +
      + + +
      +
      +

      Benefits of Accessible Authentication (Minimum)

      + +

      People with cognitive issues relating to memory, reading (for example, dyslexia), numbers (for example, dyscalculia), or perception-processing limitations will be able to authenticate irrespective of the level of their cognitive abilities.

      + +
      + +
      +

      Examples of Accessible Authentication (Minimum)

      +

      The examples of this Success Criterion are the same as the Accessible Authentication (Enhanced) examples.

      + +
        +
      • A web site uses a properly marked up username (or email) and password fields as the login authentication (meeting Success Criterion 1.3.5 Input Purpose and Success Criterion 4.1.2: Name, Role, Value). The user's browser or integrated third-party password manager extension can identify the purpose of the inputs and automatically fill in the username and password.
      • +
      • A web site does not block paste functionality. The user is able to use a third-party password manager to store credentials, copy them, and paste them directly into a login form.
      • +
      • A web site uses WebAuthn so the user can authenticate with their device instead of username/password. The user's device could use any available modality. Common methods on laptops and phones are facial-scan, fingerprint, and PIN (Personal Identification Number). The web site is not enforcing any particular use; it is assumed a user will set up a method that suits them.
      • +
      • A web site offers the ability to login with a third-party provider using the OAuth method.
      • +
      • A web site that requires two-factor authentication allows for multiple options for the 2nd factor, including a USB-based method where the user simply presses a button to enter a time-based token.
      • +
      • A web site that requires two-factor authentication displays a QR code which can be scanned by an app on a user's device to confirm identity.
      • +
      • A web site that requires two-factor authentication sends a notification to a user's device. The user must use their device's authentication mechanism (for example, user-defined PIN, fingerprint, facial recognition) to confirm identity.
      • +
      + +
      + +
      +

      Techniques for Accessible Authentication (Minimum)

      + +
      +

      Sufficient Techniques for Accessible Authentication (Minimum)

      + +
      + +
      +

      Additional Techniques (Advisory) for Accessible Authentication (Minimum)

      +
      + +
      +

      Failures for Accessible Authentication (Minimum)

      + +
      + +
      +
      +

      Resources

      + + +
      + + + diff --git a/understanding/22/consistent-help.html b/understanding/22/consistent-help.html new file mode 100644 index 0000000000..f0bb522d29 --- /dev/null +++ b/understanding/22/consistent-help.html @@ -0,0 +1,163 @@ + + + + + Understanding Consistent Help + + + +

      Understanding Consistent Help

      + +
      +

      In brief

      +
      +
      Goal
      Make it easier to find help and support.
      +
      What to do
      Put help in the same place when it is on multiple pages.
      +
      Why it's important
      People who need help can find it more easily if it's in the same place.
      +
      +
      + +
      + +

      Intent of Consistent Help

      + +

      The intent of this Success Criterion is to ensure users can find help for completing tasks on a Web site, when it is available. When the placement of the help mechanism is kept consistent across a set of pages, users looking for help will find it easier to identify. This is distinct from interface-level help, such as contextual help, features like spell checkers, and instructional text in a form.

      + +

      Locating the help mechanism in a consistent location across pages makes it easier for users to find it. For example, when a mechanism or link is located in the header of one Web page, it will be easier to find if it is in the header of other pages. The help mechanism, such as a contact phone number, may be provided directly on the page, or it may also be a direct link to a contact page. Regardless of which approach is used, the mechanism must be located in the same relative order on each page within the set of pages.

      + +

      When testing this Success Criterion, it is the help item which is relative to the rest of the content. When testing a page, other content that is present across the set of web pages and is before the help item should be before the help item on this page. Items which are after the help item on other pages should be after the help item on this page.

      + +

      If the help item is visually in a different location, but in the same serial order, that is not helpful from a user's point of view, but it would not fail this criterion.

      + +

      When having problems completing a task on a Web site (or part of a Web site, what we call a set of Web pages), people with some types of disabilities may not be able to work through the issue without further help. Issues could include difficulty: + completing a form, or finding a document or page which provides information required to complete a task.

      + +

      Without help, some users may abandon the task. They may also fail to correctly complete a task, or they may require assistance from people who do not necessarily keep private information secure.

      + +

      While it is recommended to consistently implement a help mechanism across a set of web pages, this criterion specifically pertains to pages that do include such a mechanism. Therefore, the absence of a help mechanism on certain pages within a set does not constitute a violation.

      + +
      +

      Limitations and Exceptions

      + +

      It is not the intent of this Success Criterion to require authors to provide help or access to help. The Criterion only requires that when one of the listed forms of help is available across multiple pages that it be in a consistent location. It does not require authors to provide help information on PDFs or other static documents that may be available for viewing/download from the Web pages. PDFs and other static documents are not considered part of the "set of web pages" from which they are downloaded.

      + +

      It is also not the intent of this Success Criterion to require a human be available at all times. Ideally, if the human contact is not available during certain hours or certain days then information would be provided so the user can tell when it will be available.

      + +

      This Success Criterion only requires help mechanisms to be consistent within a particular set of web pages. Some complex Web sites consist of multiple different sets of web pages with different purposes. For example, a web-based spreadsheet application might have one set of pages for editing spreadsheets and a separate set of pages for marketing the application. This Success Criterion would allow the different sets of web pages to use different help mechanism locations. However, it is best if help mechanisms are located as consistently as possible even among different related sets of web pages.

      + +

      This Success Criterion contains an exception when "a change is initiated by the user." This exception is intended to cover cases where a user performs an action with the intent of changing the display or layout of a page, such as changing the zoom level, orientation, or viewport size. Help mechanism locations may change in response to such a user-initiated change; as the criterion's second note clarifies, "this criterion is concerned with relative order across pages displayed in the same page variation (e.g., same zoom level and orientation)."

      + +

      This exception allows the location in a smaller viewport to be different than in a larger viewport. However, it is best if the mechanism or link is consistent across a set of web pages. A consistent location, both visually and programmatically, is the most usable.

      + +

      This exception is not intended to treat every action that a user might initiate as a "change"; to qualify for the exception, the user must be initiating an action that would reasonably be expected to change the relative order of components within a page. For example, merely navigating between pages within a set of web pages is not a "change initiated by the user" for the purposes of this exception. Similarly, logging into or out of a page would not typically qualify, unless logging in would present the user with a distinct set of web pages.

      +
      + +
      +

      Help Mechanisms

      + +

      Typical help mechanisms include:

      +
        +
      • Human contact details such as a phone number, email address, hours of operation.
      • +
      • Human contact mechanism such as a messaging system, chat client, contact form, social media channel.
      • +
      • Self-help option such as an up-to-date Frequently Asked Questions, How Do I page, Support page.
      • +
      • A fully automated contact mechanism such as a chatbot.
      • +
      + +

      The order of the types of help listed in the Success Criterion does not imply priority.

      +
      +
      +

      Support for people with cognitive and learning disabilities

      + +

      This section is not required by the Consistent Help success criterion, but provides advice related to Making Content Usable for People with Cognitive and Learning Disabilities.

      + +

      The human contact details enable users to connect with the organization or the part of the organization that can assist with the content. For example, an online jobs / recruitment portal may provide a contact method for the team that supports the recruitment portal and not a catch-all for the entire company. Each layer of contact added prolongs the time before the user will receive help.

      + +

      The human contact mechanism enables a person to express what they are looking for using their own words. For some with cognitive disabilities, this may be the best way for them to find an answer to their problem.

      + +

      For pages for which no human support is available it helps if a self-help option says that no human support is available. Self-help options can go beyond allowing the user to search within the site. Contextual help is still recommended (see Success Criterion 3.3.5 for more information), but a self-help option provides a single location that makes it easier for people with cognitive disabilities to understand what help is available without having to hunt for it. While some people may easily be able to identify that no support would be available for a particular type of Web site, this may not be apparent to some users with disabilities.

      + +

      Chatbots can work for many people, and particularly for people with cognitive disabilities if they:

      + +
        +
      • recognize misspelled words,
      • +
      • provide human contact details if the chatbot is unable to provide a satisfactory response after 3 attempts, and
      • +
      • can be dismissed with a single interaction, and recalled using a link or button.
      • +
      + +

      This criterion does not require that a site provide a help mechanism. However, when help is available:

      +
        +
      • People who may have difficulty locating help are more likely to find it and complete their task.
      • +
      • Users that experience cognitive fatigue or cognitive shut down will be able to reserve their energy for the task, instead of using it to find support.
      • +
      • Enabling users (especially those with cognitive disabilities) to find solutions while expressing their question using their own words (for example by interacting with a chatbot) increases their chances of success for completing a task.
      • +
      + +

      Self help methods beyond the site, such as using internet search to find the contact information for an organization, can be too difficult. Further, the user's disability may make it more difficult to find the help available (such as a "contact us" link, phone number, or support page) if the information is not consistently present within a few interactions (e.g., displayed in the header, or via a menu). In addition, for some users with disabilities, struggling to complete a task on a site may cause additional cognitive challenges when searching for help within the site.

      + +

      When a user is quickly able to find help, they are able to complete the task even if they encounter challenges.

      +
      +
      + +
      +

      Benefits of Consistent Help

      + +
        +
      • People who may have difficulty locating help are more likely to find it when it is consistently located.
      • +
      + + +
      + +
      +

      Examples of Consistent Help

      + +
        +
      • On-line job application: Some of the application questions may be hard for new job seekers to understand even after reading the contextual help. For example, the form may request their identification number, but they may have several and not know which one to enter. Consistently located contact information will enable them to use phone or email so they can get an answer to their question.
      • +
      • Medical appointment scheduling form: When the service a patient is trying to book is not easily findable within the interface, they may need human help. A consistently located messaging option (chat client) enables them to quickly interact with a staff person that can help, without requiring them to manage a second interface.
      • +
      • Finding a specific policy or procedure: An employee who needs to complete a work task may have difficulty locating the specific policy or procedure document on their employer's Web site. A consistently located "How Do I" page may include the information that enables them to independently complete this task.
      • +
      + +
      + + +
      +

      Techniques for Consistent Help

      + + +
      +

      Sufficient Techniques for Consistent Help

      + +
      + +
      +

      Additional Techniques (Advisory) for Consistent Help

      + +
      + +
      +

      Failures for Consistent Help

      + +
        +
      • Inconsistent Help Location +
      • +
      +
      +
      + +
      +

      Resources

      + + + +
      + + + + + + + diff --git a/understanding/22/dragging-movements.html b/understanding/22/dragging-movements.html new file mode 100644 index 0000000000..06537aa102 --- /dev/null +++ b/understanding/22/dragging-movements.html @@ -0,0 +1,127 @@ + + + + + Understanding Dragging + + + +

      Understanding Dragging Movements

      + +
      +

      In brief

      +
      +
      Goal
      Don’t rely on dragging for user actions.
      +
      What to do
      For any action that involves dragging, provide a simple pointer alternative.
      +
      Why it's important
      Some people cannot use a mouse to drag items.
      +
      +
      + +
      + +

      Intent of Dragging Movements

      + +

      The intent of this Success Criterion is to ensure functionality that uses a dragging movement has another single pointer mode of operation without the need for the dexterity required to drag elements.

      + +

      Some people cannot perform dragging movements in a precise manner. Others use a specialized or adapted input device, such as a trackball, head pointer, eye-gaze system, or speech-controlled mouse emulator, which may make dragging cumbersome and error-prone.

      + +

      When an interface implements functionality that uses dragging movements, users perform four discrete actions:

      + +
        +
      1. tap or click to establish a starting point, then
      2. +
      3. press and hold that contact while...
      4. +
      5. performing a repositioning of the pointer, before...
      6. +
      7. releasing the pointer at the end point.
      8. +
      + +

      Not all users can accurately press and hold that contact while also repositioning the pointer. An alternative method must be provided so that users with mobility impairments who use a pointer (mouse, pen, or touch contact) can use the functionality.

      + +

      This requirement is separate from keyboard accessibility because people using a touch screen device may not use a physical keyboard. Keyboard specific interactions such as tabbing or arrow keys may not be possible when encountering a drag and drop control. Note, however, that providing a text input can be an acceptable single-pointer alternative to dragging. For example, an input beside a slider could allow any user to enter a precise value for the slider. In such a situation, the on-screen keyboard that appears for touch users offers a single-pointer means of entering an alphanumeric value.

      + +

      This criterion does not apply to scrolling enabled by the user-agent. Scrolling a page is not in scope, nor is using a technique such as CSS overflow to make a section of content scrollable.

      + +
      + +

      Relationship to other requirements

      + +

      Success Criteria 2.1.1 Keyboard and 2.1.3 Keyboard (No Exception) require dragging features to be keyboard accessible. However, achieving keyboard equivalence for a dragging operation does not automatically meet this Success Criterion. It is possible to create an interface that works with dragging and keyboard controls that does not work using only clicks or taps. While many designs can be created for a dragging alternative which address both keyboard accessibility and operability by single pointer operation, the two requirements should be assessed independently.

      + +

      This Success Criterion applies to dragging movements as opposed to pointer gestures, which are covered in Success Criterion 2.5.1 Pointer Gestures. Pointer gestures include directional path-based as well as multi-point gestures. In contrast, for dragging movements, only the start and end point of the movement matters, not the actual path.

      + +

      Additional examples are selection rectangles that set the first x/y rectangle coordinate at the pointer position via a pointer down-event, and the second x/y coordinate, after a dragging movement, at the next up-event. A similar example is a connecting line drawn between two different items on the screen, as in an allocation test where users are required to draw a line between questions and corresponding answers. In these cases, the dragging movement requires an alternative way to accomplish the same action that does not rely on the dragging movement. For example, two separate single tap or click actions may define the rectangle coordinates or the start and end points of a connecting line.

      + +
      + +
      +

      Alternatives for dragging movements on the same page

      + +

      Where functionality can be executed via dragging movements and an equivalent option exists that allows for single-pointer access without dragging, this Success Criterion is passed. It does not have to be the same component, so long as the functionality is equivalent. An example is a color wheel where a color can be changed by dragging an indicator. In addition, text fields for the numerical input of color values allow the definition of a color without requiring dragging movements. (Note that a text input is considered device agnostic; although the purpose is to enter characters, text entry can take place through voice, pointer or keyboard.)

      + +
      + +
      +

      Distinguishing dragging movements from path-based pointer gestures

      + + +

      Dragging movements covered in this Success Criterion are pointer interactions where only the start- and endpoints matter. Once the pointer engages with a target, the direction of the dragging movement does not factor into the interaction until the pointer disengages the target. Since the dragging movement does not have an intermediate point, the dragging movement can go in any direction. Path-based gestures are covered in Success Criterion 2.5.1 Pointer Gestures.

      + +
      + +
      + +
      +

      Benefits of Dragging Movements

      + +
        +
      • Users who struggle with performing dragging movements can still operate an interface with a pointer interface.
      • +
      + +
      + +
      +

      Examples of Dragging Movements with alternatives

      + +
        +
      • A map allows users to drag the view of the map around, and the map has up/down/left/right buttons to move the view as well.
      • +
      • A sortable list of elements may, after tapping or clicking on a list element, provide adjacent controls for moving the element up or down in the list by simply tapping or clicking on those controls.
      • +
      • A taskboard that allows users to drag and drop items between columns also provides an additional pop-up menu after tapping or clicking on items for moving the selected element to another column by tapping or clicking on pop-up menu entries.
      • +
      • A radial control widget (color wheel) where the value can be set by dragging the marker for the currently selected color to another position, also allows picking another color value by tapping or clicking on another place in the color wheel.
      • +
      • A linear slider control widget, where the value can be set by dragging the visual indicator (thumb) showing the current value, allows tapping or clicking on any point of the slider track to change the value and set the thumb to that position.
      • +
      • A widget where you can drag a gift to one person in a photo of a group of people also has a menu alternative where users can select the person that should receive the gift from the menu.
      • +
      + +
      + +
      +

      Techniques for Dragging

      + +
      +

      Sufficient Techniques for Dragging Movements

      + + + +
      + +
      +

      Additional Techniques (Advisory) for Dragging Movements

      + +
      + +
      +

      Failures for Dragging Movements

      + + +
      + +
      + + + diff --git a/understanding/22/focus-appearance.html b/understanding/22/focus-appearance.html new file mode 100644 index 0000000000..5426fd0a9e --- /dev/null +++ b/understanding/22/focus-appearance.html @@ -0,0 +1,783 @@ + + + + + + + Understanding Focus Appearance + + + + + +

      Understanding Focus Appearance

      + +
      +

      In brief

      +
      +
      Goal
      +
      Make it easier to spot the keyboard focus.
      +
      What to do
      +
      Use a focus indicator of sufficient size and contrast.
      +
      Why it's important
      +
      Many people can't see small changes in visual appearance, including older people.
      +
      +
      + +
      + +

      Intent of Focus Appearance

      + + +

      The purpose of this Success Criterion is to ensure a keyboard focus indicator is clearly visible and + discernible. Focus Appearance is closely related to 2.4.7 Focus Visible and 1.4.11 Non-text Contrast. + Focus Visible requires that a visible focus indicator exists while a component has keyboard focus; Focus + Appearance defines a minimum level of visibility. Where Non-text Contrast requires a component to have + adequate contrast against the background in each of its states, Focus Appearance requires sufficient + contrast for the focus indicator itself.

      + +

      For sighted people with mobility impairments who use a keyboard or a device that utilizes the keyboard interface + (such as a switch or voice input), knowing the current point of focus is very important. Visible focus must also meet the needs + of users with low vision, who may also rely on the keyboard.

      + +

      A keyboard focus indicator can take different forms. This Success Criterion encourages the use of a solid + outline around the focused user interface component, but allows other types of indicators that are at least + as large.

      + + +

      This Understanding document will elaborate on the minimum area requirement, color contrast requirements, and + finally list some user agent exceptions.

      + +
      +

      Minimum area

      + +

      The first part of the Success Criterion specifies a minimum area for the focus indicator:

      + +
      +
        +
      • is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused + component or sub-component
      • +
      +
      + + +

      This only specifies a minimum area for the focus indicator. It does not require that the focus indicator + literally be a 2 CSS pixel thick outline, only that the indicator be at least that large.

      + +

      However, the simplest way to meet the size requirement is to use a focus indicator which is a + solid 2 CSS pixel thick perimeter.

      + +

      A CSS pixel is what developers use in CSS declarations like “width: 200px”. It is + device-independent and not to be confused with device pixels which vary depending on the physical pixel + density.
      + + The rest of this document notates CSS pixels as “px”. +

      + +
      +

      Using a solid outline

      + +

      The easiest and most common way to meet this requirement is to use a solid outline around the + component. The outline must be at least 2px thick. The following illustration shows a + minimally thick focus indicator, where a 2px thick band of white pixels making up + the page background around an example button have been altered to black. +

      + +
      + + 2 blue buttons with a dark 2 pixel thick offset focus rectangle around the second + +
      Passes: The focus indicator is a solid 2px thick outline.
      +
      + +

      For non-rectangular components, the "perimeter" definition allows authors to use either of the + following types of outline:

      + +
        +
      • a line which solidly encloses a shape, or
      • +
      • a line which solidly encloses the minimum bounding box of a shape
      • +
      + +

      For example, a star-shaped button may use either a focus indicator that follows the shape of the star + or a focus indicator that follows the bounding box of the star. In the following examples, the same + three stars have already been selected, and focus is on the third star. The first example uses a + focus indicator which matches the star shape of the focused star. The second uses a rectangular + indicator.

      + +
      + + Three of 5 stars are selected with a solid-line focus indicator in the shape of a star outlining the third + +
      Passes: a solid outline indicator surrounds the third of five stars.
      +
      + +
      + + 3 of 5 stars are selected with a solid-line rectangular focus indicator around the third + +
      Passes: a solidly bound focus rectangle encloses the third of five stars.
      +
      + +

      Offsetting indicators slightly from the focused component, as in the examples above, is not required + to meet the minimum area requirement of the success criterion, but it can help make indicators more + visible. In CSS, the outline and outline-offset properties are commonly + used to achieve this.

      + +

      The smallest possible 2 CSS pixel thick indicator that is still a "perimeter" is a solid line that + appears inside the component against the component's outer edge, for example by using a CSS + border property. Indicators that are inset further within the component (not directly + against the component's outer edge) need to be thicker than 2 CSS pixels to meet the minimum size + requirement. +

      + +
      + + a button along with 4 examples of different 2px solid focus indicators for it: offset outside the component, an outline around the boundary of the component, a border inside the boundary of the component, and inset inside the component +
      All four of these example focus indicators are 2px solid lines. The "outset", "outline", + and "border" indicators pass. The "inset" indicator does not meet the minimum area requirement + and fails; it would need to be at least 3px thick to pass.
      + +
      + +

      Note that different Non-text Contrast requirements may apply depending on whether the focus indicator + is offset from, inset into, or against the edge of the component. See the Relationship with Non-text Contrast section + below.

      +
      +
      +

      Other indicator shapes

      + +

      This Success Criterion does not require that focus indicators be solid outlines. Other shapes may be + used so long as they meet the minimum area requirement.

      + +

      The minimum area of the focus indicator for a control is the area of a 2 CSS pixel thick perimeter of + the control (or its minimum bounding box) in the control's unfocused state. For example, if a + control is a rectangle 90px wide and 30px tall, the area of a 2 CSS pixel thick perimeter is + difference between the areas of:

      + +
        +
      • A 92px by 32px rectangle (1px larger on all sides), and
      • +
      • A 88px by 28px rectangle (1px smaller on all sides)
      • +
      + +

      This results in a minimum area of (92px * 32px) - (88px * 28px) = 480px2.

      + +

      Some general formulas for 2 CSS pixel thick perimeters of common shapes are:

      + +
      +
      Rectangle with width w and height h
      +
      4h + 4w
      +
      Circle with radius r
      +
      4𝜋r
      +
      Rounded rectangle with width w, height h, and border radius r
      +
      4h + 4w - (16 - 4𝜋)r
      +
      + +

      If you need to use complex mathematics to work out if a focus indicator is large enough, + it is probably a sign that you should use a larger indicator instead. The bigger the visible change + when an item receives focus, the easier it is for someone to see.

      + +

      The following 2 examples use a 90px wide by 30px tall button, with a minimum area requirement of + 480px2:

      + +
      + + Three 90 by 30 pixel buttons. The middle button has a focus indicator which is a 3px thick outline inset by 3px inside the button +
      Passes: the inner outline is inset slightly from the outer edge of the component, but + compensates for this by being 3px thick. It has an area of 612px2, which exceeds the + 480px2 minimum.
      +
      + +
      + Three 90 by 30 pixel buttons. The middle button has a focus indicator which is two rectangles inside the button, one on either side +
      Passes: the indicator rectangles on either side of the focused button are each 9px wide + by 28px tall. In total, they are 504px2, which just barely meets the + 480px2 minimum.
      + +
      + +

      Prefer using focus indicator techniques that scale with both the width and height of the + focused control. Otherwise, if controls change size across different variations of a page (for + example, in a responsive design), the indicator might meet the area requirement in some variations + but not others. For example, in the above figure, if the width of the two highlight rectangles did + not scale as the button grew wider, it would stop meeting the minimum area requirement if the button + needed to grow any wider to accomodate a longer button label.

      + +

      Another way of achieving the area requirement is to alter the appearance of the entire component, for + instance by changing its color – provided that the new color has a contrast ratio of at least 3:1 + against the original color. This can be effective in a set of closely placed buttons. The following + example demonstrates this with 5 rating stars; the center star is filled in with a darker color to + indicate focus. However, it is much more difficult to detect such a focus indicator when components + are not near each other and so cannot be easily compared. For users using magnification, even + components relatively close together may be difficult to compare, so it is not considered a best + practice.

      + +
      + + 3 of 5 stars are selected with the whole third star altered in color to indicate focus + +
      Passes: a color change applies to the whole third star to indicate focus.
      +
      +
      + +
      + +
      +

      Change of contrast

      + +

      The second part of the Success Criterion's indicator requirements states that an area of the indicator: +

      + +
      +
        +
      • has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states +
      • +
      +
      + +

      This requirement measures the change of contrast between the same pixels in different states. This is + different from the Text Contrast and Non-text Contrast Success Criteria, which measure the contrast + between different adjacent pixels in a single state at a time.

      + +

      3:1 is the minimum allowable change-of-contrast ratio, but the greater the change of + contrast between states, the easier it is for users to see the focus indicator. Authors are encouraged + to make the change-of-contrast ratio as great as possible.

      + +

      The following illustration shows a minimally contrasting focus indicator, where some of + the white pixels making up the page background have been altered to a mid-grey that has a 3:1 contrast + ratio with the original white. Authors are encouraged to exceed the minimum focus appearance. For + instance, the dark blue lines in figures 2 and 3 are much more visible.

      + +
      + + Two orange-yellow five-pointed stars, one with a mid-gray focus rectangle +
      Passes: Two buttons in the shape of a star, with the second surrounded by a focus indicator + whose pixels contrast 3:1 between focused (light grey) and unfocused (white) states.
      + +
      + +

      When a component changes to include a focus indicator, that change can be measured as a change of color + contrast. For example, if a yellow outline is added to a button on a blue background, the change of + color is from blue to yellow. This change can be measured whether the focus indicator is on the + background around the component, or the background within the component.

      + +
      + + Three dark blue buttons on a white background. The middle button has a yellow inner border. +
      Passes: adding a yellow outline to a link is a change of color from blue to yellow. That + change has a contrast ratio of 12:1.
      + +
      + +

      If a control receiving focus changes its background (fill color) to a color that contrasts less than 3:1 + with the original background, that would not pass the change of contrast.

      + +
      + + Three black buttons with a dark background. The middle button has a dark grey background. +
      Fails: the second link has a dark-grey (#555) which fails this Success + Criterion because the change from black-background to dark-grey background does not meet 3:1. +
      + +
      + +

      If the background change is sufficient, it is a method of passing the criterion.

      + +
      + + Three black buttons with a dark border and two have a dark background. The middle button has a white background. +
      Passes: the second link has a white background (#fff) which passes this + Success Criterion because the change from black-background to white-background meets 3:1. +
      + +
      + +
      +

      Partially contrasting indicators

      + +

      It is not necessary for the entire focus indicator to have a 3:1 change of contrast. It is + sufficient for just a part of the indicator to meet the change of contrast requirement, so long as + the contrasting part of the indicator meets the minimum area requirement.

      + +
      + + A button whose focus indicator is two nested outlines: an inner 2px thick light gray outline with low contrast against the background, and an outer 2px thick black outline with high contrast +
      Passes: The black part of the indicator meets 3:1 contrast with the white background, + but the gray part does not. The black part is 2px thick, so it meets the minimum area + requirement on its own and the gray part can be ignored.
      +
      + +
      + A button whose focus indicator is two nested outlines: an inner 1px thick light gray outline with low contrast against the background, and an outer 1px thick black outline with high contrast +
      Fails: The indicator as a whole is 2px thick, but the part of it that has sufficient + change-of-contrast is only 1px thick. The part of the indicator with sufficient + change-of-contrast does not meet the minimum area requirement.
      + +
      + +

      When calculating whether a focus indicator meets the minimum area requirement, only the part of the + indicator which meets the change-of-contrast requirement should be included in the calculation.

      +
      + +
      +

      Gradients

      + +

      If a focus indicator has a gradient, the principle is to measure the contrast of the changed area, + and ignore any part of the gradient which has less than a 3:1 change-of-contrast ratio.

      + +
      + + Three buttons, the middle with a heavy drop-shadow indicating focus. +
      When a gradient is used on a focus indicator, the measure of surface area should only + include the area that has changed enough to meet the 3:1 contrast ratio.
      + +
      + +

      If you eliminate the area which has less than 3:1 change-of-contrast, you can calculate the area of + the remaining parts of the indicator to determine whether the indicator meets the minimum area + requirement.

      + +
      + + The middle button with the drop-shadow included, but the subtle grey areas removed to only show the contrasting area. +
      Passes: the same focused button with the non-contrasting areas removed. The contrasting + area is 6px thick along most of the bottom edge and 3-4px thick on the left and right edges, + which is enough to meet the minimum area requirement.
      +
      + +

      Some of the examples in this document are screen-captured images of elements. Due to + loss of resolution in these images, the actual pixel color may not match the original. As such, they + are intended to be used for illustrative purposes, and should not be inspected on a pixel-by-pixel + basis for sufficient contrast.

      + +

      Some designs have pages with a non-solid background image covering the whole (or part) of the page or + make use of parallax scrolling effects which result in a near-infinite number of color combinations + if a page is scrolled and/or changes are made to the viewport size.

      + +

      If the contrast of background colors that change are close enough to need to be tested for each + combination then they would likely not meet the user need of people with low vision in certain + scroll combinations and would likely fail in certain combinations as well. In these cases it would + be an easy solution to use a two-color + focus indicator or some other mechanism to indicate focus such as a solid box with a border + to guarantee there is sufficient contrast across variations of background images or background + gradients.

      + +

      It is possible to use visual patterns such as strips switching places to disguise a change of focus + indicator. However, this is not considered a visible indicator.

      + +
      +
      + +
      +

      Relationship with Non-text Contrast

      + +

      Focus indicators are visual information required to identify a state of a user interface component. That + means that they are subject to 1.4.11 Non-text Contrast, in + addition to 2.4.13 Focus Appearance.

      + +

      In combination with 2.4.7 Focus Visible, 1.4.11 Non-text Contrast requires that the visual focus indicator for a component + must have sufficient contrast against the adjacent colors when the component is focused, except where + the appearance of the component is determined by the user agent and not modified by the author.

      + +

      The difference between the contrast requirements in Focus Appearance and Non-text Contrast is:

      + +
        +
      • Focus Appearance requires that focus indicators have a change of contrast between focused + and non-focused states.
      • +
      • Non-text Contrast requires that focus indicators have adjacent contrast between the + indicator (in the focused state) and adjacent non-indicator colors.
      • +
      + +
      + + A light blue button with a 3px thick border. The border is black in the unfocused state and light gray in the focused state. +
      This example passes Focus Appearance but fails Non-text Contrast; there is insufficient + adjacent contrast between the focus indicator and the adjacent colors. +
      +
      + +
      + A light blue button with a 3px thick border. The border is black in the unfocused state and dark gray in the focused state. +
      This example passes Non-text Contrast but fails Focus Appearance; there is insufficient + change of contrast between the focused and unfocused states. +
      + +
      + +

      Additionally, Non-text Contrast does not establish any size requirement and has slightly different rules + for when exceptions are allowed.

      + + +

      See the Relationship with Focus Visible section of Understanding 1.4.11 + Non-text Contrast for more details and examples.

      + +
      + +
      +

      Component keyboard focus

      +

      The preamble to this Success Criterion is "When a user interface component has keyboard focus..." The + keyboard focus is the point of interaction for someone using a keyboard. For environments with + a keyboard-operable interface, the keyboard focus can be moved around the interface in order to interact + with different components. Whichever component is being interacted with has focus. +

      + +

      WCAG defines user interface component as "a part of the content that is perceived by users as a + single control for a distinct function." Because different users may perceive controls differently, + there is a potential for some variation when interpreting what constitutes both a single + control and a distinct function. This is particularly the case when something visually + presents in a way that may differ from how it is programmatically created under the covers. Where there + is not a native HTML component upon which to base designs, there can be great variations in how the + components and their focus indicators are portrayed. Further, some components have sub-components that + can take focus, such as the menu items on a menu.

      + +

      Nonetheless, consistent results from different testers were obtained for this Success Criterion by using + the focus indicator itself as the gauge of what constitutes the component being interacted with. For + complex components, the three typical focus indicators are as follows:

      + +
        +
      • Focus indicator around only the whole component
      • +
      • Focus indicators around both the component and subcomponent
      • +
      • Focus indicator around only the subcomponent
      • +
      + +

      Each of these will be discussed, using a tablist as a familiar complex component.

      + +

      Focus indicator around only the whole component

      +
      + + Three tab buttons shown with a dark blue rectangle around all three tab buttons. +
      A tablist with a focus indicator around only the whole.
      +
      + +

      When the focus indicator is shown only around the whole tablist, the user is guided to considering the + tablist as a single user component. The tab items within it are visually distinguished between selected + and unselected states (and visual indicators of selection state must meet the criteria given in 1.4.11 Non-text + Contrast).

      + +

      Having a focus indicator only around the whole is possible where there is no need to have a + selected sub-component while another sub-component has focus. For a tablist which synchronizes its tab + panel content with whatever tab is active, only one tab item can be selected at a time, and since + whatever tab is selected is considered active, a separate focus indicator is redundant.

      + + +

      Result: the group focus indicator must meet the requirements of this Success Criterion.

      + +

      A radio button group and a + star-rating + widget, which each use only a whole-component focus indicator, provide working examples of + different complex components that pass the primary requirements of this Success Criterion. In the star + ratings example, users can increment the rating by 1/2 stars. Not only is a focus indicator for each 1/2 + star unnecessary, but it would actually be difficult to achieve without making the interaction + confusing. +

      + +

      Focus indicators around both the component and subcomponent

      + +
      + + Three tab buttons shown with a dark blue rectangle around all three tab buttons, the first tab button also has a dark outline as well as a blue bar indicating it is selected. +
      + The same tab list showing except the first tab is selected, but the second has the focus outline. +
      The same tablist in two states. In the first, focus is around both the tablist and the + currently selected tab; in the second, focus is around both the tablist and an unselected tab. +
      +
      + +

      For a tablist which does not keep its tab panel content synchronized with whatever tab is selected, there + needs to be a focus indicator for the tab item subcomponent. This is because the tab item with focus may + be different than the selected item.

      +

      The user can navigate to the tablist, which in this implementation has a focus rectangle around the whole + tablist as well as one around a tab item (conventionally the item that is currently selected). The focus + around the whole is helpful in cueing a keyboard user that this is a complex component that has its own + interaction. The user can then move focus between the unselected and selected tab items -- each of which + in turn has its own focus indicator -- before activating one, which then makes it selected as well as + focused, and updates the tab panel to match.

      +

      In this scenario, either the group focus indicator or the sub-component indicator must meet the + requirements of this Success Criterion. To avoid being overly prescriptive, the Success Criterion allows + authors to choose which makes the most sense. Generally, if a sub-component focus is necessary, it + should be assessed instead of the group indicator.

      + +

      Result: the focus indicator for the tab item meets the requirements of this Success Criterion. The + tablist focus indicator does not need to meet the requirements.

      + +

      A slider to pick + colors provides a working example of a different complex component that predominantly shows + focus for the subcomponent. In this case, the thumb slider sub-component has a focus indicator of + sufficient size and contrast to pass the sufficient area calculation. There is also a subtle focus + around the whole slider component, but it does not need to be assessed to pass this Success Criterion. +

      + + +

      Focus indicator around only the subcomponent

      + +
      + + Three tab buttons shown and the first button has a dark outline. +
      The same tabs as in the prior set, but the focus indicator around the whole is removed. +
      +
      + +

      The same unsynchronized tablist can also be implemented as something which only shows focus on the tab + items and not on the whole. The behaviour is the same as in the prior example, but there is never a + focus indicator placed around the tablist. This interaction is acceptable, but it is not best practice + since it demands more understanding from the user with less information. For example, some visual cues + for the tablist and tab items (and tab panel) may not be clear. As well, keyboard users may not + initially understand the expected keyboard interaction.

      + +

      Result: the focus indicator for the tab item must meet the requirements of this Success Criterion, + judging focus with both selected and unselected tab items.

      + +

      A + functional example of sub-component-only tab focus has an indicator that is large enough (at + least four times the shortest side) with sufficient contrast to pass the focus area language of this + Success Criterion.

      + + +

      Where something with focus is not a user interface component

      +

      Some pages contain very large editing regions, such as web implementations of word processors and code + editors. Unlike a textarea element, which is a user interface component, these large + editing regions do not typically meet the definition of user interface components; + they are not "perceived by users as a single control for a distinct function." + Providing focus indicators around such editing regions may still be beneficial to some; however, where + the region is not perceived as a single control, it is not covered by this Success Criterion. The web + page will still need to provide a insertion point (caret indicator) in such editing regions in order to + meet the requirements of 2.4.7 + Focus Visible.

      + +

      Some non-operable elements can take focus (such as a heading element that is the target of a skip link). + However, the preamble of this Success Criterion refers to user interface components; it is only when the + element with focus is operable by keyboard that this Success Criterion applies.

      +
      + +
      +

      Exceptions

      + +

      There are two situations where the focus appearance does not need to be assessed:

      + +
        +
      • the focus indicator cannot be adjusted by the author
      • +
      • the author has not modified the effects of the user agent default
      • +
      + +
      +

      First exception: the focus indicator cannot be adjusted by the author

      + +
      +

      The focus indicator is determined by the user agent and cannot be adjusted by the author

      +
      + +

      Some components or technologies may not allow the author to adjust the focus indicator. This is the + case with HTML select elements (both single and multi-select), where the visual + treatments for selection and focus cannot be adjusted by the author. In this case the Success + Criterion does not apply.

      + +
      + + A country select element with Afghanistan selected and Albani with focus +
      Passes: The user agent's default select element presentation cannot be + modified by the author, so it passes regardless of the quality of the focus indicator +
      +
      + +
      + +
      +

      Second exception: the default indicator and background are not modified

      + +
      +

      The focus indicator and the indicator's background color are not modified by the author

      +
      + +

      If the focus indicator and the background behind the focus indicator are not modified by the author, + the Success Criterion does not apply.

      + +

      The intent of this exception is to reduce burden on authors by allowing them to rely on the default + indicators provided by user agents (browsers). If all user agents provided good focus indicators, + authors would be able to concentrate efforts on other accessibility considerations. Unfortunately, + browser default focus indicators vary by component, browser, and across devices and operating + systems, and the default focus indicators in some browsers can be difficult to see (such as a 1px + dotted outline). For this reason, most authors override browser defaults in order to overcome these + deficiencies and create a more uniform user experience, regardless of browser.

      + +

      Some browser makers are improving their default focus indicators to make them more visible. As more + browsers adopt defaults that meet the primary bullets of this Success Criterion, authors will be + able to achieve improved focus indicators without customization.

      + +

      Modifying the focus indicator background

      + +

      Browser default focus indicators can be made more difficult to see if the author modifies + the pixels directly adjacent to the indicator (commonly referred to as its background), such as by + positioning a component on top of an image or gradient background, or altering the page's default + white background color, for instance using a blue background in combination with a browser's blue + default indicator. For this reason, where the author alters the pixels directly adjacent to the + default focus indicator, the user agent exception does not apply, and the author will need to verify + they meet the size and contrast requirements of this Success Criterion.

      +

      Altering the body element's background-color attribute + is one way of altering the pixels directly adjacent to the indicator in most + implementations. However, specifying a value of white (#FFFFFF) does not nullify this + exception since, as established in the third note of the contrast ratio definition, the + default ("unspecified") color is assumed to be white. +

      + +

      As well, if the browser provides an indicator within a component by default, then authors + can potentially reduce the visibility by changing the component color (which in such a scenario is + the background color for the focus indicator). For example, if the default indicator on a button + uses a colored inner border, authors can negatively affect the focus appearance by making the button + or its unfocused border color a similar-luminosity color. For this reason, this user agent exception + can only be met if the author both does not modify the default focus indicator and does not + modify its background.

      + +
      + + A button with an author-customized blue border which looks very similar to the blue border used by a user agent default focus indicator +
      Fails: The middle button is focused using a browser's default focus indicator, but it is + very difficult to tell which button is focused because the custom blue border on the unfocused + button uses a similar color.
      + +
      +
      +
      +
      + +
      +

      Benefits of Focus Appearance

      + +
        +
      • This Success Criterion helps anyone who relies on the keyboard to operate the page, by letting them + visually determine the component on which keyboard operations will interact at any point in time.
      • +
      • People with attention limitations, short term memory limitations, or limitations in executive processes + benefit by being able to discover where the focus is located.
      • +
      + +
      + +
      +

      Examples of Focus Appearance

      + +
        +
      • When links receive focus, an outline is displayed around the link that contrasts with the background + adjacent to the link.
      • +
      • When buttons receive focus, an outline is displayed within the button (around the text) that contrasts + with the button's background.
      • +
      • When text fields receive focus, an outline is displayed around the field, indicating that the input has + focus.
      • +
      • When radio buttons receive focus, an outline is displayed around the control, indicating that the input + has focus.
      • +
      + +
      + +
      +

      Related Resources

      + +
      + +
      +

      Techniques

      + +
      +

      Sufficient Techniques

      + + +
      + +
      +

      Failures

      + +
      +
      + + + \ No newline at end of file diff --git a/understanding/22/focus-not-obscured-enhanced.html b/understanding/22/focus-not-obscured-enhanced.html new file mode 100644 index 0000000000..7d90460a6d --- /dev/null +++ b/understanding/22/focus-not-obscured-enhanced.html @@ -0,0 +1,67 @@ + + + + +Understanding Focus Not Obscured (Enhanced) + + + +

      Understanding Focus Not Obscured (Enhanced)

      + +
      +

      In brief

      +
      +
      Goal
      Don't cover any part of the item with focus.
      +
      What to do
      Ensure when an item gets keyboard focus, it is fully visible.
      +
      Why it's important
      People who can't use a mouse need to see what has keyboard focus.
      +
      +
      + +
      +

      Intent of Focus Not Obscured (Enhanced)

      +

      The intent of this Success Criterion is to ensure that the item receiving keyboard focus is always visible in the user's viewport. For sighted people who rely on a keyboard (or on a device that operates through the keyboard interface, such as a switch or voice input), knowing the current point of focus is critical. The component with focus signals the interaction point on the page. Where users cannot see the item with focus, they may not know how to proceed, or may even think the system has become unresponsive.

      +

      Typical types of content that can overlap focused items are sticky footers, sticky headers, and non-modal dialogs. As a user tabs through the page, these layers of content can hide the item receiving focus, along with its focus indicator.

      +

      A notification implemented as sticky content, such as a cookie banner, will fail this Success Criterion if it partially covers a component receiving focus. Ways of passing include making the banner modal so the user has to dismiss the banner before navigating through the page, or using scroll padding so the banner does not overlap other content. Notifications that do not require user action could also meet this criterion by closing on loss of focus.

      +

      Another form of obscuring can occur where light boxes or other semi-opaque effects overlap the item with focus. This form of obscuring is not in scope for this Success Criterion. While less than 100 percent opacity is not causing the component to be visually hidden, such semi-opaque overlaps may cause a failure of 1.4.11 Non-text Contrast and/or 2.4.13 Focus Appearance. When a focus indicator can be covered by a semi-opaque component, the focus indicator should be assessed against 1.4.11 and 2.4.13. The intention in both situations is that the component receiving focus should never be obscured to the point a user cannot tell which item has focus.

      +
      +
      +

      Benefits of Focus Not Obscured (Enhanced)

      +
        +
      • Sighted users who rely on a keyboard interface to operate the page will be able to see the component which gets keyboard focus. Such users include those who rely on devices which use the keyboard interface, including speech input, sip-and-puff software, on-screen keyboards, scanning software, and a variety of assistive technologies and alternate keyboards.
      • +
      • People with limited or low vision but who rely upon a pointing device (for viewport orientation and repositioning) benefit from a clearly visible indication of the current point of keyboard interaction, especially where magnification reduces the overall useable portion of content.
      • +
      • People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to more easily discover where the focus is located.
      • +
      +
      +
      +

      Examples of Focus Not Obscured (Enhanced)

      + +
        +
      • A page has a sticky footer (attached to the bottom of the viewport). When tabbing down the page the focused item is not at all obscured by the footer because content in the viewport scrolls up to always display the item with keyboard focus using scroll padding.
      • +
      • A page has a large (30% wide) cookie approval dialog. The dialog is modal, preventing access to the other controls in the page until it has been dismissed. Focus is not obscured because the cookie approval dialog (including the focus indicator) remains on screen until selections are made and submitted.
      • +
      • A notification is implemented as a sticky header and the keyboard focus is moved to the notification. The notification disappears when it loses focus, and does not obscure any other controls (including the focus indicator visible prior to the notification).
      • +
      +
      +
      +

      Resources

      +
      +
      +

      Techniques for Focus Not Obscured (Enhanced)

      +
      +

      Sufficient Techniques

      + +
      +
      +

      Additional Techniques (Advisory)

      +
      +
      +

      Failures

      +
        +
      • An interaction that causes content to appear over the component with keyboard focus, visually covering part of the focus indicator. This behavior might be encountered with advertising or promotional material meant to provide more information about a product as the user navigates through a catalogue.
      • +
      • A page has a sticky footer (attached to the bottom of the viewport). When tabbing down the page, a focused item is partially obscured by the footer because content in the viewport scrolls without sufficient scroll padding.
      • +
      +
      +
      + + diff --git a/understanding/22/focus-not-obscured-minimum.html b/understanding/22/focus-not-obscured-minimum.html new file mode 100644 index 0000000000..38f2ad1c76 --- /dev/null +++ b/understanding/22/focus-not-obscured-minimum.html @@ -0,0 +1,201 @@ + + + + + Understanding Focus Not Obscured (Minimum) + + + +

      Understanding Focus Not Obscured (Minimum)

      + +
      +

      In brief

      +
      +
      Goal
      Keep the focused item visible.
      +
      What to do
      Ensure when an item gets keyboard focus, it is at least partially visible.
      +
      Why it's important
      People who can't use a mouse need to see what has keyboard focus.
      +
      +
      + +
      + +

      Intent of Focus Not Obscured (Minimum)

      + +

      The intent of this Success Criterion is to ensure that the item receiving keyboard focus is always partially visible in the user's viewport. For sighted people who rely on a keyboard (or on a device that operates through the keyboard interface, such as a switch or voice input), knowing the current point of focus is critical. The component with focus signals the interaction point on the page. Where users cannot see the item with focus, they may not know how to proceed, or may even think the system has become unresponsive.

      + +

      In recognition of the complex responsive designs common today, this AA criterion allows for the component receiving focus to be partially obscured by other author-created content. A partly obscured component can still be very visible, although the more of it that is obscured, the less easy it is to see. For that reason, authors should attempt to design interactions to reduce the degree and frequency with which the item receiving focus is partly obscured. For best visibility, none of the component receiving focus should be obscured. This preferred outcome is covered by the AAA criterion Focus Not Obscured (Enhanced).

      + +

      Typical types of content that can overlap focused items are sticky footers, sticky headers, and non-modal dialogs. As a user tabs through the page, these layers of content can obscure the item receiving focus, along with its focus indicator.

      + +

      A notification implemented as sticky content, such as a cookie banner, will fail this Success Criterion if it entirely obscures a component receiving focus. Ways of passing include making the banner modal so the user has to dismiss the banner before navigating through the page, or using scroll padding so the banner does not overlap other content. Notifications that do not require user action could also meet this criterion by closing on loss of focus.

      + +

      Another form of obscuring can occur where light boxes or other semi-opaque effects overlap the item with focus. While less than 100 percent opacity is not causing the component to be entirely obscured, such semi-opaque overlaps may cause a failure of 1.4.11 Non-text Contrast. When a focus indicator can be covered by a semi-opaque component, the ability of the focus indicator to pass 1.4.11 should be evaluated (and pass) while the focus indicator is under the semi-opaque component. The intention in both situations is that the component receiving focus should never be obscured to the point a user cannot tell which item has focus.

      + +
      +

      User-movable content

      +

      This SC contains a note regarding content that can be repositioned. If users can move content regions, then they can potentially position the movable content such that it obscures other content that may receive focus. In such a case, the author is only responsible for ensuring that the movable content in its initial position does not obscure the item receiving focus.

      +

      This note is intended to accommodate a common interaction in complex applications such as authoring tools, where the main editing region (also called a canvas) can be enhanced by displaying toolbars or other panels, which can be repositioned around the canvas. It is possible to design such toolbars so they do not obscure focus. Authors are encouraged to do so, as well as pursue techniques which ensure equitable keyboard use of such toolbars. However, in recognition of the complexities involved in responsive design as well as in supporting the ability to transform the text size and spacing of content, only the starting position of such movable panels is assessed.

      + +
      +
      +

      User-opened content

      +

      This SC contains a note regarding content that is opened or disclosed by the user. One example of such content is a menu button opened by a user that opens a list of choices over pre-existing content on the screen. Such content can obscure other information on the screen, but it does not obscure an item receiving keyboard focus, because the new content doesn't stay open through a change of focus. However, authors may create user-opened content that is intentionally designed to persist until closed by the user, such as a chat window. Such persistent content has the potential to fail Focus Not Obscured (Minimum). Various types are described in this section. All can be designed so that they pass this Success Criterion.

      + +

      This section only applies to content that the user actively discloses. Content pre-positioned by the author (such as a sticky footer), or content that appears without direct user initiation, such as system warnings, must not prevent the item receiving focus from being immediately visible in the viewport. Also, this note is not intended to apply to disclosures that are by convention non-persistent. As discussed in the following sub-section, an open dropdown that does not close when no longer focused is not following this convention.

      + +
      +

      Non-persistent opened information

      +

      A number of components on the web open (or disclose) additional content (on activation or on focus) intended for immediate user interaction or information. This new content is often on top of other content, obscuring it. Examples of such components are menu items, select element items, combobox lists (and other dropdown items), date picker calendars, and tooltips. The common trait of all these components is that they are not expected to persist after being acted on or once they are no longer the primary point of user interaction. Such non-persistent disclosures do not fail this SC since they do not obscure the item with focus. However, if an author allows such components to persist after the user has 1) activated one of the opened items or 2) moved the focus away from the triggering item and the additional content, it is at risk of failing this criterion by obscuring the item with focus.

      + +
      + +
      +

      User openable, persistent disclosures

      +

      Some disclosure patterns provide a mechanism for the user to open additional content that remains open until intentionally closed by the user. Accordions are a simple example of such a pattern. Chatbots and expandable side navigation are more complex examples. All of these patterns can be implemented so they are not at risk of failing this SC. Some possible approaches are:

      + +
        +
      • When the additional content appears, it displaces existing content. An accordion is an example of this. When an accordion is opened, the disclosed content shifts existing content further down the page. Since the new content does not obscure existing content, it cannot obscure the item with focus. + +
      • + +
      • When the additional content appears, existing content reflows. The popout sidebar on the WCAG standard is an example of this pattern. When the side menu is activated, it opens a new section of information along the left side of the page. The main content area is reduced horizontally to accommodate the new content, and the existing content reflows to fit in the thinner space. As a result, there is no overlapping content between the two sections; the item receiving focus, whether in the left navigation or in the main content, will not be obscured by the other section. + +
      • +
      • + When the additional content is opened, it takes focus and the tab ring is constrained to the new content until it is dismissed. This modality is somewhat like a dialog, in that a user cannot navigate beyond the opened content by keyboard without dismissing it first (typically by pressing Esc). However, unlike in a modal dialog, in some implementations a pointer user may be able to interact with content outside the opened section without dismissing it. Since this pattern potentially creates an inequitable experience between keyboard and pointer users, it should be used cautiously. That said, it does prevent the opened content from obscuring the keyboard focus in the main content, and thus should pass this SC. This is described and demonstrated in a short video in the Knowbility article in the reference section, under the section heading Keep keyboard focus in the slide-out navigation until it's closed. + +
      • +
      • + The disclosure expands into an area of the page containing no other content. Many pages are designed with wide margins, providing significant white space into which new content can be opened. Many chatbots and toast notifications are designed to 'slide up' into the right unpopulated side of a page. Where authors are careful to ensure content is not obscured at each breakpoint in a responsive design, no obscuring of other operable content need occur. + +
      • +
      • + When focus leaves the additional content, the additional content is automatically hidden or collapsed, or the content can be hidden or collapsed by use of a dedicated keyboard command (for example, the Escape key.) This is very similar to patterns discussed previously under Non-persistent opened information. A distinguishing factor can be that the user's last point of interaction in the disclosure is preserved (it persists) even though it may be hidden until a user returns. Some trees and side navigation patterns behave this way. + +
      • +
      + +

      In recognition of more complex interfaces and user needs there is a note: Content opened by the user may obscure the component receiving focus. If the user can bring the item with focus into view using a method without having to navigate back to the user-opened content to dismiss it, this criterion would be passed. For example, keyboard actions that may allow the item with focus to be revealed include: +

      + +
        +
      • using the Escape key to dismiss the obscuring content;
      • +
      • using keys to scroll the content in the viewport to reveal the item with focus;
      • +
      • issuing a key to move between overlays.
      • +
      + +

      For example:

      + +
        +
      • A user opens a chat interface, which is a popover non-modal dialog. This results in some content of the underlying page being fully obscured. The user navigates away from the chat interface by use of the tab key, focusing onto a link that has been fully obscured by the dialog. The user presses the Escape key to close the chat interface, which un-obscures the link.
      • +
      • A user expands a fixed-position page feedback component at the bottom of a Web page. They then use their keyboard to navigate to a link that's fully obscured by the expanded component and press the down arrow or space key on their keyboard to scroll the content on the page, un-obscuring the link.
      • +
      • A user opens a web-based multi-user authoring application. An overlay appears displaying a list of people who have contributed to the document. The user tabs through the list of contributors and activates one of them. The application displays a new overlay, which obscures the first one, that displays that person's recent contributions. The user presses the F6 key to toggle the stacking order of the two overlays.
      • +
      + +
      +
      +
      +

      Modal dialogs

      + +

      A properly constructed modal dialog will always pass this SC. Even if it appears directly on top of an item with focus, the dialog takes focus on appearance, and thus the item receiving focus -- the dialog or one of its components -- is visible. A properly constructed modal maintains that focus and prevents interaction outside the modal until it is dismissed.

      +

      A dialog-like overlay that does not take focus on appearance and does not either constrain interaction to the overlay or dismiss itself on loss of focus (thus allowing focus to exit into the content behind it) will be at risk of failing this SC, where it is positioned such that it can obscure other focusable items.

      +
      +
      + +
      +

      Benefits of Focus Not Obscured (Minimum)

      + +
        +
      • Sighted users who rely on a keyboard interface to operate the page will be able to see the component which gets keyboard focus. Such users include those who rely on a keyboard or on devices which use the keyboard interface, including speech input, sip-and-puff software, onscreen keyboards, scanning software, and a variety of assistive technologies and alternate keyboards.
      • +
      • People with limited or low vision, who may primarily user a pointer for screen orientation and repositioning, nonetheless benefit from a visible indication of the current point of keyboard interaction, especially where magnification reduces the overall viewing portion of the screen.
      • +
      • People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to discover where the focus is located.
      • +
      + +
      + +
      +

      Examples of Focus Not Obscured (Minimum)

      + +
        +
      • A page has a sticky footer (attached to the bottom of the viewport). When tabbing down the page the focused item is not completely visually obscured by the footer because content in the viewport scrolls up to always display the item with keyboard focus using scroll padding.
      • +
      • A page has a full-width cookie approval dialog. The dialog is modal, preventing access to the other controls in the page until it has been dismissed. Focus is not obscured because the major portion of the cookie approval dialog remains on screen (until selections are made and submitted), and so the major portion of the keyboard focus indicator remains visible.
      • +
      • A notification is implemented as a sticky header and the keyboard focus is moved to the notification so at least part of the focus indicator is in view. The notification disappears when it loses focus so it does not obscure any other controls, and part of the prior keyboard focus indicator is visible.
      • +
      + +
      + +
      +

      Resources

      + + +
      + + +
      +

      Techniques for Focus Not Obscured (Minimum)

      + +
      +

      Sufficient Techniques

      + + + +
      + +
      +

      Additional Techniques (Advisory)

      + +
      + +
      +

      Failures

      + +
      + +
      + + + diff --git a/understanding/22/img/component-complex-both-unselected.png b/understanding/22/img/component-complex-both-unselected.png new file mode 100644 index 0000000000..8c68c31271 Binary files /dev/null and b/understanding/22/img/component-complex-both-unselected.png differ diff --git a/understanding/22/img/component-complex-both.png b/understanding/22/img/component-complex-both.png new file mode 100644 index 0000000000..771af997f0 Binary files /dev/null and b/understanding/22/img/component-complex-both.png differ diff --git a/understanding/22/img/component-complex-sub.png b/understanding/22/img/component-complex-sub.png new file mode 100644 index 0000000000..9df24991cd Binary files /dev/null and b/understanding/22/img/component-complex-sub.png differ diff --git a/understanding/22/img/component-complex-whole.png b/understanding/22/img/component-complex-whole.png new file mode 100644 index 0000000000..1d0b6d77b1 Binary files /dev/null and b/understanding/22/img/component-complex-whole.png differ diff --git a/understanding/22/img/focus-indicator-background-passing.png b/understanding/22/img/focus-indicator-background-passing.png new file mode 100644 index 0000000000..cefbb10c7b Binary files /dev/null and b/understanding/22/img/focus-indicator-background-passing.png differ diff --git a/understanding/22/img/focus-indicator-background.png b/understanding/22/img/focus-indicator-background.png new file mode 100644 index 0000000000..67562d3d60 Binary files /dev/null and b/understanding/22/img/focus-indicator-background.png differ diff --git a/understanding/22/img/focus-indicator-basic.png b/understanding/22/img/focus-indicator-basic.png new file mode 100644 index 0000000000..09666591ae Binary files /dev/null and b/understanding/22/img/focus-indicator-basic.png differ diff --git a/understanding/22/img/focus-indicator-box-shadow-only.png b/understanding/22/img/focus-indicator-box-shadow-only.png new file mode 100644 index 0000000000..bedf2aa698 Binary files /dev/null and b/understanding/22/img/focus-indicator-box-shadow-only.png differ diff --git a/understanding/22/img/focus-indicator-box-shadow.png b/understanding/22/img/focus-indicator-box-shadow.png new file mode 100644 index 0000000000..bb6bc7d09c Binary files /dev/null and b/understanding/22/img/focus-indicator-box-shadow.png differ diff --git a/understanding/22/img/focus-indicator-browser-defaults-modified-background.png b/understanding/22/img/focus-indicator-browser-defaults-modified-background.png new file mode 100644 index 0000000000..fdb1c6f7c6 Binary files /dev/null and b/understanding/22/img/focus-indicator-browser-defaults-modified-background.png differ diff --git a/understanding/22/img/focus-indicator-browser-defaults-unmodified.png b/understanding/22/img/focus-indicator-browser-defaults-unmodified.png new file mode 100644 index 0000000000..f240bb4fea Binary files /dev/null and b/understanding/22/img/focus-indicator-browser-defaults-unmodified.png differ diff --git a/understanding/22/img/focus-indicator-browser-defaults.html b/understanding/22/img/focus-indicator-browser-defaults.html new file mode 100644 index 0000000000..e865ec70ab --- /dev/null +++ b/understanding/22/img/focus-indicator-browser-defaults.html @@ -0,0 +1,37 @@ + + + Figure source: Focus Indicator Custom Shapes + + +
      +

      Figure source: Focus Indicator Browser Defaults

      +
      +

      Unmodified indicator background

      + + + +
      +
      +

      Blue indicator background

      + + + +
      +
      + + diff --git a/understanding/22/img/focus-indicator-checkboxs.png b/understanding/22/img/focus-indicator-checkboxs.png new file mode 100644 index 0000000000..933ef9982d Binary files /dev/null and b/understanding/22/img/focus-indicator-checkboxs.png differ diff --git a/understanding/22/img/focus-indicator-checked.png b/understanding/22/img/focus-indicator-checked.png new file mode 100644 index 0000000000..a3ed176405 Binary files /dev/null and b/understanding/22/img/focus-indicator-checked.png differ diff --git a/understanding/22/img/focus-indicator-circle.png b/understanding/22/img/focus-indicator-circle.png new file mode 100644 index 0000000000..61fccb8621 Binary files /dev/null and b/understanding/22/img/focus-indicator-circle.png differ diff --git a/understanding/22/img/focus-indicator-custom-shapes-inset.png b/understanding/22/img/focus-indicator-custom-shapes-inset.png new file mode 100644 index 0000000000..7068585a83 Binary files /dev/null and b/understanding/22/img/focus-indicator-custom-shapes-inset.png differ diff --git a/understanding/22/img/focus-indicator-custom-shapes-side-highlights.png b/understanding/22/img/focus-indicator-custom-shapes-side-highlights.png new file mode 100644 index 0000000000..4c46f1213b Binary files /dev/null and b/understanding/22/img/focus-indicator-custom-shapes-side-highlights.png differ diff --git a/understanding/22/img/focus-indicator-custom-shapes.html b/understanding/22/img/focus-indicator-custom-shapes.html new file mode 100644 index 0000000000..25f4a1ad94 --- /dev/null +++ b/understanding/22/img/focus-indicator-custom-shapes.html @@ -0,0 +1,71 @@ + + + Figure source: Focus Indicator Custom Shapes + + +
      +

      Figure source: Focus Indicator Custom Shapes

      +

      All examples are 90px x 30px buttons, so have 480px2 minimum indicator area.

      +
      +

      Passes: 3px inset, 3px thick

      +

      Indicator area = (84 * 24) - (78 * 18) = 612px2 > 480px2

      + + + +
      +
      +

      Passes: 2 28px x 9px rectangles

      +

      Indicator area = 2 * 28 * 9 = 504px2 > 480px2

      + + + +
      +
      + + diff --git a/understanding/22/img/focus-indicator-extra-outline.png b/understanding/22/img/focus-indicator-extra-outline.png new file mode 100644 index 0000000000..1810f48f4b Binary files /dev/null and b/understanding/22/img/focus-indicator-extra-outline.png differ diff --git a/understanding/22/img/focus-indicator-good-adjacent-bad-change.png b/understanding/22/img/focus-indicator-good-adjacent-bad-change.png new file mode 100644 index 0000000000..b2fbb271f1 Binary files /dev/null and b/understanding/22/img/focus-indicator-good-adjacent-bad-change.png differ diff --git a/understanding/22/img/focus-indicator-good-change-bad-adjacent.png b/understanding/22/img/focus-indicator-good-change-bad-adjacent.png new file mode 100644 index 0000000000..49fc670d73 Binary files /dev/null and b/understanding/22/img/focus-indicator-good-change-bad-adjacent.png differ diff --git a/understanding/22/img/focus-indicator-group-and-star.svg b/understanding/22/img/focus-indicator-group-and-star.svg new file mode 100644 index 0000000000..f73f7c2172 --- /dev/null +++ b/understanding/22/img/focus-indicator-group-and-star.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/understanding/22/img/focus-indicator-group-outline.svg b/understanding/22/img/focus-indicator-group-outline.svg new file mode 100644 index 0000000000..860e8562a6 --- /dev/null +++ b/understanding/22/img/focus-indicator-group-outline.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/understanding/22/img/focus-indicator-icon.png b/understanding/22/img/focus-indicator-icon.png new file mode 100644 index 0000000000..28d8903d01 Binary files /dev/null and b/understanding/22/img/focus-indicator-icon.png differ diff --git a/understanding/22/img/focus-indicator-innerline-strong.png b/understanding/22/img/focus-indicator-innerline-strong.png new file mode 100644 index 0000000000..0bca39f28f Binary files /dev/null and b/understanding/22/img/focus-indicator-innerline-strong.png differ diff --git a/understanding/22/img/focus-indicator-innerline.png b/understanding/22/img/focus-indicator-innerline.png new file mode 100644 index 0000000000..10168a6193 Binary files /dev/null and b/understanding/22/img/focus-indicator-innerline.png differ diff --git a/understanding/22/img/focus-indicator-inside.png b/understanding/22/img/focus-indicator-inside.png new file mode 100644 index 0000000000..1ab9cfdc0e Binary files /dev/null and b/understanding/22/img/focus-indicator-inside.png differ diff --git a/understanding/22/img/focus-indicator-non-contrast.png b/understanding/22/img/focus-indicator-non-contrast.png new file mode 100644 index 0000000000..c4cabe344c Binary files /dev/null and b/understanding/22/img/focus-indicator-non-contrast.png differ diff --git a/understanding/22/img/focus-indicator-non-text-contrast.html b/understanding/22/img/focus-indicator-non-text-contrast.html new file mode 100644 index 0000000000..6f2e850483 --- /dev/null +++ b/understanding/22/img/focus-indicator-non-text-contrast.html @@ -0,0 +1,47 @@ + + + Figure source: Focus Indicator Custom Shapes + + +
      +

      Figure source: Focus Indicator Relationship with Non-text Contrast

      +
      +

      Passes Focus Appearance, fails Non-text Contrast

      + + + +
      +
      +

      Passes Non-text Contrast, fails Focus Appearance

      + + + +
      +
      + + diff --git a/understanding/22/img/focus-indicator-ntc-comparison1.png b/understanding/22/img/focus-indicator-ntc-comparison1.png new file mode 100644 index 0000000000..fc0a1fa38f Binary files /dev/null and b/understanding/22/img/focus-indicator-ntc-comparison1.png differ diff --git a/understanding/22/img/focus-indicator-offset-types.html b/understanding/22/img/focus-indicator-offset-types.html new file mode 100644 index 0000000000..8f3d1e45da --- /dev/null +++ b/understanding/22/img/focus-indicator-offset-types.html @@ -0,0 +1,91 @@ + + + Figure source: Focus Indicator Offset Types + + +
      +

      Figure source: Focus Indicator Offset Types

      +
      + +
      +
      + + + + +
      +
      + + diff --git a/understanding/22/img/focus-indicator-offset-types.png b/understanding/22/img/focus-indicator-offset-types.png new file mode 100644 index 0000000000..2ba42891ca Binary files /dev/null and b/understanding/22/img/focus-indicator-offset-types.png differ diff --git a/understanding/22/img/focus-indicator-outerline.png b/understanding/22/img/focus-indicator-outerline.png new file mode 100644 index 0000000000..873775989e Binary files /dev/null and b/understanding/22/img/focus-indicator-outerline.png differ diff --git a/understanding/22/img/focus-indicator-select.png b/understanding/22/img/focus-indicator-select.png new file mode 100644 index 0000000000..089e1d6667 Binary files /dev/null and b/understanding/22/img/focus-indicator-select.png differ diff --git a/understanding/22/img/focus-indicator-solid-border.png b/understanding/22/img/focus-indicator-solid-border.png new file mode 100644 index 0000000000..7f8e0f1db3 Binary files /dev/null and b/understanding/22/img/focus-indicator-solid-border.png differ diff --git a/understanding/22/img/focus-indicator-solid-border.svg b/understanding/22/img/focus-indicator-solid-border.svg new file mode 100644 index 0000000000..ce4f80676f --- /dev/null +++ b/understanding/22/img/focus-indicator-solid-border.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/understanding/22/img/focus-indicator-solid-outline.png b/understanding/22/img/focus-indicator-solid-outline.png new file mode 100644 index 0000000000..dcadc0b8ec Binary files /dev/null and b/understanding/22/img/focus-indicator-solid-outline.png differ diff --git a/understanding/22/img/focus-indicator-solid-outline.svg b/understanding/22/img/focus-indicator-solid-outline.svg new file mode 100644 index 0000000000..433a4c3673 --- /dev/null +++ b/understanding/22/img/focus-indicator-solid-outline.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/understanding/22/img/focus-indicator-star-shadow.png b/understanding/22/img/focus-indicator-star-shadow.png new file mode 100644 index 0000000000..8717f2642a Binary files /dev/null and b/understanding/22/img/focus-indicator-star-shadow.png differ diff --git a/understanding/22/img/focus-indicator-star-with-abutted-line.png b/understanding/22/img/focus-indicator-star-with-abutted-line.png new file mode 100644 index 0000000000..f466e7cfcf Binary files /dev/null and b/understanding/22/img/focus-indicator-star-with-abutted-line.png differ diff --git a/understanding/22/img/focus-indicator-star-with-abutted-line.svg b/understanding/22/img/focus-indicator-star-with-abutted-line.svg new file mode 100644 index 0000000000..595e447fed --- /dev/null +++ b/understanding/22/img/focus-indicator-star-with-abutted-line.svg @@ -0,0 +1,7 @@ + + + + + + + \ No newline at end of file diff --git a/understanding/22/img/focus-indicator-star-with-focus.png b/understanding/22/img/focus-indicator-star-with-focus.png new file mode 100644 index 0000000000..e1c82cbdc2 Binary files /dev/null and b/understanding/22/img/focus-indicator-star-with-focus.png differ diff --git a/understanding/22/img/focus-indicator-star-with-focus.svg b/understanding/22/img/focus-indicator-star-with-focus.svg new file mode 100644 index 0000000000..496f7543bf --- /dev/null +++ b/understanding/22/img/focus-indicator-star-with-focus.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/understanding/22/img/focus-indicator-star-with-light-focus.png b/understanding/22/img/focus-indicator-star-with-light-focus.png new file mode 100644 index 0000000000..e37af2db88 Binary files /dev/null and b/understanding/22/img/focus-indicator-star-with-light-focus.png differ diff --git a/understanding/22/img/focus-indicator-star-with-light-focus.svg b/understanding/22/img/focus-indicator-star-with-light-focus.svg new file mode 100644 index 0000000000..02e0d0e6dc --- /dev/null +++ b/understanding/22/img/focus-indicator-star-with-light-focus.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/understanding/22/img/focus-indicator-star-without-focus.png b/understanding/22/img/focus-indicator-star-without-focus.png new file mode 100644 index 0000000000..74ad6604c0 Binary files /dev/null and b/understanding/22/img/focus-indicator-star-without-focus.png differ diff --git a/understanding/22/img/focus-indicator-star-without-focus.svg b/understanding/22/img/focus-indicator-star-without-focus.svg new file mode 100644 index 0000000000..67157b1a35 --- /dev/null +++ b/understanding/22/img/focus-indicator-star-without-focus.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/understanding/22/img/focus-indicator-strong-dashed-border.png b/understanding/22/img/focus-indicator-strong-dashed-border.png new file mode 100644 index 0000000000..12589b03bd Binary files /dev/null and b/understanding/22/img/focus-indicator-strong-dashed-border.png differ diff --git a/understanding/22/img/focus-indicator-strong-dashed-border.svg b/understanding/22/img/focus-indicator-strong-dashed-border.svg new file mode 100644 index 0000000000..8852e04f03 --- /dev/null +++ b/understanding/22/img/focus-indicator-strong-dashed-border.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/understanding/22/img/focus-indicator-strong.png b/understanding/22/img/focus-indicator-strong.png new file mode 100644 index 0000000000..0042c3157a Binary files /dev/null and b/understanding/22/img/focus-indicator-strong.png differ diff --git a/understanding/22/img/focus-indicator-thick-non-contrast.png b/understanding/22/img/focus-indicator-thick-non-contrast.png new file mode 100644 index 0000000000..43f0d7fe48 Binary files /dev/null and b/understanding/22/img/focus-indicator-thick-non-contrast.png differ diff --git a/understanding/22/img/focus-indicator-thick-short-side.png b/understanding/22/img/focus-indicator-thick-short-side.png new file mode 100644 index 0000000000..b72d6de934 Binary files /dev/null and b/understanding/22/img/focus-indicator-thick-short-side.png differ diff --git a/understanding/22/img/focus-indicator-thin-non-contrast.png b/understanding/22/img/focus-indicator-thin-non-contrast.png new file mode 100644 index 0000000000..865cad28ec Binary files /dev/null and b/understanding/22/img/focus-indicator-thin-non-contrast.png differ diff --git a/understanding/22/img/focus-indicator-two-color-thick.png b/understanding/22/img/focus-indicator-two-color-thick.png new file mode 100644 index 0000000000..aea14637c4 Binary files /dev/null and b/understanding/22/img/focus-indicator-two-color-thick.png differ diff --git a/understanding/22/img/focus-indicator-two-color-thin.png b/understanding/22/img/focus-indicator-two-color-thin.png new file mode 100644 index 0000000000..8d5ff4db69 Binary files /dev/null and b/understanding/22/img/focus-indicator-two-color-thin.png differ diff --git a/understanding/22/img/focus-indicator-two-color.html b/understanding/22/img/focus-indicator-two-color.html new file mode 100644 index 0000000000..5f145c335c --- /dev/null +++ b/understanding/22/img/focus-indicator-two-color.html @@ -0,0 +1,46 @@ + + + Figure source: Focus Indicator Two Color + + +
      +

      Figure source: Focus Indicator Two Color

      +
      +

      Passes: the 2px thick black line passes

      + + +
      +
      +

      Fails: the indicator is 2px thick, but the part of the indicator meeting change contrast is only 1px thick

      + + +
      +
      + + diff --git a/understanding/22/img/focus-indicator-underline.png b/understanding/22/img/focus-indicator-underline.png new file mode 100644 index 0000000000..ebebb58518 Binary files /dev/null and b/understanding/22/img/focus-indicator-underline.png differ diff --git a/understanding/22/img/focus-indicator-weak-dashed-border.png b/understanding/22/img/focus-indicator-weak-dashed-border.png new file mode 100644 index 0000000000..08cde7c6a9 Binary files /dev/null and b/understanding/22/img/focus-indicator-weak-dashed-border.png differ diff --git a/understanding/22/img/focus-indicator-weak-dashed-border.svg b/understanding/22/img/focus-indicator-weak-dashed-border.svg new file mode 100644 index 0000000000..1600f1f080 --- /dev/null +++ b/understanding/22/img/focus-indicator-weak-dashed-border.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/understanding/22/img/focus-indicator-whole-star.png b/understanding/22/img/focus-indicator-whole-star.png new file mode 100644 index 0000000000..dd15c3bbd2 Binary files /dev/null and b/understanding/22/img/focus-indicator-whole-star.png differ diff --git a/understanding/22/img/focus-indicator-whole-star.svg b/understanding/22/img/focus-indicator-whole-star.svg new file mode 100644 index 0000000000..b7cbfe4f92 --- /dev/null +++ b/understanding/22/img/focus-indicator-whole-star.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/understanding/22/img/focus-indicators-passing.png b/understanding/22/img/focus-indicators-passing.png new file mode 100644 index 0000000000..01fb3531c0 Binary files /dev/null and b/understanding/22/img/focus-indicators-passing.png differ diff --git a/understanding/22/img/focus-inline-link-outline.png b/understanding/22/img/focus-inline-link-outline.png new file mode 100644 index 0000000000..8012eed63f Binary files /dev/null and b/understanding/22/img/focus-inline-link-outline.png differ diff --git a/understanding/22/img/focus-inline-link.png b/understanding/22/img/focus-inline-link.png new file mode 100644 index 0000000000..f58e7671a5 Binary files /dev/null and b/understanding/22/img/focus-inline-link.png differ diff --git a/understanding/22/img/target-dropdown.afdesign b/understanding/22/img/target-dropdown.afdesign new file mode 100644 index 0000000000..1c8e08e9bc Binary files /dev/null and b/understanding/22/img/target-dropdown.afdesign differ diff --git a/understanding/22/img/target-dropdown.png b/understanding/22/img/target-dropdown.png new file mode 100644 index 0000000000..cd1ec5a3a6 Binary files /dev/null and b/understanding/22/img/target-dropdown.png differ diff --git a/understanding/22/img/target-dropdown.svg b/understanding/22/img/target-dropdown.svg new file mode 100644 index 0000000000..69c14bcf1d --- /dev/null +++ b/understanding/22/img/target-dropdown.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/understanding/22/img/target-large-small-clipping.afdesign b/understanding/22/img/target-large-small-clipping.afdesign new file mode 100644 index 0000000000..7147bb94b0 Binary files /dev/null and b/understanding/22/img/target-large-small-clipping.afdesign differ diff --git a/understanding/22/img/target-large-small-clipping.png b/understanding/22/img/target-large-small-clipping.png new file mode 100644 index 0000000000..cbb4c39844 Binary files /dev/null and b/understanding/22/img/target-large-small-clipping.png differ diff --git a/understanding/22/img/target-large-small-clipping.svg b/understanding/22/img/target-large-small-clipping.svg new file mode 100644 index 0000000000..7513c40b4d --- /dev/null +++ b/understanding/22/img/target-large-small-clipping.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/understanding/22/img/target-large-small-touching.afdesign b/understanding/22/img/target-large-small-touching.afdesign new file mode 100644 index 0000000000..43afbd3e00 Binary files /dev/null and b/understanding/22/img/target-large-small-touching.afdesign differ diff --git a/understanding/22/img/target-large-small-touching.png b/understanding/22/img/target-large-small-touching.png new file mode 100644 index 0000000000..d54240b8af Binary files /dev/null and b/understanding/22/img/target-large-small-touching.png differ diff --git a/understanding/22/img/target-large-small-touching.svg b/understanding/22/img/target-large-small-touching.svg new file mode 100644 index 0000000000..8a05adbd26 --- /dev/null +++ b/understanding/22/img/target-large-small-touching.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/understanding/22/img/target-size-basic.afdesign b/understanding/22/img/target-size-basic.afdesign new file mode 100644 index 0000000000..533abaf054 Binary files /dev/null and b/understanding/22/img/target-size-basic.afdesign differ diff --git a/understanding/22/img/target-size-basic.png b/understanding/22/img/target-size-basic.png new file mode 100644 index 0000000000..92dc95b80c Binary files /dev/null and b/understanding/22/img/target-size-basic.png differ diff --git a/understanding/22/img/target-size-basic.svg b/understanding/22/img/target-size-basic.svg new file mode 100644 index 0000000000..274c2337ef --- /dev/null +++ b/understanding/22/img/target-size-basic.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/understanding/22/img/target-size-bounding-boxes.afdesign b/understanding/22/img/target-size-bounding-boxes.afdesign new file mode 100644 index 0000000000..378e8214b6 Binary files /dev/null and b/understanding/22/img/target-size-bounding-boxes.afdesign differ diff --git a/understanding/22/img/target-size-bounding-boxes.png b/understanding/22/img/target-size-bounding-boxes.png new file mode 100644 index 0000000000..35f8b9aa51 Binary files /dev/null and b/understanding/22/img/target-size-bounding-boxes.png differ diff --git a/understanding/22/img/target-size-bounding-boxes.svg b/understanding/22/img/target-size-bounding-boxes.svg new file mode 100644 index 0000000000..9aca20ca03 --- /dev/null +++ b/understanding/22/img/target-size-bounding-boxes.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/understanding/22/img/target-size-skewed.afdesign b/understanding/22/img/target-size-skewed.afdesign new file mode 100644 index 0000000000..5061a64bc4 Binary files /dev/null and b/understanding/22/img/target-size-skewed.afdesign differ diff --git a/understanding/22/img/target-size-skewed.png b/understanding/22/img/target-size-skewed.png new file mode 100644 index 0000000000..22153e6b72 Binary files /dev/null and b/understanding/22/img/target-size-skewed.png differ diff --git a/understanding/22/img/target-size-skewed.svg b/understanding/22/img/target-size-skewed.svg new file mode 100644 index 0000000000..9f6987679f --- /dev/null +++ b/understanding/22/img/target-size-skewed.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/understanding/22/img/target-size-undersized-rounded.afdesign b/understanding/22/img/target-size-undersized-rounded.afdesign new file mode 100644 index 0000000000..0d14bf90a0 Binary files /dev/null and b/understanding/22/img/target-size-undersized-rounded.afdesign differ diff --git a/understanding/22/img/target-size-undersized-rounded.png b/understanding/22/img/target-size-undersized-rounded.png new file mode 100644 index 0000000000..3d92a1b887 Binary files /dev/null and b/understanding/22/img/target-size-undersized-rounded.png differ diff --git a/understanding/22/img/target-size-undersized-rounded.svg b/understanding/22/img/target-size-undersized-rounded.svg new file mode 100644 index 0000000000..a308f28063 --- /dev/null +++ b/understanding/22/img/target-size-undersized-rounded.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/understanding/22/img/target-spacing-toolbar.afdesign b/understanding/22/img/target-spacing-toolbar.afdesign new file mode 100644 index 0000000000..bf90181127 Binary files /dev/null and b/understanding/22/img/target-spacing-toolbar.afdesign differ diff --git a/understanding/22/img/target-spacing-toolbar.png b/understanding/22/img/target-spacing-toolbar.png new file mode 100644 index 0000000000..895e340014 Binary files /dev/null and b/understanding/22/img/target-spacing-toolbar.png differ diff --git a/understanding/22/img/target-spacing-toolbar.svg b/understanding/22/img/target-spacing-toolbar.svg new file mode 100644 index 0000000000..d488b49480 --- /dev/null +++ b/understanding/22/img/target-spacing-toolbar.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/understanding/22/img/target-text-buttons-single-row.afdesign b/understanding/22/img/target-text-buttons-single-row.afdesign new file mode 100644 index 0000000000..a6d9f87570 Binary files /dev/null and b/understanding/22/img/target-text-buttons-single-row.afdesign differ diff --git a/understanding/22/img/target-text-buttons-single-row.png b/understanding/22/img/target-text-buttons-single-row.png new file mode 100644 index 0000000000..d1971fe4e4 Binary files /dev/null and b/understanding/22/img/target-text-buttons-single-row.png differ diff --git a/understanding/22/img/target-text-buttons-single-row.svg b/understanding/22/img/target-text-buttons-single-row.svg new file mode 100644 index 0000000000..5d2dbfb405 --- /dev/null +++ b/understanding/22/img/target-text-buttons-single-row.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/understanding/22/img/target-text-buttons-two-rows.afdesign b/understanding/22/img/target-text-buttons-two-rows.afdesign new file mode 100644 index 0000000000..a9f3d1dbaa Binary files /dev/null and b/understanding/22/img/target-text-buttons-two-rows.afdesign differ diff --git a/understanding/22/img/target-text-buttons-two-rows.png b/understanding/22/img/target-text-buttons-two-rows.png new file mode 100644 index 0000000000..bb78992288 Binary files /dev/null and b/understanding/22/img/target-text-buttons-two-rows.png differ diff --git a/understanding/22/img/target-text-buttons-two-rows.svg b/understanding/22/img/target-text-buttons-two-rows.svg new file mode 100644 index 0000000000..9f856f9a66 --- /dev/null +++ b/understanding/22/img/target-text-buttons-two-rows.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/understanding/22/redundant-entry.html b/understanding/22/redundant-entry.html new file mode 100644 index 0000000000..4ef19cd3fd --- /dev/null +++ b/understanding/22/redundant-entry.html @@ -0,0 +1,118 @@ + + + + + Understanding Redundant Entry + + + +

      Understanding Redundant Entry

      + +
      +

      In brief

      +
      +
      Goal
      Make it easier for users to complete multi-step processes.
      +
      What to do
      Don't ask for the same information twice in the same session.
      +
      Why it's important
      Some people with cognitive disabilities have difficulty remembering what they entered before.
      +
      +
      + +
      + +

      Intent of Redundant Entry

      + +

      The intent of this Success Criterion is to ensure that users can successfully complete multi-step processes. It reduces cognitive effort where information is asked for more than once during a process. It also reduces the need to recall information provided in a previous step.

      + +

      Information that is required to be remembered for input can pose a significant barrier to users with cognitive or memory difficulties. All users experience a natural gradual mental fatigue as they proceed through steps in a process. This fatigue is accelerated by the stress of recalling information from short-term working memory. Users with learning, and cognitive disabilities are highly susceptible to mental fatigue.

      + +

      Requiring people to recall information previously entered can cause them to give up or re-enter the same information incorrectly. The autocomplete feature of browsers is not considered sufficient because it is the content (the web site) that needs to provide the stored information for a redundant entry, or avoid asking for the same information again.

      + +

      This Success Criterion does not add a requirement to store information between sessions. A process is defined on the basis of an activity and is not applicable when a user returns after closing a session or navigating away. However, a process can run across different domains, so if a check-out process includes a 3rd party payment provider, that would be in scope.

      + +

      The term "available to select" is not prescriptive. The term allows authors to develop techniques where auto-population is not possible. It can include allowing the user to:

      + +
        +
      • select and populate a field, including from a drop-down;
      • +
      • select text from the page and copy it into an input;
      • +
      • tick a checkbox to populate inputs with the same values as previously entered (e.g., my billing address is the same as my shipping address).
      • +
      + +

      Data which is "available to select" would need to be on the same page. Ideally, it would be visible by default and closely associated with the input where the data is required. However, it could be elsewhere on a page, including within a show/hide component.

      + +

      This Success Criterion does not apply if data is provided by the user with a different method, such as uploading a resume in a document format.

      + +

      This Success Criterion does not impact Accessible Authentication (Minimum), for which allowing auto-filling of passwords is a sufficient technique. In that case the filling is performed by the user's browser. Redundant Entry is asking for the website content to make the previous entry available, but not between sessions or for essential purposes such as asking for a password.

      + +

      This criterion does not include requirements or exceptions specific to privacy or personally identifiable information (PII), but when implementing techniques such as auto-population, authors should ensure data protection when storing information even temporarily during a process. It is possible to eliminate redundant entry in ways that do not introduce additional privacy risks, but it is also possible that a poor implementation (for meeting this criterion) could leak additional PII.

      + +

      Exceptions

      + +

      There are exceptions for:

      +
        +
      • Essential uses of input re-entry for things like memory games which would be invalidated if the previous answers were supplied.
      • +
      • Security measures such as preventing a password string from being shown or copied. When creating a password, it should be a unique and complex string and therefore cannot be validated by the author. If the system requires the user to manually create a password that is not displayed, having users re-validate their new string is allowed as an exception.
      • +
      • When the previously entered information is no longer valid, it can be requested that the user enter that information again.
      • +
      + +
      +
      +

      Benefits of Redundant Entry

      + +
        +
      • Users with cognitive disabilities experience short-term, working memory difficulty. Not having to repeatedly remember particular information reduces stress and the likelihood of mistakes.
      • +
      • Users who experience difficulty forming new memories, recalling information, and other functions related to cognition can complete processes without having to unnecessarily rely on their memory.
      • +
      • Users with mobility impairments, for example using switch control or voice input, benefit from a reduced need for text entry.
      • +
      + +
      + +
      +

      Examples of Redundant Entry

      + +
        +
      • A form requests the user’s corporate identification number (ID) in the first step of a process to purchase a new computer. In the 3rd step the user is asked to confirm that the computer will belong to the user (rather than a colleague), and re-shows the ID. It allows the user to change the ID, but defaults to the previously entered one.
      • +
      • A form on an e-commerce website allows the user to confirm that the billing address and delivery address are the same address.
      • +
      • A search results page pre-fills the search input with the previously entered search term in the same process.
      • +
      + +
      + +
      + +

      Techniques for Redundant Entry

      + +
      + +

      Sufficient Techniques for Redundant Entry

      + + + +
      + +
      +

      Additional Techniques (Advisory) for Redundant Entry

      + +
      + +
      +

      Failures for Redundant Entry

      + +
      + +
      + +
      +

      Resources

      + + + +
      + + + diff --git a/understanding/22/target-size-minimum.html b/understanding/22/target-size-minimum.html new file mode 100644 index 0000000000..70048d3c36 --- /dev/null +++ b/understanding/22/target-size-minimum.html @@ -0,0 +1,199 @@ + + + + + Understanding Target Size (Minimum) + + + +

      Understanding Target Size (Minimum)

      + +
      +

      In brief

      +
      +
      Goal
      Make controls easier to activate.
      +
      What to do
      Ensure targets meet a minimum size or have sufficient spacing around them.
      +
      Why it's important
      Some people with physical impairments cannot click small buttons that are close together.
      +
      +
      + +
      +

      Intent of Target Size (Minimum)

      + +

      The intent of this Success Criterion is to help ensure targets can be easily activated without accidentally activating an adjacent target. Users with dexterity limitations and those who have difficulty with fine motor movement find it difficult to accurately activate small targets when there are other targets that are too close. Providing sufficient size, or sufficient spacing between targets, will reduce the likelihood of accidentally activating the wrong control.

      +

      Disabilities addressed by this requirement include hand tremors, spasticity, and quadriplegia. Some people with disabilities use specialized input devices instead of a computer mouse or trackpad. Typically these types of input device do not provide as much accuracy as mainstream pointing devices. Meeting this requirement also ensures that touchscreen interfaces are easier to use.

      +

      This Success Criterion defines a minimum size and, if this can't be met, a minimum spacing. It is still possible to have very small, and difficult to activate, targets and meet the requirements of this Success Criterion, provided that the targets don't have any adjacent targets that are too close. However, using larger target sizes will help many people use targets more easily. As a best practice it is recommended to at least meet the minimum size requirement of the Success Criterion, regardless of spacing. For important links/controls, consider aiming for the stricter 2.5.5 Target Size (Enhanced).

      + +
      +

      Exceptions

      +

      The requirement is for targets to be at least 24 by 24 CSS pixels in size. There are five exceptions:

      + +
        +
      • Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target.
      • +
      • Equivalent: In cases where a target does not have a size equivalent to 24 by 24 CSS pixels, but there is another control that can achieve the underlying function that does meet the requirements of this success criterion, the target can be excepted based on the "Equivalent" exception.
      • +
      • Inline: The success criterion does not apply to inline targets in sentences, or where the size of the target is constrained by the line-height of non-target text. This exception is allowed because text reflow based on viewport size makes it impossible for authors to anticipate where links may be positioned relative to one another. Applying this success criterion when multiple links are embedded in blocks of smaller text often results in an undesirable design. It is more important to set the line height to a value that improves readability.
      • +
      • User agent control: Browsers have default renderings of some controls, such as the days of the month calendar in an <input type="date">. As long as the author has not modified the user agent default, the target size for a User agent control is excepted.
      • +
      • Essential: If the size and spacing of the targets is fundamental to the information being conveyed, the Essential exception applies. For example, in digital maps, the position of pins is analogous to the position of places shown on the map. If there are many pins close together, the spacing between pins and neighboring pins will often be below 24 CSS pixels. It is essential to show the pins at the correct map location, therefore the Essential exception applies. A similar example is an interactive data visualization where targets are necessarily dense. Another example is where jurisdictions legally require online forms to replicate paper forms, which can impose constraints on the size of targets. In such jurisdictions, any legal requirement to replicate small targets can be considered essential. When the "Essential" exception is applicable, authors are strongly encouraged to provide equivalent functionality through alternative means to the extent practical.
      • +
      +
      + +
      +

      Size requirement

      + +

      For a target to be "at least 24 by 24 CSS pixels", it must be possible to draw a solid 24 by 24 CSS pixel square, aligned to the horizontal and vertical axis such that the square is completely within the target (does not extend outside the target's area).

      + +
      + Three square boxes next to each other, each with a height and width of 24px +
      Where targets are a 24 by 24px square (and larger is better), they meet the size requirement of the criterion and pass (image shown to scale - see the scalable original version)
      +
      + +

      The 24 by 24px square has to be aligned with the page, although the target itself could be skewed.

      + +
      + A skewed rectangle that includes a 24 by 24px square within it. +
      So long as there is a solid 24 by 24px square within the target, it meets the size requirement of the criterion and passes (image shown to scale - see the scalable original version)
      +
      + +

      If a target is not large enough to allow for a 24 by 24px square to be drawn inside it, it is considered undersized, and does not pass the size requirement of the Success Criterion. However, if it has sufficient space around it without adjacent targets, it may still pass the criterion thanks to the spacing exception (below).

      + +
      + A circle with a diameter of 24px, but not filling up a 24px square. +
      The rounded corners do not leave sufficient space to draw a 24 by 24px square inside the target, making the target undersized. Depending on the spacing to other targets, it may still pass if it has sufficient clearance (image shown at 1:1 and 2:1 scale - see the scalable original version)
      +
      + +

      The requirement is independent of the zoom factor of the page; when users zoom in, the CSS pixel size of elements does not change. This means that authors cannot meet it by claiming that the target will have enough spacing or sufficient size if the user zooms into the page.

      + +

      The requirement does not apply to targets while they are obscured by content displayed as a result of a user interaction or scripted behavior of content, for example:

      + +
        +
      • interacting with a combobox shows a dropdown list of suggestions
      • +
      • activating a button displays a modal dialog
      • +
      • content displays a cookie banner after page load
      • +
      • content displays a "Take a survey" dialog after some period of user inactivity
      • +
      +

      The requirement does however apply to targets in any new content that appears on top of other content.

      + +

      While the Success Criterion primarily helps touch users by providing target sizing to prevent accidental triggering of adjacent targets, it is also useful for mouse or pen users. It reduces the chances of erroneous activation due to either a tremor or reduced precision, whether because of reduced fine motor control or input imprecision.

      + +
      +
      +

      Spacing

      + +

      When the minimum size for a target is not met, spacing can at least improve the user experience. There is less chance of accidentally activating a neighboring target if a target is not immediately adjacent to another. Touchscreen devices and user agents generally have internal heuristics to identify which link or control is closest to a user's touch interaction - this means that sufficient spacing between targets can work as effectively as a larger target size itself.

      + +

      When a target is smaller than 24 by 24 CSS pixels, it is undersized. In this case, we check if it at least has sufficient spacing by drawing a 24 CSS pixel diameter circle over the undersized target, centered on the target's bounding box. For rectangular targets, the bounding box coincides with the target itself – thus, the circle is placed on the center of the target. If the target is not rectangular – for instance, if the target is clipped, has rounded corners, or if it's a more complex clickable SVG shape – we need to first determine the bounding box, and then find the box's center. Note that for concave shapes, the center of the bounding box may be outside of the target itself. Now, we center the circle on the center of the bounding box.

      + +
      + Three undersized targets - a square target, a convex target, and a concave target; the concave and convex targets have a bounding box around them; all three targets have a 24 CSS pixel circle centered on the center of their bounding box +
      For a square/rectangular target, the 24 CSS pixel diameter circle is centered on the target itself. For convex and concave targets, it is centered on the bounding box of the shape. Note the concave target, where in this case the center of the bounding box is outside of the actual target (image shown to scale - see the scalable original version)
      +
      + +

      We repeat this process for all adjacent undersized targets. To determine if an undersized target has sufficient spacing (to pass this Success Criterion's spacing exception), we check that the 24 CSS pixel diameter circle of the target does not intersect another target or the circle of any other adjacent undersized targets.

      + +

      The following example shows three versions of a horizontal row of six icon-based buttons:

      +
        +
      • In the top row, the dimensions of each target are 24 by 24 CSS pixels, passing this Success Criterion.
      • +
      • In the second row, the same targets are only 20 by 20 CSS pixels, but have a 4 CSS pixel space between them – as the target size is below 24 by 24 CSS pixels, these need to be evaluated against the Success Criterion's spacing exception, and they pass.
      • +
      • In the last row, the targets are again 20 by 20 CSS pixels, but have no space between them – these fail the spacing exception. This is because, when drawing the 24 CSS pixel diameter circles over the targets, the circles intersect.
      • +
      + +
      + The first toolbar's targets have a dimension of 24 by 24 CSS pixels, so pass. The second toolbar, with smaller targets, shows 24 CSS pixel circles drawn on each target for assessment. The circles do not intersect and so the targets have enough space to pass. The third toolbar shows similar circles on the targets, but the circles intersect due to the lack of spacing between targets, so the toolbar fails. +
      Three rows of targets, illustrating two ways of meeting this Success Criterion and one way of failing it (image shown to scale - see the scalable original version)
      +
      +

      The next two illustrations show sets of buttons which are only 16 CSS pixels tall. In the first set, there are no targets immediately above or below the buttons, so they pass. In the second illustration, there are further buttons, and they have been stacked on top of one another, resulting in a fail.

      +
      + A row of buttons which are more than 44px wide and 16 CSS pixels high. There are no close targets above or below. The buttons are overlaid with the 24 CSS pixel diameter circles, and do not intersect each other nor any other targets. +
      While the height of the targets is only 16 CSS pixels, the lack of adjacent targets above and below means that the targets pass this Success Criterion (image shown to scale - see the scalable original version)
      +
      + +
      + Two rows of buttons only 16 CSS pixels high, with no spacing between them. The buttons are overlaid with the 24 CSS pixel diameter circles, and all the circles either overlap another circle, or another target. +
      Two rows of buttons, both with a height of only 16 CSS pixels. The rows are close, with only a 1 CSS pixel gap between them. This means that the 24 CSS pixel spacing circles of the targets in one row will intersect the targets (and their circles, depending on their respective widths) in the other line, thus failing the Success Criterion. Image shown to scale - see the scalable original version.
      +
      +

      The following two illustrations show how menu items can be adjusted to properly meet this requirement. In the first illustration, the About us menu has been activated, showing that each of the menu item targets has a 24 CSS pixel height (text and padding), and so passes. In the second illustration, the same menu is expanded, but the menu items only achieve 18 CSS pixels in height, and so fail.

      +
      + Two examples of a dropdown menu - a pass example with menu items 24 CSS pixels high, and a fail example with menu items only 18 CSS pixels high. One item has a 24 CSS pixel diameter circle which intersects adjacent targets. +
      The menu items with a height of 24 CSS pixels pass. For the menu items that are only 18 CSS pixels high, the 24 CSS pixel spacing circles of the targets in one row will intersect the adjacent menu item targets and circles, and fail (image shown to scale - see the scalable original version)
      +
      + +

      The following example has one large target (an image that links to a new page related to that image) and a very small second target (a control with a magnifier icon to open a zoomed-in preview, possibly in a modal, of the image).

      +

      In the top row, the small target overlaps - or, to be more technically accurate, clips - the large target. The small target itself has a size of 24 by 24 CSS pixels, so passes. In the second row, we see that if the second target is any smaller – in this case 16 by 16 CSS pixels – it fails the criterion, as the circle with a 24 CSS pixel diameter we draw over the small target will intersect the large target itself.

      + +
      + Two rows showing a small target clipping a large target +
      The 24 by 24 CSS pixel small target passes, while the 16 by 16 CSS pixel small target fails, since the 24 CSS pixel diameter circle used for undersized targets intersect the large target (image shown to scale - see the scalable original version)
      +
      + +

      In the following example, we have the same two targets – a large target and a small target. This time, the small target touches/abuts the large target. If the small target is smaller than 24 by 24 CSS pixels, the circle with a 24 CSS pixel diameter we draw over the small target will intersect the large target itself, failing the requirement. The undersized target must be spaced further away from the large target until its circle doesn't intersect the large target.

      + +
      + Two rows showing a small target and a large target touching/abutting +
      In the first row, the 16 by 16 CSS pixel target touching/abutting the large target fails, as its 24 CSS pixel diameter circle used for undersized targets intersects the large target. In the second row we see that the only way the undersized target can pass is by adding a 4 CSS pixel spacing gap between the targets (image shown to scale - see the scalable original version)
      +
      + +

      Users with different disabilities have different needs for control sizes. It can be beneficial to provide an option to increase the active target area without increasing the visible target size. Another option is to provide a mechanism to control the density of layout and thereby change target size or spacing, or both. This can be beneficial for a wide range of users. For example, users with visual field loss may prefer a more condensed layout with smaller sized controls while users with other forms of low vision may prefer large controls.

      +
      +
      + +
      +

      Benefits of Target Size (Minimum)

      +

      Having targets with sufficient size - or at least sufficient target spacing - can help all users who may have difficulty in confidently targeting or operating small controls. Users who benefit include, but are not limited to:

      +
        +
      • People who use a mobile device where the touch screen is the primary mode of interaction;
      • +
      • People using mouse, stylus or touch input who have mobility impairments such as hand tremors;
      • +
      • People using a device in environments where they are exposed to shaking such as public transportation;
      • +
      • Mouse users who have difficulty with fine motor movements;
      • +
      • People who access a device using one hand;
      • +
      • People with large fingers, or who are operating the device with only a part of their finger or knuckle.
      • +
      + +
      + +
      +

      Examples of Target Size (Minimum)

      + +
        +
      • Three buttons are on-screen and the target size of each button is 24 by 24 CSS pixels. Since the target size itself is 24 by 24 CSS pixels, no additional spacing is required, the Success Criterion passes.
      • +
      • A row of buttons, each of which has a horizontal width of more than 24 CSS pixels, a height of only 20 CSS pixels, and vertical margin of 4 CSS pixels above and below the row of buttons. Since there is sufficient spacing both above and below the row of buttons, the Success Criterion passes.
      • +
      • Links within a paragraph of text have varying target dimensions. Links within paragraphs of text do not need to meet the 24 by 24 CSS pixels requirements, so the Success Criterion passes.
      • +
      +
      + +
      + +

      Resources

      + +
      + +
      +

      Techniques for Target Size (Minimum)

      + + +
      +

      Sufficient Techniques for Target Size (Minimum)

      + + + +
      + +
      +

      Additional Techniques (Advisory) for Target Size (Minimum)

      + +
      + +
      +

      Failures for Target Size (Minimum)

      + +
      + +
      + + + diff --git a/understanding/about.html b/understanding/about.html new file mode 100644 index 0000000000..2da202d0c8 --- /dev/null +++ b/understanding/about.html @@ -0,0 +1,102 @@ + + + + + + + About WCAG Understanding Documents | WAI | W3C + + + + + + +
      + +
      +

      About WCAG Understanding Documents

      + +
      +

      About WCAG

      +

      Web Content Accessibility Guidelines (WCAG) provides requirements for making websites, applications, and other digital content accessible to people with disabilities. For an introduction to WCAG, supporting technical documents, and educational material, see WCAG 2 Overview.

      +

      There are additional resources that help you understand and implement WCAG. These Understanding documents are one type of resource. Others are explained in the WCAG 2 Documents.

      +
      +
      +

      About the Understanding Documents

      +

      WCAG Understanding documents are guides to understanding and implementing WCAG. They provide detailed explanations for + each guideline and each success criterion to help readers better understand the intent + of the success criteria. They include background information and technical details. They include techniques that are examples of ways to meet the success criteria. Each technique is linked to more details in a techniques page. Techniques are explained in Understanding Techniques for WCAG Success Criteria.

      +

      WCAG Understanding documents are not introductory resources. They are for people who want to understand WCAG more thoroughly. The WCAG Overview provides introductory information.

      + +
      +

      Structure of the Documents

      +

      Understanding Guideline pages include:

      +
        +
      • The intent
      • +
      • Any advisory techniques that are related + to the guideline and not specifically related to any of its success criteria
      • +
      +

      Understanding Success Criterion pages include:

      +
        +
      • The success criterion wording from WCAG
      • +
      • Intent of the success criterion
      • +
      • Benefits, how it helps people with disabilities
      • +
      • Examples
      • +
      • Related resources
      • +
      • Techniques +
          +
        • Sufficient techniques
        • +
        • Advisory techniques
        • +
        • Failures
        • +
        +
      • +
      • Key terms for this success criterion, from the WCAG Glossary
      • +
      +
      +
      + +
      +
      +

      Change Log

      +

      For a detailed view of recent changes to the informative documents see the github updates.

      +
      +
      + +
      +
      +

      Acknowledgements

      +
      +
      +
      +
      +
      + +
      + Back to Top + +
      + + + + diff --git a/understanding/conformance.html b/understanding/conformance.html index 450dda6c1d..8559cb484a 100644 --- a/understanding/conformance.html +++ b/understanding/conformance.html @@ -1,22 +1,22 @@ - + Understanding Conformance - +

      Understanding Conformance

      -

      All WCAG 2.0 Success Criteria are written as testable criteria for objectively determining - if content satisfies them. Testing the Success Criteria would involve a combination +

      All WCAG 2 success criteria are written as testable criteria for objectively determining + if content satisfies them. Testing the success criteria would involve a combination of automated testing and human evaluation. The content should be tested by those who understand how people with different types of disabilities use the Web.

      Testing and testable in the context refer to functional testing, that is verifying - that the content functions as expected, or in this case, that it satisfies the Success - Criteria. Although content may satisfy all Success Criteria, the content may not always + that the content functions as expected, or in this case, that it satisfies the success criteria. + Although content may satisfy all success criteria, the content may not always be usable by people with a wide variety of disabilities. Therefore, usability testing is recommended, in addition to the required functional testing. Usability testing aims to determine how well people can use the content for its intended purpose. It @@ -29,22 +29,21 @@

      Understanding Conformance

      What does conformance mean?

      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. + standard. In WCAG 2 the 'requirements' are the success criteria. To conform to WCAG + 2, you need to satisfy the success criteria, that is, there is no content which + violates the success criteria.

      -

      This means that if there is no content to which a success criterion applies, the success - criterion is satisfied. +

      This means that if there is no content to which a success criterion applies, the success criterion is satisfied.

      Most standards only have one level of conformance. In order to accommodate different situations that may require or allow greater levels of accessibility than others, - WCAG 2.0 has three levels of conformance, and therefore, three levels of Success Criteria. + WCAG 2 has three levels of conformance, and therefore, three levels of success criteria.

      @@ -54,7 +53,7 @@

      What does conformance mean?

      Understanding Conformance Requirements

      There are five requirements that must be met in order for content to be classified - as 'conforming' to WCAG 2.0. This section provides brief notes on those requirements. + as 'conforming' to WCAG 2. This section provides brief notes on those requirements. This section will be expanded over time to address questions that may arise or to provide new examples of ways to meet the different conformance requirements.

      @@ -63,12 +62,23 @@

      Understanding Conformance Requirements

      Understanding Requirement 1

      -

      +
      +

      Conformance Level: One of the following levels of conformance is met in full.

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

      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.

      + +

      The first requirement deals with the levels of conformance. It basically says that all information on a page conforms or has a - conforming alternate version that is available from the page. The requirement also explains that no conformance - is possible without at least satisfying all of the Level A Success Criteria. + conforming alternate version that is available from the page. The requirement also explains that no conformance + is possible without at least satisfying all of the Level A success criteria.

      The note points out that authors are encouraged to go beyond conformance to a particular @@ -86,7 +96,12 @@

      Understanding Requirement 1

      Understanding Requirement 2

      -

      +
      +

      Full pages: Conformance (and conformance level) is for full Web page(s) only, and cannot be achieved if part of a Web page is excluded.

      +

      For the purpose of determining conformance, alternatives to part of a page's content are considered part of the page when the alternatives can be obtained directly from the page, e.g., a long description or an alternative presentation of a video.

      +

      Authors of Web pages that cannot conform due to content outside of the author's control may consider a Statement of Partial Conformance.

      +

      A full page includes each variation of the page that is automatically presented by the page for various screen sizes (e.g. variations in a responsive Web page). Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform.

      +

      This provision simply requires that the whole page conform. Statements about "part of a page conforming" cannot be made. @@ -122,7 +137,10 @@

      Understanding Requirement 2

      Understanding Requirement 3

      -

      +
      +

      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.

      +

      This provision prevents a Web page that is part of a larger process from being considered conforming if the process overall is not. This would prevent a shopping site from @@ -136,9 +154,10 @@

      Understanding Requirement 3

      Understanding Requirement 4

      -

      +
      +

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

      -

      This conformance requirement is explained below under +

      This conformance requirement is explained below under Understanding Accessibility Support.

      @@ -148,7 +167,22 @@

      Understanding Requirement 4

      Understanding Requirement 5

      -

      +
      +

      Non-Interference: If technologies are used in a way that is not accessibility supported, or if they are used in a non-conforming way, then they do not block the ability of users to access the rest of the page. In addition, the Web page as a whole continues to meet the conformance requirements under each of the following conditions:

      +
        +
      1. when any technology that is not relied upon is turned on in a user agent,
      2. +
      3. when any technology that is not relied upon is turned off in a user agent, and
      4. +
      5. when any technology that is not relied upon is not supported by a user agent
      6. +
      +

      In addition, the following success criteria apply to all content on the page, including content that is not otherwise relied upon to meet conformance, because failure to meet them could interfere with any use of the page:

      +
        +
      • 1.4.2 - Audio Control,
      • +
      • 2.1.2 - No Keyboard Trap,
      • +
      • 2.3.1 - Three Flashes or Below Threshold, and
      • +
      • 2.2.2 - Pause, Stop, Hide.
      • +
      +

      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.

      +

      This basically says that technologies that are not accessibility supported can be used, as long as all the information is also available using technologies @@ -166,14 +200,14 @@

      Understanding Requirement 5

      There are four provisions that particularly deal with issues of interference with use of the page. These four are included in a note here. A note on each of the provisions - indicates that these Success Criteria need to be met for all content including content + indicates that these success criteria need to be met for all content including content created using technologies that are not accessibility supported.

      A Web page incorporates a new interactive graphic technology called "ZAP". Although - ZAP is accessibility-supported, the information that is presented in ZAP is also presented + ZAP is not accessibility-supported, the information that is presented in ZAP is also presented on the page in HTML, so ZAP is not relied upon. So, this page would pass conformance requirement #1. However, if the user tries to tab through the ZAP content, the focus drops into the ZAP object and gets stuck there. Once inside, there is nothing the @@ -201,7 +235,7 @@

      Understanding Conformance Claims

      Here is a claim which has been enhanced with schema.org metadata:

      -
      +     
       <div typeof="WebPage" vocab="http://schema.org/">
           <p property="accessibilitySummary">On 23 March 2009, all content available on
              the server at <a 
      @@ -281,11 +315,11 @@ 

      Partial conformance claims due to third party content

      -

      Information about any additional steps taken that go beyond the Success Criteria

      +

      Information about any additional steps taken that go beyond the success criteria

      One of the optional components of a conformance claim is "Information about any additional - steps taken that go beyond the Success Criteria to enhance accessibility." This can - include additional Success Criteria that have been met, advisory techniques that were + steps taken that go beyond the success criteria to enhance accessibility." This can + include additional success criteria that have been met, advisory techniques that were implemented, information about any additional protocols used to aid access for people with particular disabilities or needs, etc. Any information that would be useful to people in understanding the accessibility of the pages may be included. @@ -305,7 +339,7 @@

      Use of metadata to report conformance claims

      and tool developers are encouraged to support them.

      -

      In addition, metadata can be used to report conformance to individual Success Criteria +

      In addition, metadata can be used to report conformance to individual success criteria once Level A conformance has been achieved.

      @@ -390,7 +424,7 @@

      Examples of Conformance Claims including optional components

        -
      • The following additional Success Criteria have also been met: 1.1.2, 1.2.5, and 1.4.3. +
      • The following additional success criteria have also been met: 1.1.2, 1.2.5, and 1.4.3.
      • @@ -462,7 +496,35 @@

        Examples of Conformance Claims including optional components

        Techniques for Conformance Claims

        - +
        +
          +
        • + +
        • +
        • + +
        • +
        • + +
        • +
        • + +
        • +
        • + +
        • +
        • + +
        • +
        • + +
        • +
        • + +
        • +
        +
        +

        Advisory Techniques for Conformance Claims

        @@ -483,56 +545,56 @@

        Advisory Techniques for Conformance Claims

        Understanding Levels of Conformance

        -

        First, there are a number of conditions that must be met for a Success Criterion to +

        First, there are a number of conditions that must be met for a success criterion to be included at all. These include:

          -
        1. All Success Criteria must be +
        2. All success criteria must be important access issues for people with disabilities that address problems beyond the usability problems that might be faced by all users. In other words, the access issue must cause a proportionately greater problem for people with disabilities than it causes people without disabilities in order to be considered an accessibility issue (and covered under these accessibility guidelines).
        3. -
        4. All Success Criteria must also be testable. This is important since otherwise it would - not be possible to determine whether a page met or failed to meet the Success Criteria. - The Success Criteria can be tested by a combination of machine and human evaluation - as long as it is possible to determine whether a Success Criterion has been satisfied +
        5. All success criteria must also be testable. This is important since otherwise it would + not be possible to determine whether a page met or failed to meet the success criteria. + The success criteria can be tested by a combination of machine and human evaluation + as long as it is possible to determine whether a success criterion has been satisfied with a high level of confidence.
        -

        The Success Criteria were assigned to one of the three levels of conformance by the +

        The success criteria were assigned to one of the three levels of conformance by the working group after taking into consideration a wide range of interacting issues. Some of the common factors evaluated when setting the level included:

          -
        • whether the Success Criterion is - essential (in other words, if the Success Criterion isn't met, then even assistive technology +
        • whether the success criterion is + essential (in other words, if the success criterion isn't met, then even assistive technology can't make content accessible)
        • -
        • whether it is possible to satisfy the Success Criterion for - all Web sites and types of content that the Success Criteria would apply to (e.g., different topics, types of content, +
        • whether it is possible to satisfy the success criterion for + all Web sites and types of content that the success criterion would apply to (e.g., different topics, types of content, types of Web technology)
        • -
        • whether the Success Criterion requires skills that could - reasonably be achieved by the content creators (that is, the knowledge and skill to meet the Success Criteria could be acquired +
        • whether the success criterion requires skills that could + reasonably be achieved by the content creators (that is, the knowledge and skill to meet the success criterion could be acquired in a week's training or less)
        • -
        • whether the Success Criterion would impose limits on the "look & feel" and/or function +
        • whether the success criterion would impose limits on the "look & feel" and/or function of the Web page. (limits on function, presentation, freedom of expression, design - or aesthetic that the Success Criteria might place on authors) + or aesthetic that the success criterion might place on authors)
        • -
        • whether there are no workarounds if the Success Criterion is not met
        • +
        • whether there are no workarounds if the success criterion is not met
        @@ -542,9 +604,9 @@

        Understanding Levels of Conformance

        Understanding Accessibility Support

        -

        Many of the Success Criteria deal with providing accessibility through assistive technologies +

        Many of the success criteria deal with providing accessibility through assistive technologies or special accessibility features in mainstream user agents (for example, a 'show - captions' option in a media player). That is, the Success Criteria require that something + captions' option in a media player). That is, the success criteria require that something be done in the Web content that would make it possible for assistive technologies to successfully present the content's information to the user. For example, a picture that you were supposed to click on to go to a topic would not be accessible to a person @@ -698,7 +760,7 @@

        Technical Definition of "Accessibility Support"

        be true for a technology:

        -
        accessibility supported
        +
        accessibility supported
        @@ -737,7 +799,7 @@

        Understanding Accessibility-Supported Web Technology Uses

        accessibility-supported technology uses and this is allowed in meeting WCAG. Customers, companies or others may, however, specify that technology uses from a custom or public compilation be used. See - . + Documenting Accessibility Support for Uses of a Web Technology.

        @@ -788,16 +850,15 @@

        Accessibility Support Statements

        Understanding "Programmatically Determined"

        -

        Several Success Criteria require that content (or certain aspects of content) can +

        Several success criteria require that content (or certain aspects of content) can be "programmatically determined." This means that the content is authored in such a way that user agents, including assistive technologies, can access the information.

        -

        In order for content created with Web technologies (such as HTML, CSS, PDF, GIF, MPEG, - Flash etc.) to be accessible to people with different types of disabilities, it is +

        In order for content created with Web technologies (such as HTML, CSS, PDF, GIF, MPEG, etc.) to be accessible to people with different types of disabilities, it is essential that the technologies used work with the accessibility features of browsers and other user agents, including assistive technologies. In order for something to - meet a Success Criterion that requires it to be "programmatically determined," it + meet a success criterion that requires it to be "programmatically determined," it would need to be implemented using a technology that has assistive technology support.

        @@ -854,7 +915,7 @@

        Understanding Conforming Alternate Versions

        alternative version is defined as:

        -
        conforming alternate version
        +
        conforming alternate version

        This ensures that all of the information and all of the functionality that is on the pages inside of the scope of conformance is available on conforming Web pages. @@ -867,7 +928,7 @@

        Understanding Conforming Alternate Versions

        Why permit alternate versions?

        Why does WCAG permit conforming alternate versions of Web pages to be included in - conformance claims? That is, why include pages that do not satisfy the Success Criteria + conformance claims? That is, why include pages that do not satisfy the success criteria for a conformance level in the scope of conformance or a claim?

        @@ -882,7 +943,7 @@

        Why permit alternate versions?

        providing an accessible alternative page in technologies that are accessibility supported. Users for whom the new technology is adequately supported get the benefits of the new version. Authors who look ahead to future accessibility support can satisfy the - Success Criteria now with the alternate version page, and also work with the other + success criteria now with the alternate version page, and also work with the other page to build in future access when assistive technology (AT) support is available. @@ -917,7 +978,7 @@

        Why permit alternate versions?

      • Sometimes, the best experience for users with certain types of disabilities is provided by tailoring a Web page specifically to accommodate that disability. In such a situation, it may not be possible or practical to make the Web page accommodate all disabilities - by satisfying all of the Success Criteria. The alternate versions requirement permits + by satisfying all of the success criteria. The alternate versions requirement permits such specialized pages to be included within a conformance claim as long as there is a fully conformant 'alternate version' page.
      • @@ -936,10 +997,10 @@

        Why permit alternate versions?

      -

      A concern when permitting Web pages that do not satisfy the Success Criteria is that +

      A concern when permitting Web pages that do not satisfy the success criteria is that people with disabilities will encounter these non-conforming pages, not be able to access their content, and not be able to find the “conforming alternate version." - A key part of the Alternate Versions provision, therefore, is the ability to find + A key part of the alternate versions provision, therefore, is the ability to find the conforming page (the alternate version) from the non-conforming page when it is encountered. The conformance requirement that permits alternate pages, therefore, also requires a way for users to find the accessible version among the alternate versions. @@ -978,7 +1039,7 @@

      Techniques for Providing a Conforming Alternate Version

      Sufficient Techniques for Providing Conforming Alternative Versions of Web pages

      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 + 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 , particularly the "Other Techniques" section. @@ -988,7 +1049,7 @@

      Sufficient Techniques for Providing Conforming Alternative Versions of Web p
    • - Providing a link at the beginning of the nonconforming content that points to an alternate + Providing a link at the beginning of the nonconforming content that points to an alternate version that does meet WCAG 2.0 Level A Success Criteria @@ -996,7 +1057,7 @@

      Sufficient Techniques for Providing Conforming Alternative Versions of Web p
    • - Providing a link adjacent to or associated with a non-conforming object that links + Providing a link adjacent to or associated with a non-conforming object that links to a conforming alternate version @@ -1004,13 +1065,13 @@

      Sufficient Techniques for Providing Conforming Alternative Versions of Web p
    • - C29: Using a style switcher to provide a conforming alternate version + C29: Using a style switcher to provide a conforming alternate version
    • - SCR38: Creating a conforming alternate version for a web page designed with progressive + SCR38: Creating a conforming alternate version for a web page designed with progressive enhancement @@ -1018,7 +1079,7 @@

      Sufficient Techniques for Providing Conforming Alternative Versions of Web p
    • - Using .htaccess to ensure that the only way to access non-conforming content is from + Using .htaccess to ensure that the only way to access non-conforming content is from conforming content @@ -1026,7 +1087,7 @@

      Sufficient Techniques for Providing Conforming Alternative Versions of Web p
    • - SVR3: Using HTTP referer to ensure that the only way to access non-conforming content + SVR3: Using HTTP referer to ensure that the only way to access non-conforming content is from conforming content @@ -1034,7 +1095,7 @@

      Sufficient Techniques for Providing Conforming Alternative Versions of Web p
    • - Allowing users to provide preferences for the display of conforming alternate versions + Allowing users to provide preferences for the display of conforming alternate versions
    • @@ -1049,7 +1110,7 @@

      Common Failures Identified by the Working Group

    • - F19: Failure of Conformance Requirement 1 due to not providing a method for the user + F19: Failure of Conformance Requirement 1 due to not providing a method for the user to find the alternative conforming version of a non-conforming Web page @@ -1103,7 +1164,7 @@

      Examples of Conforming Alternate Versions

      site might limit their ability to address the needs of diverse office locations that have different technology bases and individual employees who use a wide variety of user agents and assistive technologies. To address these concerns, the company created - an alternate version of the content that met all Level A Success Criteria using a + an alternate version of the content that met all Level A success criteria using a more limited set of uses of accessibility-supported content technologies. The two versions link to each other. @@ -1145,7 +1206,7 @@

      Understanding "Web Page"

      The definition of a Web Page is:

      -
      web page
      +
      web page

      It is important to note that, in this standard, the term "Web page" includes much more than static HTML pages. The term 'Web Page' was used in these guidelines to allow diff --git a/understanding/documenting-accessibility-support.html b/understanding/documenting-accessibility-support.html index 185fa6c654..d9b619e75e 100644 --- a/understanding/documenting-accessibility-support.html +++ b/understanding/documenting-accessibility-support.html @@ -1,11 +1,11 @@ - + Documenting Accessibility Support for Uses of a Web Technology

      Documenting Accessibility Support for Uses of a Web Technology

      -

      The documentation of accessibility support for uses of a Web technology provides the information needed to determine whether it is possible to satisfy the WCAG 2.1 Success Criteria for a particular environment.

      +

      The documentation of accessibility support for uses of a Web technology provides the information needed to determine whether it is possible to satisfy the WCAG 2 success criteria for a particular environment.

      Accessibility Support documentation for uses of a Web technology includes the following information:

      • @@ -21,7 +21,7 @@

        Documenting Accessibility Support for Uses of a Web Technology

        Ways of using the technology that are supported by the user agent; ideally, there are ways to meet all of the success criteria, but exceptions should be noted.

      • -

        Known limitations of the user agent support for uses of the technology to meet Success Criteria

        +

        Known limitations of the user agent support for uses of the technology to meet success criteria

    • diff --git a/understanding/index.html b/understanding/index.html index d02fb9b2d4..163d088a0f 100644 --- a/understanding/index.html +++ b/understanding/index.html @@ -4,115 +4,49 @@ - Understanding WCAG 2.1 - - + Understanding WCAG 2.2 | WAI | W3C + + - -
      - -

      Understanding WCAG 2.1

      -

      Updated

      - - - -
      + + +
      - W3C® - (MIT, - ERCIM, - Keio, Beihang). +

      All WCAG 2.2 Understanding Docs

      + - W3C liability, - trademark and - document use - rules apply. -

      -
      -
      -
      -

      Abstract

      -

      Understanding WCAG 2.1 is a guide to understanding and using Web Content Accessibility Guidelines (WCAG) 2.1 [[WCAG21]]. It is part of a set of documents that support WCAG 2.1. Please note that the contents of this document are informative (they provide guidance), and not normative (they do not set requirements for conforming to WCAG 2.1). See Web Content Accessibility Guidelines (WCAG) Overview for an introduction to WCAG, supporting technical documents, and educational material.

      -
      -
      -

      Status of This Document

      -

      This is the official version of "Understanding WCAG 2.1", and is referenced by Web Content Accessibility Guidelines 2.1. This resource is maintained as needed to update interpretive guidance and reference techniques to meet the guidelines.

      -

      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

      -

      Understanding WCAG 2.1 is a guide to understanding and using Web Content Accessibility Guidelines 2.1 [[WCAG21]] Although the normative definition and requirements for WCAG 2.1 can all be found in the WCAG 2.1 document itself, the concepts and provisions may be new to some people. Understanding WCAG 2.1 provides a non-normative extended commentary on each guideline and each Success Criterion to help readers better understand the intent and how the guidelines and Success Criteria work together. It also provides examples of techniques or combinations of techniques that the Working Group has identified as being sufficient to meet each Success Criterion. Links are then provided to write-ups for each of the techniques.

      -
      -

      Relationship to Understanding WCAG 2.0

      -

      Understanding WCAG 2.0 [[UNDERSTANDING-WCAG20]] is a substantial resource to support Web Content Accessibility Guidelines 2.0 [[WCAG20]]. Understanding WCAG 2.1 is a parallel resource that supports the new success criteria in WCAG 2.1. At this stage, it only includes content related to new features of WCAG 2.0. Future versions may include content relevant to WCAG 2.0, depending on how WCAG 2.1 evolves and what structure is determined to provide optimal support.

      -

      Unlike Understanding WCAG 2.0, this document has not been published as a Technical Report. This change reduces the formality of the document and increases the ability of the Accessibility Guidelines Working Group to maintain the content and optimize the structure. The Working Group considers the content to be authoritative. If feedback indicates the need, the document could be published as a Technical Report in the future.

      -
      -
      -

      Structure of Understanding WCAG 2.1

      -

      This is not an introductory document. It is a detailed technical description of the guidelines and their Success Criteria. See Web Content Accessibility Guidelines (WCAG) Overview for an introduction to WCAG, supporting technical documents, and educational material.

      -

      Understanding WCAG 2.1 is organized by guideline. There is an Understanding Guideline X.X section for each guideline. The intent and any advisory techniques that are related to the guideline but not specifically related to any of its Success Criteria are listed there as well.

      -

      The Understanding Guidelines X.X section is then followed by a Understanding Success Criterion X.X.X section for each Success Criterion of that guideline. These sections each contain:

      -
        -
      • -

        The Success Criterion as it appears in WCAG 2.1

        -
      • -
      • -

        Intent of the Success Criterion

        -
      • -
      • -

        Benefits (how the Success Criterion helps people with disabilities)

        -
      • -
      • -

        Examples

        -
      • -
      • -

        Related Resources

        -
      • -
      • -

        Techniques or combinations of techniques that are sufficient to meet the guidelines

        -
      • -
      • -

        Failures of this Success Criterion

        -
      • -
      • -

        Additional advisory techniques that go beyond what is required to meet the Success Criterion but can be used to make some or all types of content more accessible. Use of advisory techniques does not impact the level of conformance claimed.

        -
      • -
      • -

        Key terms for this Success Criterion (taken from the WCAG 2.1 Glossary)

        -
      • -
      -

      Links are provided from each Guideline in WCAG 2.1 directly to each Understanding Guideline X.X in this document. Similarly, there is a link from each Success Criterion in WCAG 2.1 to the Understanding Success Criterion X.X.X section in this document.

      -
      -
      -

      Techniques for WCAG 2.1

      -

      Techniques specific to WCAG 2.1 are added to the the techniques for WCAG 2.0, it is one set. The Techniques change log lists the new techniques added since WCAG 2.1 was published.

      -
      - -
      -
      - -
      -

      Understanding documents change Log

      -

      A list of significantly updated Understanding documents since WCAG 2.1 was published:

      -
        -
      1. : Updated Understanding Non-text contrast, based on the changes from Pull request 550.
      2. -
      -

      For a more detailed view of recent changes to the informative documents see the github updates.

      -
      - -
      -

      Acknowledgements

      + + + Back to Top +
      + + diff --git a/understanding/intro.html b/understanding/intro.html index fb8cba8688..f4c29f8a8d 100644 --- a/understanding/intro.html +++ b/understanding/intro.html @@ -1,23 +1,23 @@ - + - Introduction to Understanding WCAG 2.1 + Introduction to Understanding WCAG 2 -

      Introduction to Understanding WCAG 2.1

      -

      Understanding WCAG 2.1 is an essential guide to understanding and using "Web Content Accessibility Guidelines 2.1". Although the normative definition and requirements for WCAG 2.1 can all be found in the WCAG 2.1 document itself, the concepts and provisions may be new to some people. Understanding WCAG 2.1 provides a non-normative extended commentary on each guideline and each Success Criterion to help readers better understand the intent and how the guidelines and Success Criteria work together. It also provides examples of techniques or combinations of techniques that the Working Group has identified as being sufficient to meet each Success Criterion. Links are then provided to write-ups for each of the techniques.

      -

      This is not an introductory document. It is a detailed technical description of the guidelines and their Success Criteria. See Web Content Accessibility Guidelines (WCAG) Overview for an introduction to WCAG, supporting technical documents, and educational material.

      -

      Understanding WCAG 2.1 is organized by guideline. There is an Understanding Guideline X.X section for each guideline. The intent and any advisory techniques that are related to the guideline but not specifically related to any of its Success Criteria are listed there as well.

      -

      The Understanding Guidelines X.X section is then followed by a Understanding Success Criterion X.X.X section for each Success Criterion of that guideline. These sections each contain:

      +

      Introduction to Understanding WCAG 2

      +

      Understanding WCAG 2 is an essential guide to understanding and using "Web Content Accessibility Guidelines 2". Although the normative definition and requirements for WCAG 2 can all be found in the WCAG 2 document itself, the concepts and provisions may be new to some people. Understanding WCAG 2 provides a non-normative extended commentary on each guideline and each success criterion to help readers better understand the intent and how the guidelines and success criteria work together. It also provides examples of techniques or combinations of techniques that the Working Group has identified as being sufficient to meet each success criterion. Links are then provided to write-ups for each of the techniques.

      +

      This is not an introductory document. It is a detailed technical description of the guidelines and their success criteria. See Web Content Accessibility Guidelines (WCAG) Overview for an introduction to WCAG, supporting technical documents, and educational material.

      +

      Understanding WCAG 2 is organized by guideline. There is an Understanding Guideline X.X section for each guideline. The intent and any advisory techniques that are related to the guideline but not specifically related to any of its success criteria are listed there as well.

      +

      The Understanding Guidelines X.X section is then followed by an Understanding success criterion X.X.X section for each success criterion of that guideline. These sections each contain:

      • -

        The Success Criterion as it appears in WCAG 2.1

        +

        The success criterion as it appears in WCAG 2

      • -

        Intent of the Success Criterion

        +

        Intent of the success criterion

      • -

        Benefits (how the Success Criterion helps people with disabilities)

        +

        Benefits (how the success criterion helps people with disabilities)

      • Examples

        @@ -29,21 +29,21 @@

        Introduction to Understanding WCAG 2.1

        Techniques or combinations of techniques that are sufficient to meet the guidelines

      • -

        Common failures of this Success Criterion

        +

        Common failures of this success criterion

      • -

        Additional advisory techniques that go beyond what is required to meet the Success Criterion but can be used to make some or all types of content more accessible. Use of advisory techniques does not impact the level of conformance claimed.

        +

        Additional advisory techniques that go beyond what is required to meet the success criterion but can be used to make some or all types of content more accessible. Use of advisory techniques does not impact the level of conformance claimed.

      • -

        Key terms for this Success Criterion (taken from the WCAG 2.1 Glossary)

        +

        Key terms for this success criterion (taken from the WCAG 2 Glossary)

      -

      Links are provided from each Guideline in WCAG 2.1 directly to each Understanding Guideline X.X in this document. Similarly, there is a link from each Success Criterion in WCAG 2.1 to the Understanding Success Criterion X.X.X section in this document.

      -

      For information about individual techniques, follow the links throughout this document to the techniques of interest in the Techniques for WCAG 2.1 document.

      +

      Links are provided from each Guideline in WCAG 2 directly to each Understanding Guideline X.X in this document. Similarly, there is a link from each success criterion in WCAG 2 to the Understanding Success Criterion X.X.X section in this document.

      +

      For information about individual techniques, follow the links throughout this document to the techniques of interest in the Techniques for WCAG 2 document.

      For links to information on different disabilities and assistive technologies see Disabilities on Wikipedia.

      Understanding the Four Principles of Accessibility

      -

      The guidelines and Success Criteria are organized around the following four principles, which lay the foundation necessary for anyone to access and use Web content. Anyone who wants to use the Web must have content that is:

      +

      The guidelines and success criteria are organized around the following four principles, which lay the foundation necessary for anyone to access and use Web content. Anyone who wants to use the Web must have content that is:

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

        @@ -79,30 +79,30 @@

        Understanding the Four Principles of Accessibility

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

      -

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

      +

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

      Layers of Guidance

      The Guidelines

      -

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

      +

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

      Success Criteria

      -

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

      -

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

      -

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

      +

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

      +

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

      +

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

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

      -

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

      +

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

      • -

        sufficient techniques for meeting the Success Criterion,

        +

        sufficient techniques for meeting the success criterion,

      • optional advisory techniques, and

      • -

        descriptions of the intent of the Success Criteria, including benefits, and examples.

        +

        descriptions of the intent of the success criterion, including benefits, and examples.

      diff --git a/understanding/refer-to-wcag.html b/understanding/refer-to-wcag.html index 8fb4adb859..22b4450799 100644 --- a/understanding/refer-to-wcag.html +++ b/understanding/refer-to-wcag.html @@ -1,60 +1,60 @@ - + - How to refer to WCAG 2.1 from other documents + How to refer to WCAG 2 from other documents -

      How to refer to WCAG 2.1 from other documents

      -

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

      -

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

      +

      How to refer to WCAG 2 from other documents

      +

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

      +

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

      Information references

      -

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

      -

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

      +

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

      +

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

      -

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

      -

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

      -

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

      +

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

      +

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

      +

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

      -

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

      -

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

      +

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

      +

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

      1. -

        Conformance at any level of WCAG 2.1 requires that all of the Level A Success Criteria be met. References to WCAG 2.1 conformance cannot be for any subset of Level A.

        +

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

      2. -

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

        +

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

      3. -

        If Level AA conformance to WCAG 2.1 is specified, then all Level A and all Level AA Success Criteria must be met.

        +

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

      4. -

        If Level AAA conformance to WCAG 2.1 is specified, then all Level A, all Level AA, and all Level AAA Success Criteria must be met.

        -

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

        -

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

        +

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

        +

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

        +

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

      Examples

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

      -

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

      +

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

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

      -

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

      +

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

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

      -

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

      -

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

      -

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

      +

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

      +

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

      +

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

      -

      Referring to content from WCAG support documents

      -

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

      -

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

      +

      Referring to content from WCAG 2 support documents

      +

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

      +

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

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

      or

      -

      W3C World Wide Web Consortium (200x): WCAG2.0 HTML Techniques (URI: {URI of HTML Techniques})

      +

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

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

      diff --git a/understanding/toc.html b/understanding/toc.html deleted file mode 100644 index aa46eaf84b..0000000000 --- a/understanding/toc.html +++ /dev/null @@ -1,532 +0,0 @@ - \ No newline at end of file diff --git a/understanding/understanding-act-rules.html b/understanding/understanding-act-rules.html new file mode 100644 index 0000000000..ef08e26b36 --- /dev/null +++ b/understanding/understanding-act-rules.html @@ -0,0 +1,76 @@ + + + + Understanding Test Rules for WCAG 2 Success Criteria + + +

      Understanding Test Rules for WCAG 2 Success Criteria

      + +

      Test Rules provide guidance for developers of automated testing tools and manual testing methodologies, to help ensure consistent interpretation of WCAG 2 success criteria.

      +

      W3C's List of Test Rules for WCAG 2 is updated periodically. They are developed according to the Accessibility Conformance Testing (ACT) Rules Format 1.0 standard.

      +

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

      + +
      +

      Test Rules Rules are Informative

      +

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

      +

      While W3C's List of Test Rules for WCAG 2 are reviewed by the W3C Accessibility Guidelines Working Group (AGWG), they are not vetted to the same degree as the W3C Web Content Accessibility Guidelines (WCAG) standard (called W3C Recommendation). The WCAG 2 standard is the normative reference on determining conformance.

      +
      + +
      +

      Test Rules are Partial Checks

      +

      Test Rules typically check specific aspects of WCAG 2 success criteria. For example, that a table cell has a header rather than the entire WCAG 2 success criterion 1.3.1 "Info and Relationships", which applies to many more information structures on a web page. In fact, this example rule would not even check the validity of the table header, only if the header exists for a given table cell.

      +

      Test Rules are also technology-specific. For example, the aforementioned table header example would be specific to HTML, possibly enriched with WAI-ARIA roles and properties, but not to other formats with tables. WCAG 2 success criteria are designed to be technology-agnostic and applicable to all web technologies.

      +
      + +
      +

      Test Rules Check for Failures

      +

      Test Rules are designed to check failures in satisfying WCAG 2 success criteria. That is, when content fails Test Rules, it means that the content does not satisfy the corresponding success criteria. However, when content passes Test Rules, it means that no corresponding failures were detected — it does not necessarily mean that the content satisfies all aspects of the corresponding success criteria.

      +

      The reason for this is because WCAG 2 success criteria typically cover several aspects and technologies, while Test Rules only check specific aspects. Checking that content satisfies all aspects of WCAG 2 success criteria typically requires further verification by human testers.

      +

      WCAG 2 Conformance Requirement 1 allows for "conforming alternate versions". That means that content may still conform to WCAG 2, even when content fails Test Rules, thus does not satisfy the corresponding success criteria.

      +
      + + + +
      +

      Structure of Test Rules

      +

      Test Rules conform to the Accessibility Conformance Testing (ACT) Rules Format 1.0 standard. They include the following parts:

      +
        +
      • Descriptive Title – title for the Test Rule, which should describe the rule
      • +
      • Rule Identifier – identifier for the Test Rule; the W3C rules use alphanumeric strings
      • +
      • Rule Type – there are two basic types of Test Rules, depending on what is being tested: +
          +
        • Atomic Rule – test one specific situation, which may be part of a composite rule
        • +
        • Composite Rule – combine outcome from multiple atomic rules to one outcome
        • +
        +
      • +
      • Accessibility Requirements Mapping – maps the Test Rule to particular accessibility requirements; in this suite of rules we use Web Content Accessibility Guidelines (WCAG) 2 success criteria
      • +
      • Rule Input – describes the scope of input into Test Rules, which is one of the following: +
          +
        • Input Aspects – input into atomic rules, such as DOM Tree and CSS Styling etc.
        • +
        • Input Rules – input into the composite rules, which are the atomic rules in scope
        • +
        +
      • +
      • Applicability – description of the specific parts of the content, for which the rule applies
      • +
      • Expectations – description of the expected characteristics of the applicable rule content
      • +
      • Assumptions – assumptions made, such as specific interpretations of the requirements
      • +
      • Accessibility Support – known limitations regarding browsers and assistive technology
      • +
      • Test Cases – sample code demonstrating passed, failed, and inapplicable rule conditions
      • +
      • Change Log – history of changes for the Test Rules, to support backward compatibility
      • +
      • Glossary – list of key terms defined by the Test Rule or used by the specific Test Rule
      • +
      • Issues List (Optional) – list of known issues or bugs for the particular Test Rule, if any
      • +
      • Background (Optional) – relevant background, such as additional documentation, if any
      • +
      • Acknowledgements (Optional) – such as rule writers, reviewers, and other contributors
      • +
      +
      + + diff --git a/understanding/understanding-metadata.html b/understanding/understanding-metadata.html index b518e2a1df..7dee0f25ca 100644 --- a/understanding/understanding-metadata.html +++ b/understanding/understanding-metadata.html @@ -1,14 +1,14 @@ - + Understanding Metadata

      Understanding Metadata

      -

      This section discusses metadata techniques that can be employed to satisfy WCAG 2.1 Success Criteria. For more information about metadata see resources below.

      +

      This section discusses metadata techniques that can be employed to satisfy WCAG 2 success criteria. For more information about metadata see resources below.

      At its most basic level, metadata is essentially 'data about data' and is used to both describe and find resources.

      Metadata is a powerful tool that can be used for describing Web pages and accessible components of Web pages as well as associating alternate versions of Web content to each other. These descriptions in turn allows users to locate specific information they need or prefer.

      -

      In conjunction with WCAG, metadata can play a number of roles including:

      +

      In conjunction with WCAG 2, metadata can play a number of roles including:

      1. Metadata can be used to associate conforming alternate versions of Web pages with Web pages which do not conform, in order to allow users to find the conforming alternate version when they land on a non-conforming page that they cannot use.

        @@ -17,7 +17,7 @@

        Understanding Metadata

        Metadata can be used to locate and also to describe alternate pages where there are multiple versions of a page which have been developed, especially where the alternate pages are optimized for individuals with different disabilities. The user can use the metadata both to locate the alternate versions and to identify characteristics of the versions, so that they can find the one that best meets their needs.

      2. -

        In addition to being used for whole pages (as in #1 and #2 above), metadata can be used to describe alternate versions of subcomponents of a page. Again, the metadata can be used to find alternate versions of a Web page component as well as to get descriptions of the alternate versions ( if there are several) in order to determine which one would best meet the user's needs.

        +

        In addition to being used for whole pages (as in #1 and #2 above), metadata can be used to describe alternate versions of subcomponents of a page. Again, the metadata can be used to find alternate versions of a Web page component as well as to get descriptions of the alternate versions (if there are several) in order to determine which one would best meet the user's needs.

      diff --git a/understanding/understanding-techniques.html b/understanding/understanding-techniques.html index 8bb496e315..be18332fc6 100644 --- a/understanding/understanding-techniques.html +++ b/understanding/understanding-techniques.html @@ -1,53 +1,37 @@ - Understanding Techniques for WCAG Success Criteria + Understanding Techniques for WCAG 2 Success Criteria -

      Understanding Techniques for WCAG Success Criteria

      -

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

      -

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

      -

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

      +

      Understanding Techniques for WCAG 2 Success Criteria

      +

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

      +

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

      +

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

        -
      • -

        Sufficient techniques

        -
      • -
      • -

        Advisory techniques

        -
      • -
      • -

        Failures

        -
      • +
      • Sufficient techniques
      • +
      • Advisory techniques
      • +
      • Failures

      Also explained below:

        -
      • -

        General and technology-specific techniques - which can be sufficient or advisory

        -
      • -
      • -

        Other techniques - beyond what is in W3C's published document

        -
      • -
      • -

        Technique tests

        -
      • -
      • -

        User agent and assistive technology support

        -
      • -
      • -

        Using the techniques - with important considerations

        -
      • +
      • General and technology-specific techniques - which can be sufficient or advisory
      • +
      • Other techniques - beyond what is in W3C's published document
      • +
      • Technique tests
      • +
      • User agent and assistive technology support
      • +
      • Using the techniques - with important considerations

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

      Techniques are Informative

      -

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

      -

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

      +

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

      +

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

      -

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

      +

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

      Sufficient Techniques

      @@ -57,10 +41,10 @@

      Sufficient Techniques

      From an author's perspective: If you use the sufficient techniques for a given criterion correctly and it is accessibility-supported for your users, you can be confident that you met the success criterion.

    • -

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

      +

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

    • -

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

      +

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

      Numbered Lists, "AND"

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

      @@ -71,24 +55,12 @@

      Advisory Techniques

      Advisory techniques are suggested ways to improve accessibility. They are often very helpful to some users, and may be the only way that some users can access some types of content.

      Advisory techniques are not designated as sufficient techniques for various reasons such as:

        -
      • -

        they may not be sufficient to meet the full requirements of the success criteria;

        -
      • -
      • -

        they may be based on technology that is not yet stable;

        -
      • -
      • -

        they may not be accessibility supported in many cases (for example, assistive technologies do not work with them yet);

        -
      • -
      • -

        they may not be testable;

        -
      • -
      • -

        in some circumstances they may not be applicable or practical, and may even decrease accessibility for some users while increasing it for others;

        -
      • -
      • -

        they may not address the success criterion itself, and instead provide related accessibility benefits.

        -
      • +
      • they may not be sufficient to meet the full requirements of the success criteria;
      • +
      • they may be based on technology that is not yet stable;
      • +
      • they may not be accessibility supported in many cases (for example, assistive technologies do not work with them yet);
      • +
      • they may not be testable;
      • +
      • in some circumstances they may not be applicable or practical, and may even decrease accessibility for some users while increasing it for others;
      • +
      • they may not address the success criterion itself, and instead provide related accessibility benefits.

      Authors are encouraged to apply all of the techniques where appropriate to best address the widest range of users' needs.

      @@ -100,64 +72,60 @@

      Failures

      Authors to know what to avoid,

    • -

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

      +

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

    • -

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

      -

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

      +

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

      +

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

    • -

      General and Technology-specific Techniques

      +

      General and Technology-specific Techniques

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

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

      -

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

      +

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

      Other Techniques

      -

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

      -

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

      -

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

      +

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

      +

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

      +

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

      Any techniques can be sufficient if:

      Submitting Techniques

      -

      The WCAG Working Group encourages people to submit new techniques so that they can be considered for inclusion in updates of the Techniques for WCAG 2.1 document. Please submit techniques for consideration using the Techniques Submission Form.

      +

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

      Testing Techniques

      -

      Each technique has tests that help:

      +

      Each technique has tests that help:

        -
      • -

        authors verify that they implemented the technique properly, and

        -
      • -
      • -

        evaluators determine if web content meets the technique.

        -
      • +
      • authors verify that they implemented the technique properly, and
      • +
      • evaluators determine if web content meets the technique.
      -

      The tests are only for a technique, they are not tests for conformance to WCAG success criteria.

      +

      The tests are only for a technique, they are not tests for conformance to WCAG 2 success criteria.

      • Failing a technique test does not necessarily mean failing WCAG, because the techniques are discrete (that is, they address one specific point) and they are not required.

      • -

        Content can meet WCAG success criteria in different ways other than W3C's published sufficient techniques.

        +

        Content can meet WCAG 2 success criteria in different ways other than W3C's published sufficient techniques.

      • -

        Content that passes the sufficient techniques for a specific technology does not necessarily meet all WCAG success criteria. Some success criteria have only general techniques, not technology-specific techniques.

        +

        Content that passes the sufficient techniques for a specific technology does not necessarily meet all WCAG 2 success criteria. Some success criteria have only general techniques, not technology-specific techniques.

      • The content must be accessibility supported for the content's users. Some sufficient techniques require browser, assistive technology, or other support that some users might not have.

      -

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

      +

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

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

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

      Support Notes Change Over Time

      Using the Techniques

      -

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

      +

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

      Alternatives must meet success criteria

      -

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

      +

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

      Example Code

      diff --git a/understanding/understanding-template.html b/understanding/understanding-template.html index ddb681842d..f73ba2b723 100644 --- a/understanding/understanding-template.html +++ b/understanding/understanding-template.html @@ -1,21 +1,21 @@ - WCAG 2.0 Understanding Page + WCAG 2 Understanding Page

      Understanding SC #.#.#

      Intent

      -

      This section contains the main explanatory content of the Understanding. It explains why the Guideline or Success Criterion exists and, at a high level, how to meet it.

      -
      -

      Benefits

      -

      This explains how following the success criterion benefits particular types of users with disabilities.

      -
        -
      • Benefit
      • -
      -
      +

      This section contains the main explanatory content of the Understanding. It explains why the Guideline or success criterion exists and, at a high level, how to meet it.

      +
      +
      +

      Benefits

      +

      This explains how following the success criterion benefits particular types of users with disabilities.

      +
        +
      • Benefit
      • +

      Examples

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

      Resources

      Techniques

      -

      This section references techniques that can be used to meet the Guideline or Success Criterion. There are sub-sections for sufficient techniques, advisory techniques, and failures.

      +

      This section references techniques that can be used to meet the Guideline or success criterion. There are sub-sections for sufficient techniques, advisory techniques, and failures.

      • Within each sub-section, there may be "situations" to describe when a set of techniques need to be considered. Remove the sub-section and heading if situations are not used.
      • Techniques are provided in an unordered list. Reference techniques by linking to the filename of the technique and using the technique ID as link text. Use unlinked plain text if the technique has not been written yet.
      • @@ -49,7 +49,7 @@

        Techniques

      Sufficient

      -

      Techniques that are sufficient to meet the Guideline or Success Criterion.

      +

      Techniques that are sufficient to meet the guideline or success criterion.

      Situation

        @@ -63,14 +63,14 @@

        Situation

      Advisory

      -

      Techniques that are not sufficient by themselves to meet the Guideline or Success Criterion.

      +

      Techniques that are not sufficient by themselves to meet the guideline or success criterion.

      Same template as sufficient techniques.

      Failure

      -

      Techniques that document conditions that would cause the page not to meet the Guideline or Success Criterion, even if sufficient techniques are also used.

      +

      Techniques that document conditions that would cause the page not to meet the guideline or success criterion, even if sufficient techniques are also used.

      Same template as sufficient techniques.

      - \ No newline at end of file + diff --git a/understanding/understanding.11tydata.js b/understanding/understanding.11tydata.js new file mode 100644 index 0000000000..e6a12fdc66 --- /dev/null +++ b/understanding/understanding.11tydata.js @@ -0,0 +1,7 @@ +export default function (data) { + return { + headerLabel: "Understanding Docs", + headerUrl: data.understandingUrl, + isUnderstanding: true, + }; +} diff --git a/understanding/understanding.css b/understanding/understanding.css index 2716852863..f7a039253e 100644 --- a/understanding/understanding.css +++ b/understanding/understanding.css @@ -206,4 +206,8 @@ p.sctxt { video { max-width: 100%; +} +/* make links in W3C masthead bold, since we can't make them underline */ +.head p:not(.copyright) > a, .head > a:first-child { + font-weight: bold; } \ No newline at end of file diff --git a/wcag20/Techniques/ua-notes/Overview.html b/wcag20/Techniques/ua-notes/Overview.html index 9c38d7d974..b6e2af6178 100644 --- a/wcag20/Techniques/ua-notes/Overview.html +++ b/wcag20/Techniques/ua-notes/Overview.html @@ -1,2 +1,2 @@ -User Agent Support Notes for WCAG Techniques

      User Agent Support Notes for WCAG Techniques

      This resource contains documented user agent issues from WCAG 2.0 Techniques. There is a separate page for each technology. For some technology, user agent issues are primarily documented in overall technology notes that introduce the technology and are repeated in the technology page here.

      \ No newline at end of file +User Agent Support Notes for WCAG Techniques

      User Agent Support Notes for WCAG Techniques

      This resource contains documented user agent issues from WCAG 2.0 Techniques. There is a separate page for each technology. For some technology, user agent issues are primarily documented in overall technology notes that introduce the technology and are repeated in the technology page here.

      diff --git a/wcag20/Techniques/ua-notes/aria.html b/wcag20/Techniques/ua-notes/aria.html index 475368b656..44e8d1af4e 100644 --- a/wcag20/Techniques/ua-notes/aria.html +++ b/wcag20/Techniques/ua-notes/aria.html @@ -27,7 +27,7 @@

      WAI-ARIA Technology Notes< support the use of Liveregions.

    • Firefox 3+ contains better support for WAI-ARIA, including Liveregions.

    • IE8 partially supports WAI-ARIA.

    • JAWS 8 and Window-Eyes 5.5+ partially support WAI-ARIA.

    • Jaws 10+ supports WAI-ARIA.

    • FireVox, a self-voicing extension to Firefox, also - supports WAI-ARIA via direct DOM access.

    • NVDA partially supports WAI-ARIA.

    • Accessibility Support for WAI-ARIA

      Using technologies in an Accessibility Supported way is required for conformance claims. Read more about Accessibility Support. [begin delete] The WCAG Working Group plans to review which WAI-ARIA techniques are sufficient when Accessible Rich Internet Application specifications reach W3C Recommendation status. [end delete]Refer to WAI-ARIA Overview for the latest information on the status of WAI-ARIA specifications.

      ARIA1: Using the aria-describedby property to provide a descriptive label for user interface controls

      See User Agent Support for WAI-ARIA for general information on user agent support.

      IE 8 only supports aria-labelledby with a single id value and it partially supports aria-describedby.

      ARIA2: Identifying a required field with the aria-required property

      See User Agent Support for WAI-ARIA for general information on user agent support.

      ARIA4: Using a WAI-ARIA role to expose the role of a user interface component

      See User Agent Support for WAI-ARIA for general information on user agent support.

      ARIA5: Using WAI-ARIA state and property attributes to expose the state of a user interface component

      See User Agent Support for WAI-ARIA for general information on user agent support.

      ARIA6: Using aria-label to provide labels for objects

      See User Agent Support for WAI-ARIA for general information on user agent support.

      • Jaws V.11 and greater has complete support. + supports WAI-ARIA via direct DOM access.

      • NVDA partially supports WAI-ARIA.

      Accessibility Support for WAI-ARIA

      Using technologies in an Accessibility Supported way is required for conformance claims. Read more about Accessibility Support. [begin delete] The WCAG Working Group plans to review which WAI-ARIA techniques are sufficient when Accessible Rich Internet Application specifications reach W3C Recommendation status. [end delete]Refer to WAI-ARIA Overview for the latest information on the status of WAI-ARIA specifications.

      ARIA1: Using the aria-describedby property to provide a descriptive label for user interface controls

      See User Agent Support for WAI-ARIA for general information on user agent support.

      IE 8 only supports aria-labelledby with a single id value and it partially supports aria-describedby.

      ARIA2: Identifying a required field with the aria-required property

      See User Agent Support for WAI-ARIA for general information on user agent support.

      ARIA4: Using a WAI-ARIA role to expose the role of a user interface component

      See User Agent Support for WAI-ARIA for general information on user agent support.

      ARIA5: Using WAI-ARIA state and property attributes to expose the state of a user interface component

      See User Agent Support for WAI-ARIA for general information on user agent support.

      ARIA6: Using aria-label to provide labels for objects

      See User Agent Support for WAI-ARIA for general information on user agent support.

      H53: Using the body of the object element

      This technique is not supported well by assistive technologies and cross-browser - support is irregular.

      H57: Using language attributes on the html element

      Additional subtags for region, script, variant or other aspects may lead to errors in language switching in older versions of some screenreaders.

      JAWS 8.0 can be configured to change language automatically on the basis of the lang attribute. However, it only switches amongst major languages as indicated by the primary code. If a regional language variant is indicated with a language subcode, JAWS will use the default variant for which it is configured.

      H58: Using language attributes to identify changes in the human language

      Additional subtags for region, script, variant or other aspects may lead to errors in language switching in older versions of some screenreaders.

      JAWS 8.0 can be configured to change language automatically on the basis of the lang attribute. However, it only switches amongst major languages as indicated by the primary code. If a regional language variant is indicated with a language subcode, JAWS will use the default variant for which it is configured.

      H59: Using the link element and navigation tools

      • The link element has inconsistent user agent and assistive technology support.

      • Some user agents provide an optional navigation bar which will display the - information specified in the link element. Current versions of the Mozilla and Opera - browsers provide this functionality. IE 6.0 and Firefox 1.5 do not offer this feature - but it may be available through extensions or add-ons.

        See The 'link'-Element in (X)HTML for - more information on browser support for link.

      H60: Using the link element to link to a glossary

      Some user agents provide an optional navigation bar which will display the + support is irregular.

      H57: Using language attributes on the html element

      Additional subtags for region, script, variant or other aspects may lead to errors in language switching in older versions of some screenreaders.

      JAWS 8.0 can be configured to change language automatically on the basis of the lang attribute. However, it only switches amongst major languages as indicated by the primary code. If a regional language variant is indicated with a language subcode, JAWS will use the default variant for which it is configured.

      H58: Using language attributes to identify changes in the human language

      Additional subtags for region, script, variant or other aspects may lead to errors in language switching in older versions of some screenreaders.

      JAWS 8.0 can be configured to change language automatically on the basis of the lang attribute. However, it only switches amongst major languages as indicated by the primary code. If a regional language variant is indicated with a language subcode, JAWS will use the default variant for which it is configured.

      H60: Using the link element to link to a glossary

      Some user agents provide an optional navigation bar which will display the information specified in the link element. Current versions of the Mozilla and Opera browsers provide this functionality. IE 6.0 and Firefox 1.5 do not offer this feature but it may be available through extensions or add-ons. See The 'link'-Element in (X)HTML for diff --git a/wcag20/Techniques/working-examples/ARIA1/ex1.html b/wcag20/Techniques/working-examples/ARIA1/ex1.html index 093b5e6900..075d5fa713 100644 --- a/wcag20/Techniques/working-examples/ARIA1/ex1.html +++ b/wcag20/Techniques/working-examples/ARIA1/ex1.html @@ -3,7 +3,7 @@ "http://www.w3.org/TR/html4/strict.dtd"> - + Demonstration of describedby property Highlighting elements that receive focus

      - +

      -
      - +
      +

      diff --git a/wcag20/Techniques/working-examples/C17/input-resize.html b/wcag20/Techniques/working-examples/C17/input-resize.html index 3607b7ef55..df10223f10 100644 --- a/wcag20/Techniques/working-examples/C17/input-resize.html +++ b/wcag20/Techniques/working-examples/C17/input-resize.html @@ -1,7 +1,7 @@ - + Example of resizing input with CSS - - + +
      -

      W3C

      +

      W3C

      Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT)

      W3C Editors' DraftWorking Group Note 5 September 2013

      @@ -241,7 +241,7 @@

      W3C

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

      -


      +

      Abstract

      This document, “Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT)” describes how the Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG20] and its principles, guidelines, and success criteria can be applied to non-web Information and Communications Technologies (ICT), specifically to non-web documents and software. It provides informative guidance (guidance that is not normative and does not set requirements).

      This document is intended to become a Working Group Note, and is part of a series of technical and educational documents published by the W3C Web Accessibility Initiative (WAI) and available from the WCAG 2.0 Overview.

      @@ -448,7 +448,7 @@

      6. Comments on Conformance

      WCAG2ICT is not a standard, so it is not possible to conform to WCAG2ICT. However, some entities may wish to use the information in WCAG2ICT to help establish standards or regulations regarding accessibility in ICT that are based on WCAG 2.0. While such standards or regulations will need to address matters of conformance themselves, the following notes may be of assistance to those wishing to draft their own requirements:

      1. The WCAG 2.0 success criteria and the conformance requirements were designed to work together, such that the language of the success criteria is based on the nature of the conformance requirements. The choice of what level to use for a given criteria (A vs. AA vs. AAA) was further influenced by a number of factors specific to the web domain, as set forth in Understanding Levels of Compliance.
      2. -
      3. In the WCAG 2.0 conformance model, a success criteria is satisfied if the item being evaluated does not fail it. If the success criterion is in relation to something that does not exist for the item being evaluated (e.g. a success criterion is about captioning audio and there is no audio) then the success criterion is automatically met. This approach is central to the way the success criteria in WCAG are structured and worded.
      4. +
      5. In the WCAG 2.0 conformance model, a success criterion is satisfied if the item being evaluated does not fail it. If the success criterion is in relation to something that does not exist for the item being evaluated (e.g. a success criterion is about captioning audio and there is no audio) then the success criterion is automatically met. This approach is central to the way the success criteria in WCAG are structured and worded.
      6. WCAG 2.0 conformance is applied to the item being evaluated (i.e. web page) as a whole, except when a process includes use of several items, in which case all of the items that are needed in order to complete the process must conform.
      7. In WCAG 2.0, when conformance relies on accessibility features of the platform (i.e. browser for web content) or on assistive technologies, WCAG 2.0 requires that there are assistive technologies, etc. that work with the product (web page). That is, conformance with WCAG 2.0 requires that the approaches used are supported by assistive technologies.
      8. WCAG 2.0 allows information on part of a page to not conform if the same information is available elsewhere on the page in conforming fashion. However WCAG 2.0 identifies 4 success criteria that must be met on all areas of the page because they can interfere with the user's ability to access and use other parts of the page:
          @@ -523,7 +523,7 @@

          Success Criterion 1.4.2: Audio Control (Level A)

          Success Criterion 1.4.3: Contrast (Minimum) (Level AA)

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

      -

      Success Criterion 1.4.4: Resize text (Level AA)

      +

      Success Criterion 1.4.4: Resize Text (Level AA)

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

      Note 1: Content for which there are software players, viewers or editors with a 200 percent zoom feature would automatically meet this success criterion when used with such players, unless the content will not work with zoom.

      Note 2: The Intent section refers to the ability to allow users to enlarge the text on screen at least up to 200% without needing to use assistive technologies. This means that the application provides some means for enlarging the text 200% (zoom or otherwise) without loss of content or functionality or that the application works with the platform features that meet this requirement.

      diff --git a/working-examples/aria-alert-identify-errors/index.html b/working-examples/aria-alert-identify-errors/index.html index ea01f5d6c3..8a8bd92df3 100644 --- a/working-examples/aria-alert-identify-errors/index.html +++ b/working-examples/aria-alert-identify-errors/index.html @@ -1,9 +1,28 @@ - + -Using role=alert to Identify Errors - +Using ARIA live regions or role=alert to identify errors + + + + + + + + + +

      Semantically identifying a font icon with role="img" examples

      + +
      + +

      Example 1: Star Icon Font used as an indicator (not interactive)

      + +

      Instead of...

      +

      + +

      + +

      Do...

      +

      + +

      + + + +
      + +
      + +

      Example 2: Two colored / stacked star Icon Font used as an indicator

      + +

      Instead of...

      +

      + + + + +

      + +

      Do...

      +

      + + + + +

      + + + +
      + +
      + +

      Example 3: Email Icon Font in a link WITHOUT visible text

      + +

      Instead of...

      +

      + + + +

      + +

      Do...

      +

      + + + +

      + + + +
      + +
      + +

      Example 4: Multiple Icon Fonts as part of another sematic element WITH visible text

      + +

      Instead of...

      +

      + + Email + +

      + +

      Do...

      +

      + + + + Email + +

      + + + +
      + + + diff --git a/working-examples/aria-invalid-data-format/index.html b/working-examples/aria-invalid-data-format/index.html index be5891aa80..18d9ce4429 100644 --- a/working-examples/aria-invalid-data-format/index.html +++ b/working-examples/aria-invalid-data-format/index.html @@ -1,7 +1,7 @@ - + Forms: Using aria-invalid - -

      Extend timeout

      +

      aria-labelledby example 1: Extend time-out

      @@ -18,6 +24,6 @@

      Extend timeout

      -

      (Adapted from Easy ARIA tip #2: aria-labelledby and aria-describedby, an example put together by Marco Zehe in 2008)

      +

      (Adapted from Easy ARIA tip #2: aria-labelledby and aria-describedby, an example put together by Marco Zehe in 2008)

      diff --git a/working-examples/aria-labelledby-workshop-booking-timetable/index.html b/working-examples/aria-labelledby-workshop-booking-timetable/index.html index baaf7ac57d..2635f96d7c 100644 --- a/working-examples/aria-labelledby-workshop-booking-timetable/index.html +++ b/working-examples/aria-labelledby-workshop-booking-timetable/index.html @@ -1,10 +1,31 @@ - - + + - + Dinosaur conference - + + + +

      Dinosaur conference workshops timetable Thursday, 14. & Friday, 15. March 2013

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

      Dinosaur conference workshops timetable Thursday, 14. & Friday, 15. March 2 Dinosaur conference workshop booking table

      Track Thursday Friday
      track 1Track 1 -

      The Paleozoic era

      +

      The Paleozoic era

      2 places left

      -

      +

      @@ -59,7 +80,7 @@

      The Jurassic period

      track 2Track 2

      The Cretaceous period

      18 places left

      @@ -89,16 +110,14 @@

      Emerging scholarship

      -

       

      - +
      - +
      - - (Only enter if different from last name) + + (Only enter if different from last name)
      -

       

      diff --git a/working-examples/breadcrumb-trail/index.html b/working-examples/breadcrumb-trail/index.html index df9c98ee6e..bf997256e5 100644 --- a/working-examples/breadcrumb-trail/index.html +++ b/working-examples/breadcrumb-trail/index.html @@ -2,29 +2,49 @@ - G65 Example 3: Breadcrumb Example + + G65 Providing a breadcrumb trail examples -

      Breadcrumb Example

      +

      Breadcrumb Trail Examples

      +

      Note: hyperlinks in these examples will return 404 errors.

      + +

      Breadcrumb trail where current page is not a link

      + + +

      Breadcrumb trail where current page is a link

      - \ No newline at end of file + diff --git a/working-examples/css-fit-labels-inputs/index.html b/working-examples/css-fit-labels-inputs/index.html index 582dfb848a..f615307d2a 100644 --- a/working-examples/css-fit-labels-inputs/index.html +++ b/working-examples/css-fit-labels-inputs/index.html @@ -2,6 +2,7 @@ + Using Adjustable Labels and Inputs for Reflow + + + +

      Using CSS :focus-visible to provide keyboard focus indication

      +

      In this example, we have a standard <button> control in the HTML.

      + + + +

      By default, in all modern browsers, this button does not show any focus indication when activated using a mouse/pointer. Browsers show their default focus outline/indication when a user sets focus on the button using Tab.

      +

      In order to make this focus indication more prominent, we use the :focus-visible pseudo-class selector to define a more intentional and pronounced focus style.

      +
      :focus-visible { outline: 5px solid red; }
      + + diff --git a/working-examples/css-grid/index.html b/working-examples/css-grid/index.html index 6d54cdc328..2a66bbbf90 100644 --- a/working-examples/css-grid/index.html +++ b/working-examples/css-grid/index.html @@ -7,10 +7,10 @@ + + + Link opens in new window notification + -

      Pop-Up Warning

      -

      -This is an example of an External linkOpens a new window -

      + + +

      Link opens in new window notification

      +

      This is an example of an external link

      \ No newline at end of file diff --git a/working-examples/css-padding-focus-not-obscured/index.html b/working-examples/css-padding-focus-not-obscured/index.html new file mode 100644 index 0000000000..befed6ed31 --- /dev/null +++ b/working-examples/css-padding-focus-not-obscured/index.html @@ -0,0 +1,200 @@ + + + + + + Using CSS scroll-padding to un-obscure content + + + + +

      Fixed-Position Banner

      + +
      +
      +
      +

      Header Content

      +
      +
      +

      Main Content

      +
      + + +
      + + + \ No newline at end of file diff --git a/working-examples/css-pointer-spacing/index.html b/working-examples/css-pointer-spacing/index.html new file mode 100644 index 0000000000..f4cf5d0e84 --- /dev/null +++ b/working-examples/css-pointer-spacing/index.html @@ -0,0 +1,165 @@ + + + + + Working example - Using min-height and min-width to ensure sufficient target spacing + + + + + + + +

      Working example of using min-height and min-width to ensure sufficient target spacing

      + +

      This example relates to technique C42.

      + +

      Example 1 (display: inline-block, min-height:44px and min-width:44px set on list items inside pagination menu)

      +

      The first example shows a situation where the targets (in this case, the linked numbers in the pagination menu) are smaller than 44 × 44 CSS pixels. However, the list items that contain them have a minimum height and width of 44px, so that sufficient target spacing is assured.

      +

      Search results (invented):

      + + +
        +
      1. +

        Garbage Delight by Dennis Lee (2014-05-06) (NoDust) by | HC | Good

        +

        HarperCollins, 1800. Condition: Good.

        +
      2. +
      3. +

        Frederick S Perls: In and out the garbage pail by Frederick S Perls (1969-05-03)

        +

        Real People Press, 1804. Shows some signs of wear, and may have some markings on the inside.

        +
      4. +
      5. +

        Lila Karp: The Queen Is in the Garbage (Classic Feminist Writers) by Lila Karp (2007-05-01)

        +

        1838. Condition: Very Good. Published by Belmont Books, 1969.

        +
      6. +
      + + +

      Example 2 (display: flex, min-height:44px and min-width:44px set on links inside pagination menu)

      +

      The second example uses min-width and min-height on the targets (the linked numbers in the pagination menu) and not on the parent container, thereby meeting this target spacing Success Criterion and the AAA Success Criterion 2.5.5 Target Size.

      +

      Search results (invented):

      + + +
        +
      1. +

        Garbage Delight by Dennis Lee (2014-05-06) (NoDust) by | HC | Good

        +

        HarperCollins, 1800. Condition: Good.

        +
      2. +
      3. +

        Frederick S Perls: In and out the garbage pail by Frederick S Perls (1969-05-03)

        +

        Real People Press, 1804. Shows some signs of wear, and may have some markings on the inside.

        +
      4. +
      5. +

        Lila Karp: The Queen Is in the Garbage (Classic Feminist Writers) by Lila Karp (2007-05-01)

        +

        1838. Condition: Very Good. Published by Belmont Books, 1969.

        +
      6. +
      + + + diff --git a/working-examples/css-reduced-motion-query/index.html b/working-examples/css-reduced-motion-query/index.html index 5a7ec90b96..b666d616e1 100644 --- a/working-examples/css-reduced-motion-query/index.html +++ b/working-examples/css-reduced-motion-query/index.html @@ -1,11 +1,15 @@ - - - + + + + Motion triggered by user interaction - -
      +

      Using media queries to un-fix sticky headers / footers

      The objective of this technique is to be able to present content without sticky headers and footers when the space of the viewport is limited. This may be because of a device held in landscape mode or by zooming on a dektop.

      @@ -253,17 +253,14 @@

      Panel 4

      -