AutoGineer
Generated banner for Accessibility
Generated logo for Accessibility

Accessibility

MicrosoftOfficialPublished by Microsoft

  • Skill
  • Tool integration
  • Software development
  • MIT
  • Low risk
  • Has scripts
Get it from the source

From the author

Consolidated accessibility skill entrypoint for WCAG 2.2, ARIA Authoring Practices, cognitive accessibility, Section 508, EN 301 549, design intent verification, and the Accessibility Planner workflow.
— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The accessibility skill provides a structured approach to managing accessibility requirements across the development lifecycle. It includes a six-phase Accessibility Planner workflow, a command-line scanner for static analysis, and a runtime probe harness for verifying interaction-based accessibility. The skill enforces a doctrine of method adequacy, ensuring that verification methods are only used to decide criteria they are capable of observing, and supports the generation of evidence bundles for review.

What it does

  • Provides a six-phase workflow for accessibility discovery, planning, and backlog handoff.
  • Wraps the axe-core CLI to perform static accessibility scans on web pages.
  • Executes Playwright-based runtime probes to verify interaction behavior and screen-reader announcements.
  • Enforces method adequacy rules to distinguish between static findings and interaction-based verification.
  • Generates deterministic evidence bundles for accessibility reviews and reporting.
  • Maps findings to WCAG 2.2, ARIA Authoring Practices, and other accessibility standards.

When to use it

  • When planning accessibility requirements for a new project or feature.
  • When performing automated static scans of web content for common accessibility defects.
  • When verifying complex interaction behaviors that static analysis cannot fully evaluate.
  • When building an evidence register to track accessibility conformance across development phases.

Advantages

  • Standardizes accessibility verification across different projects and teams.
  • Prevents over-reliance on static analysis for complex interaction-based criteria.
  • Supports tiered enforcement postures to match project risk and maturity.
  • Integrates with standard CI workflows for automated accessibility testing.

Usage examples

“Scan my local file index.html for accessibility violations.”
The skill runs the axe-core scanner against the file and outputs a normalized JSON report of findings.
“Run the accessibility runtime probes for my project.”
The skill executes the configured Playwright probes and aggregates the results into a coverage matrix.

Install

  1. 1 of its files are not mirrored here, so install it from its source:

    https://github.com/microsoft/hve-core/tree/f425e943bf228052a23e6bc4810b5faef030314f/.github/skills/accessibility/accessibility

Documentation by Microsoft

Accessibility — Skill Entry

This skill is the canonical accessibility reference contract for HVE Core. Agents and instructions invoke this skill by name and rely on it to own framework reference resolution, phase guidance resolution, and the scanner CLI entrypoint.

Framework references

Assessment reference (cross-cutting, not a conformance framework):

  • Assistive-technology announcement model — read this when deciding the announcement-class criteria (WCAG 1.3.1, 4.1.2, 4.1.3): what a screen-reader user should hear, and how to decide it with an accessibility-tree assertion or a manual AT pass.

Accessibility Planner workflow

The Accessibility Planner runs six phases, each keyed to a state id:

  1. Phase 1 — Discovery (discovery)

  2. Phase 2 — Framework Selection (framework-selection)

  3. Phase 3 — Standards Mapping (standards-mapping)

  4. Phase 4 — Plan Risk Assessment (plan-risk-assessment)

  5. Phase 5 — Impact and Evidence (impact-evidence)

  6. Phase 6 — Backlog Handoff (backlog-handoff)

Phase reference index

  • Phase 1 — Discovery: capture-coaching.md — read this when running exploration-first capture questioning.

  • Phase 2 — Framework Selection: framework-selection.md — read this when choosing which frameworks and conformance level apply.

  • Phase 3 — Standards Mapping: walk the framework references roll-up tables to emit controlMappings; consumed by Phase 5. No dedicated file — mapping is driven by the framework roll-ups.

  • Phase 4 — Plan Risk Assessment: capture-coaching.md governs the questioning posture when escalation triggers reopen scoping; tier criteria are applied per the Accessibility Planner identity instructions and recorded as riskClassification.tier. No dedicated file — the accessibility risk surface is narrow enough to stay inline.

  • Phase 5 — Impact and Evidence: impact-assessment.md — read this when building the evidence register, tradeoff log, and seed work-items.

  • Phase 6 — Backlog Handoff: backlog-handoff.md — read this when rendering work items and validating handoff gates.

Method adequacy (decide vs inform)

Method adequacy is the doctrine that a verification method may only be recorded as satisfying a success criterion when that method can actually decide the criterion. A method that can observe a related signal but cannot confirm the user-facing outcome only informs the criterion; it raises or lowers suspicion but never closes it. This section is the canonical definition; the planner evidence register, the reviewer verdict logic, and the runtime probe harness all resolve adequacy through it.

The machine-readable adequacy source is scripts/runtime_a11y/probe-criteria-map.json. Each probe entry lists the criteria it decides and the criteria it only informs. A result counts as adequate only when the winning method appears in the decides list for that criterion and state.

Failure classes and adequate methods

Accessibility defects generalize into five classes. Static analysis (axe, eslint-plugin-jsx-a11y, snapshot structure counts) can decide only the first class; the remaining four require an interaction-state probe or an assistive-technology (AT) pass to be decided rather than merely informed.

ClassRepresentative WCAG SCWhat static analysis can doAdequate method to decide
Static-decidable structure1.1.1, 1.4.3, 4.1.2 (name present), 2.4.2, 3.1.1Decideaxe / static scan
Interaction behavior2.1.1, 2.1.2, 2.4.3, 2.4.7, 2.4.11Inform onlyKeyboard/interaction probe driving keys across focus/open states, or manual keyboard pass
Announcement correctness1.3.1, 4.1.2 (computed name/role), 4.1.3Inform onlyAccessibility-tree assertion of computed name/role/live, or manual AT pass (Windows NVDA or human-led JAWS)
Adaptive rendering1.4.4, 1.4.10, 1.4.12, 2.4.11Inform onlyRendered probe at 200% zoom, 320px reflow, and text-spacing states
Faux semantics1.3.1 (faux headings), 2.4.3 (faux controls)Cannot seeHeuristic source pass plus accessibility-tree assertion; no element exists for a rule engine to flag

For the announcement class, the assistive-technology announcement model specifies what the user should hear per criterion and how to decide it. For the interaction and faux-semantics classes, the focus-management anti-pattern catalog enumerates the defects that pass a static scan yet break keyboard and screen-reader users.

Adequacy rule

  • A control in the interaction, announcement, adaptive-rendering, or faux-semantics classes cannot be recorded as fully satisfied on static evidence alone. Static evidence caps such a control at a partial state until an adequate method is attached.

  • A criterion whose winning method only informs it is never a conformance verdict; it is a lead that routes to an adequate method or a manual pass.

  • Preserve the adequacy determination alongside the status so downstream planners and reviewers do not re-promote an inadequately verified control.

This doctrine and its class taxonomy are repository-original content licensed under CC BY 4.0; the underlying success-criterion definitions remain with WCAG 2.2 as cited in wcag-22.md.

Calibration is evidence quality, not a conformance verdict

Calibration establishes that the assistive-technology stack behaves as expected before its output is trusted. Its checkpoints record driver identity, profile fingerprint, and artifact hashes for a journey that passed.

A checkpoint is deliberately not a matrix input. Nothing in the coverage or outcome pipeline reads one, and that separation is intended rather than unfinished. A passing calibration says the harness was working; it does not say the surface satisfies a success criterion. Wiring checkpoints into coverage would turn a statement about the tool into a statement about the product.

If calibration evidence should ever influence coverage, that is new design work requiring its own review: it needs an explicit mapping from a journey to a criterion, surface, and state, and it must respect the same method-adequacy rules as any other evidence.

Gate strictness by assessment tier

The enforcement posture for the interaction, announcement, adaptive-rendering, and faux-semantics classes graduates with the assessment depth tier recorded in riskClassification.tier, so the gate inherits the rigor a project opted into rather than applying one global switch:

  • basic — the adequate-method probes (keyboard, widget-keyboard, live-region, aria-tree, virtual-sr) report advisory (warn-only); the always-decidable core probes still block.

  • standard (default) — ratchet: the adequate-method probes block on new or changed surfaces and stay advisory over the existing backlog, so no new defect in these classes ships while legacy content is surfaced without freezing the project.

  • comprehensive — the adequate-method probes block on every in-scope surface.

The always-decidable core probes (axe, DOM hygiene, broken links, console errors, target size, contrast, reflow/resize) block at every tier. The CI workflow template implements this dial through the A11Y_TIER and A11Y_RATCHET_SURFACES inputs; the Accessibility Reviewer applies the same graduation to its FAIL and PARTIAL verdicts.

Tooling

The scanner CLI (scripts/scan.py) wraps the Node-based axe-core scanner and normalizes its findings into a stable JSON shape.

Prerequisites

  • Python 3.11+ with uv available on PATH.

  • Node.js with npx available on PATH.

  • Network access on first run so npx can fetch @axe-core/cli.

Quick Start
uv run scripts/scan.py https://example.com --allow-host example.com
uv run scripts/scan.py ./page.html --output results.json
uv run scripts/scan.py file:///path/to/page.html

Loopback HTTP(S) targets need no additional option. Every other remote host requires either a matching, repeatable --allow-host HOST value or the broader --allow-external confirmation. Local paths and local file: URIs must resolve to existing regular files. Network shares, remote file authorities, directories, missing files, credentials, leading-dash targets, and non-HTTP(S) remote schemes are rejected before the axe CLI starts.

Parameters Reference
ParameterRequiredDefaultDescription
targetYes—Authorized HTTP(S) URL or existing regular local file to scan.
--outputNostdoutPath to write the normalized JSON results.
--allow-hostNononeAuthorize one non-loopback HTTP(S) host; repeat as needed.
--allow-externalNofalseConfirm access to any non-loopback HTTP(S) host.

Remote authorization applies to the initial scanner target only. It does not constrain browser redirects, DNS address changes, subresources, WebSockets, Service Workers, downloads, or other browser-derived requests. Run the scanner only from a workstation whose network reach matches the target's trust level.

Script Reference

  • Entrypoint: scripts/scan.py

  • Output shape:

    {
  "target": "<scanned target>",
  "summary": {
    "violations": 0,
    "passes": 0,
    "incomplete": 0,
    "inapplicable": 0
  },
  "violations": [
    { "id": "", "impact": "", "description": "", "nodes": 0 }
  ]
}

  • Exit codes:

    • 0 — scan completed successfully.

    • 1 — scan failed or returned invalid output.

    • 2 — scanner unavailable (Node.js or @axe-core/cli missing).

Troubleshooting
SymptomLikely causeActionExit code
scanner unavailable errorNode.js or npx not on PATHInstall Node.js so npx resolves, then re-run.2
Long pause or download on first runnpx is fetching @axe-core/cliAllow network access on the first run; later runs use the cache.—
Refusing to probe non-loopback hostRemote host was not explicitly authorizedAdd --allow-host HOST or confirm with --allow-external.2
Local scan target does not existLocal path or file URI cannot be resolvedSupply an existing regular local file, not a directory or share.2
scan failed or returned invalid outputaxe-core CLI errored or emitted non-JSONConfirm the target URL or file is reachable and well-formed.1
Empty violations but issues expectedPage rendered after the scan, or rules N/AConfirm the target fully loads; check summary.inapplicable.0
Mapping findings to frameworks

Each violation's impact is one of minor, moderate, serious, or critical. axe rule tags decode to WCAG success criteria by stripping the wcag prefix and inserting decimals:

axe tagWCAG success criterion
wcag1111.1.1 Non-text Content
wcag1431.4.3 Contrast (Minimum)

WCAG success criteria are normative; the axe techniques that surface them are informative. Treat scanner output as evidence pointing at a criterion, not a conformance verdict.

Runtime probe harness

The runtime probe harness (scripts/runtime_a11y) runs Playwright-based accessibility probes against a project-specific surface inventory and aggregates the results into a coverage matrix. For workflow orchestration, ask the user to run the manual-only accessibility-coverage-matrix skill (/accessibility-coverage-matrix); it is not model-invocable. Use the Accessibility Surface Inventory subagent as the canonical producer of the runtime config. Activate it by name; when it does not resolve, warn the user that the capability is unavailable and stop the dependent step.

Harness prerequisites

Complete these once before any runtime-harness command. They are separate from the scan.py prerequisites above.

  • Python 3.11+ with uv available on PATH.

  • Node.js available on PATH, plus system Google Chrome, because the probes target channel: 'chrome'.

  • Skill-local Node dependencies installed under scripts/runtime_a11y. The CLI fails fast with an install hint when they are missing.

  • Automated Windows NVDA runs additionally require the manifest-selected Guidepup NVDA asset. Machine setup and asset installation are separate actions from npm ci.

Install the harness dependencies from the scripts/runtime_a11y directory:

PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=1 npm ci
$env:PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD = '1'; npm ci

PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=1 avoids downloading bundled browsers that the harness never uses.

For automated NVDA runs, prepare the Windows machine once, then install the asset selected by the skill-local Guidepup package. Run the asset command again after updating Guidepup:

Set-Location <skill-root>/scripts/runtime_a11y
npx --yes --registry=https://registry.npmjs.org/ @guidepup/[email protected] setup
npx --yes --registry=https://registry.npmjs.org/ @guidepup/[email protected] install nvda

The commands configure the machine and write versioned assets to the Guidepup user cache. They are not part of ordinary dependency installation. Run the prerequisite-only probe before a calibration session:

uv run scripts/runtime_a11y/__main__.py run-calibration --config <path-to>/a11y-runtime.config.json --prerequisite-only

The preflight reports the skill-local library, manifest-selected NVDA asset, and any conflicting NVDA process independently. Do not start a personal NVDA instance before an automated run; the harness starts an isolated session and rejects an existing process.

Product-neutral screen-reader cases live in scripts/runtime_a11y/screen-reader-cases.json. A downstream binding supplies named routes, targets, states, and explicit execution recipes. Catalog digest drift, missing target closure, duplicate identities, unsupported commands, secret-bearing binding keys, and inferred actions fail before browser startup.

Use repeatable run-calibration --journey <id> arguments for an authorized live subset. Run the downstream integrity recipe before product cases and keep real NVDA advisory/manual. For deterministic evidence, use run-all --probe <probe-id> with surface/state filters or a reviewed probeScoping configuration; ordinary run-all must not be treated as permission to start a real screen reader.

Invocation

Run the harness through its script entrypoint. Invoke it from the skill root, which is the directory holding pyproject.toml, so uv resolves the skill's own environment. This matches the invocation convention used by scan.py and the other Python skills, and it needs no PYTHONPATH.

uv run scripts/runtime_a11y/__main__.py run-all --config a11y-runtime.config.json --out results.json
uv run scripts/runtime_a11y/__main__.py probe <probeId> --config a11y-runtime.config.json
uv run scripts/runtime_a11y/__main__.py render-artifacts --matrix coverage-matrix-repo.json --output-dir .copilot-tracking/accessibility/coverage --repo-slug repo
uv run scripts/runtime_a11y/__main__.py compose-evidence --help

To run from any other working directory, pin the skill as the uv project and use the same script path:

uv run --project <skill-root> <skill-root>/scripts/runtime_a11y/__main__.py run-all --config a11y-runtime.config.json --out results.json

  • --config resolves relative to the current working directory.

  • --out writes the aggregated JSON document to disk.

  • --base-url overrides the configured base URL. It must remain a loopback origin unless the host is allowlisted or --allow-external is supplied.

  • --trace captures Playwright traces and screenshots.

  • --allow-external confirms intentional probing of a non-loopback host.

  • render-artifacts turns a rendered matrix JSON document into the complete coverage evidence bundle.

Evidence bundle composition

compose-evidence combines downstream-owned catalogs, cadence scope, run context, normalized source envelopes, state proofs, and optional qualified-reviewer supplements into one deterministic evidence bundle. It is separate from render-artifacts: rendering creates coverage, EARL, and manual-plan views from a matrix, while composition creates a revision-bound trust envelope across evidence producers.

The command requires explicit input paths and never infers product scope, Git state, time, retention, branch policy, or a release verdict. A consuming project owns those decisions. The composer validates artifact bytes beneath --artifact-root, preserves conflicts and quarantined results, and always emits non-attestation metadata. Automation, reviewer evidence, and release evidence have separate completeness states.

For pull requests, a valid initial bundle may report reviewer evidence as pending. A qualified reviewer can later provide a privacy-minimized, digest-bound supplement and registry snapshot for deterministic recomposition against the prior bundle. Recomposition supplies both --prior-bundle and its independently retained --prior-bundle-digest; omission or mutation of prior history fails closed. Missing required reviewer evidence blocks release completeness, not ordinary bundle production. Raw screen-reader phrases and restricted transcript paths are forbidden in ordinary bundles; only approved counts, redacted metadata, and digests cross this boundary.

Use --require-completeness automated, reviewer, or release only when the downstream workflow intends that dimension to gate. Valid incomplete bundles are still written for diagnosis. The additional exits are:

Exit codeMeaning
5Automated evidence is incomplete.
6Reviewer evidence is pending or invalid.
7Release evidence is incomplete.

Existing exits 0 through 4 retain their meanings. The JSON contracts live beside the runtime at evidence-bundle.schema.json, evidence-source.schema.json, evidence-scope.schema.json, screen-reader-method-cell.schema.json, and qualified-human-result.schema.json.

For a complete adopter path from an inactive template to a first retained bundle and deterministic recomposition, including schema-valid examples for every authored input, read references/evidence-composition-adoption.md.

Visual review capture

capture-visual-review records deterministic screenshot evidence for the configured surfaces and states. It requires visualReview.enabled to be true in the runtime config.

uv run scripts/runtime_a11y/__main__.py capture-visual-review \
  --config <path-to>/a11y-runtime.config.json \
  --run-root .copilot-tracking/accessibility/local-runs/<run-name>

  • --run-root selects the evidence directory. It resolves relative to the repository root and must land on a child path inside .copilot-tracking/accessibility/local-runs. Paths outside that root, and traversal segments, are rejected.

  • Omitting --run-root allocates a timestamped run directory beneath that same root.

  • --visual-surface and --visual-state narrow the capture to specific configured ids.

  • The server the command targets follows serveMode. See Server modes.

Server modes

serveMode in the runtime config decides whether the harness manages a server for capture-visual-review.

serveModeBehavior
autoReuses a healthy server at the configured loopback origin, otherwise builds and starts one it owns and stops afterward.
servedRequires a server already answering the configured loopback origin, and fails with the expected origin and start command when none responds.
externalNever probes or starts a server. The configured target must already be reachable.
offNever probes or starts a server.

auto and served accept only loopback origins, because the harness will not manage or health-probe a remote server. A non-loopback target still requires the allowlist or --allow-external, and is only valid with external or off.

Under auto, starting an owned server builds the site first, so a capture that has to start its own server takes several minutes before the first screenshot. Leave a server running at the configured origin to skip that cost, which is the reuse path.

The Docusaurus site in this repository is configured for auto at http://127.0.0.1:3001, which is the same production-build origin the Playwright end-to-end suite uses. Capturing against the production build keeps visual evidence consistent with what continuous integration verifies.

Config summary

The harness loads scripts/runtime_a11y/config-schema.json and expects a runtime config with fields such as baseUrl, serveMode, allowlist, routes, surfaces, and probeScoping. The config defines the surfaces and interaction states the probes execute. A runtime guard blocks non-loopback targets unless the host is allowlisted or the caller supplies --allow-external. serveMode controls server ownership for visual review capture, described under Server modes.

Real-NVDA journeys support three capture modes:

  • single reads the cumulative speech log after commands and the configured settle interval.

  • clear-and-capture clears earlier speech before the settle interval, then reads the cumulative log.

  • action wraps an existing post-start declarative trigger with Guidepup action capture. Assertions can select actionSpeech or actionNormalizedSpeech to evaluate only output attributed to that trigger.

Action capture waits for Guidepup's one-second speech quiet window. It is appropriate for immediate interaction-driven announcements but does not extend to arbitrary delayed updates and cannot create speech that NVDA does not emit. Keep single, clear-and-capture, accessibility-tree evidence, and manual AT evidence available for those cases. Action mode fails closed when the journey lacks triggerAfterDriverStart, a declarative trigger, a real Guidepup driver, or action-capture support.

Probe inventory and adequacy map

The harness currently includes these probes under scripts/runtime_a11y/runner:

WCAG and ARIA APG probes:

  • probe-axe

  • probe-keyboard-traversal

  • probe-focus-visible

  • probe-focus-obscured

  • probe-live-region

  • probe-aria-tree

  • probe-widget-keyboard

  • probe-reflow-resize

  • probe-target-size

  • probe-contrast

  • probe-forced-colors

  • probe-reduced-motion

  • probe-structure-crawl

  • probe-name-in-label

  • probe-use-of-color (1.4.1)

  • probe-text-spacing (1.4.12)

  • probe-hover-focus (1.4.13)

  • probe-link-purpose (2.4.4)

  • probe-input-purpose (1.3.5)

  • probe-forms (3.3.2, informs 3.3.1/3.3.3)

  • probe-context-change (3.2.1, 3.2.2)

  • probe-orientation (1.3.4)

  • probe-audio-control (1.4.2)

  • probe-timing (2.2.1)

  • probe-zoom-blocker (1.4.4, informs 1.4.10)

  • probe-virtual-sr (4.1.2 name/role announcement captured from a virtual screen reader's spoken-phrase log; informs 1.3.1)

  • probe-real-sr (real Windows NVDA announcement assertions through a Guidepup adapter; only decides when configured expectations are present and the AT stack is available)

Non-WCAG defect-scan probes (framework defect-scan):

  • probe-console-errors (console/page errors)

  • probe-broken-links (same-origin 404s)

  • probe-dom-hygiene (duplicate ids, positive tabindex, missing/duplicate landmarks)

  • probe-title-lang (empty title, invalid lang)

Method adequacy is encoded in scripts/runtime_a11y/probe-criteria-map.json. Each entry records which criteria a probe can decide and which criteria it can only inform. A result only counts as adequate when the winning method is allowed by that mapping.

Coverage engine outputs

The matrix engine in scripts/runtime_a11y/matrix expands the criterion x surface x state grid, merges updates deterministically, and preserves human-confirmed findings over lower-priority automation. It computes adequate-coverage percentages by framework and overall. The render-artifacts command emits a deterministic bundle containing coverage-matrix-{repo-slug}.json, coverage-matrix-{repo-slug}.md, accessibility-results-{repo-slug}.earl.jsonld, manual-at-testplan-{repo-slug}.md, manual-at-testplan-{repo-slug}.yaml, and accessibility-artifacts-{repo-slug}.json.

The EARL (Evaluation and Report Language) JSON-LD export is the normalized results contract for interoperability with the ACT Rules ecosystem and downstream VPAT or EAA review. Each evaluated cell becomes one stable earl:Assertion that records subject, criterion, state, method, method adequacy, result date, and evidence. A result whose winning method only informs its criterion is earl:cantTell, never a false earl:passed. Inapplicable cells are earl:inapplicable; unevaluated cells are omitted. The paired manual plans contain cells that still require a human-deciding method and provide blank result fields for evidence writeback.

Public ARIA-AT and execution contract

The catalog in scripts/runtime_a11y/aria-at-catalog.json is the repository's documented source of truth for generated AT-oriented cases. Its provenance fields are strict and immutable: each mapping records a local catalog version, a canonical upstream URL, a commit-pinned upstream URL, and the upstream commit SHA used for the reviewed refresh. The repository does not copy upstream assertion tables or prose; it paraphrases official W3C and ARIA-AT intent and cites the source in the generated artifacts.

The current public posture is intentionally conservative. The five starter defaults (modal dialog, checkbox, select-only combobox, menu button, and tabs) are citation-bearing manual-only mappings because the richer AT-mode and quick-navigation semantics that these patterns can require are not faithfully modeled by the current structured command boundary. Runtime overrides may create explicit synthetic contract tests, but those are always non-pass candidate evidence and never accessibility conformance evidence. The resolver uses the documented fallback order of state -> surface -> catalog; commands and assertions are stored as atomic arrays, and an explicit empty array intentionally disables execution for a given case.

Unknown patterns remain generic manual drafts or project-refinement markers rather than a fake automation pass. Equally specific ambiguity is treated as a configuration error before rendering or driver startup. The public CLI exposes render-artifacts as an optional mapping configuration step and run-at-plan as the supported path for listing, selecting, executing, and reporting generated AT cases. The real-driver boundary currently supports Guidepup-backed Windows NVDA automation plus manual-only JAWS and other operator-led flows; synthetic execution is a separate evidence channel and never claims a pass. The generated manual plans stay linked to the shared real screen reader testing runbook, while case-specific commands remain inside the generated plan output rather than being written back into the matrix or coverage artifacts.

The generated manual cases, synthetic or real execution evidence, ACT-style result reasoning, EARL outcomes, and later qualified-human review are distinct layers. The public workflow renders representative fixtures through the documented CLI and inspects the six generated artifacts, but it does not commit golden outputs for the inspection bundle.

Exit codes

  • 0 indicates the harness completed successfully, even when probes reported findings.

  • Non-zero exit codes indicate a harness error such as invalid config, a failed probe, missing Node.js, uninstalled harness dependencies, missing browser support, or a blocked target.

verify-intent adds two design-intent codes that a consuming project's CI can distinguish:

Exit codeMeaningTypical response
3A blocking expectation resolved failedTreat as intent drift; the surface regressed
4A blocking expectation was never evaluatedTreat as coverage drift; the check did not run

The two are separate because a failed check and an unrun check call for different responses. Reusing one code would let missing coverage read as a regression, or pass silently.

Runtime dependencies

The harness resolves its Node dependencies from a skill-local package under scripts/runtime_a11y (package.json plus committed package-lock.json), pinning [email protected], @axe-core/[email protected], @guidepup/[email protected], and optional real-AT integration through @guidepup/[email protected]. Install the Node dependencies and the separately managed NVDA asset as described under Harness prerequisites. The probes then resolve their dependencies from the local node_modules; the CLI fails fast with an install hint when node_modules is absent, before it probes or starts any server.

Testing

The harness is tested in two tiers. Browserless verdict and pure-helper unit tests run under node --test (repo script test:node) and cover the decision logic in runner/_core.mjs (for example virtualSrNameRoleStatus and liveRegionStatus). Browser smoke tests under tests/runtime_a11y/runner/probe-smoke/ launch system Chrome and drive the real capture path against inline fixtures to prove the DOM-to-verdict pipeline, including nameless controls, live-region firing, forced-color computed styles, and CDP accessibility-node structure. They are named *.smoke.mjs so the default browserless run skips them. PR Validation runs them through the CI-owned npm run ci:test:a11y:smoke entry point. Local reproduction requires system Chrome and the skill-local node_modules.

CI regression gate

Use the ready-to-copy workflow template at references/ci/accessibility-coverage.workflow-template.yml as the documentation-first integration point for a target project. Copy it into the target repository's GitHub Actions workflow directory only after the target project commits an a11y-runtime.config.json and has a build/serve path that the template can invoke. Once authored *.intent.yaml records exist, the template fails closed if the config or current-run results are missing.

The template mirrors the Docusaurus workflow recipe by provisioning system Chrome, setting up Node 24 plus Python and uv, building the target, serving it under a configurable base URL, and running the harness script entrypoint with uv run --project pinned at the vendored skill root. The core high-confidence probes always block: probe-axe, probe-dom-hygiene, probe-broken-links, probe-console-errors, probe-target-size, probe-contrast, and probe-reflow-resize. The interaction-state and announcement probes (probe-keyboard-traversal, probe-widget-keyboard, probe-live-region, probe-aria-tree, probe-virtual-sr, probe-real-sr) are the adequate method for the classes static analysis only informs, and their blocking posture follows the A11Y_TIER dial defined under Gate strictness by assessment tier: basic reports them advisory, standard ratchets (blocking on the surfaces listed in A11Y_RATCHET_SURFACES), and comprehensive blocks them everywhere. The remaining heuristic probes such as use-of-color, hover-focus, link-purpose, name-in-label, and focus-* are surfaced as informational results so they can guide follow-up work without blocking initial adoption. The real-screen-reader probe stays advisory by default unless a project opts into it through configured expected assertions and a supported OS/AT stack; it returns candidate when the platform or AT is unavailable rather than pretending a pass or failure. Decisive coverage of the adaptive-rendering class depends on the target committing the zoom-200, reflow-320, and text-spacing states in its a11y-runtime.config.json.

The parity reference at references/ci/probe-spec-parity.md maps each runtime probe to the closest existing Docusaurus e2e spec and highlights gaps where no equivalent spec currently exists.

The references/ci/act-rule-format.md reference documents how the harness's probes, generated test cases, and EARL results align to the W3C ACT Rules Format (applicability, expectation, passed/failed/inapplicable) so results interoperate with the ACT Rules ecosystem and conformance reporting.

Design intent verification

A consuming project can declare what a surface must convey and have CI check that what shipped still matches. The declaration is a Design Intent Record, human-authored and committed at design-intent/<surface-id>.intent.yaml in that project. Each intent states what the surface must communicate, why, and for whom, and binds every claim to a named check.

The authored-record field contract is in references/design-intent/record-contract.md. Read it when authoring or reviewing a record. This section covers verification.

This skill supplies the step that turns a probe run into a verdict against that declaration.

Invocation
uv run --project <skill-root> <skill-root>/scripts/runtime_a11y/__main__.py verify-intent \
  --record design-intent/<surface-id>.intent.yaml \
  --results results.json

  • --record is the authored record. It is never read for anything but its declarations and never rewritten.

  • --results is a results document from run-all.

  • --out overrides the output path, which defaults to design-intent/.verification/<surface-id>.earl.json beside the record.

How results resolve to outcomes

A result row matches an expectation when its surface, state, emitting probe, and criterion all match what the record declares. Because criterion coverage overlaps across probes, the emitting probe is part of the join.

SituationOutcomeMode
Every matched criterion passedpassedautomatic
Any matched criterion failedfailedautomatic
Evidence gathered but not decisivecantTellautomatic
No result row matched the expectationuntestedautomatic
The expectation uses assert: customuntestedmanual

An expectation is one claim over one or more criteria, so the worst criterion outcome governs. Expectations the run did not cover report untested rather than being omitted, which keeps a missing check visible instead of silently absent.

Expectations whose criteria a probe only informs resolve to cantTell in normal operation. That is expected: the probe gathered evidence without settling the claim.

A custom expectation reports untested whether or not the record carries a human override. The adapter records only observed runtime outcome in the artifact. Human override remains authoritative in the record itself and is not merged into the generated artifact outcome.

Interpretation is two-layered by contract, and the generated artifact now carries both layers on every assertion:

  • observedOutcome is the generated artifact field outcome. An override never replaces it.

  • effectiveOutcome applies fail-safe precedence. Either an observed or human failed outcome yields failed; human passed settles only untested, cantTell, or inapplicable; otherwise the observed outcome remains. This is the value the gate applies.

  • overrideConflict is true only when the observed and authored override outcomes are each passed or failed and differ. An override that settles an untested, cantTell, or inapplicable expectation is the documented use, not a conflict.

A conclusive conflict fails closed. verify-intent writes one Warning: line to stderr for each conflicting assertion, names the intent, expectation, observed outcome, and override outcome, and returns design-intent drift when the conflicting expectation blocks.

The shipped Python verifier rejects duplicate YAML keys, validates the complete authored schema, and enforces semantic checks for dates, filename and runtime-config bindings, duplicate identifiers, method pairing, and probe adequacy before writing an artifact. This repository's PowerShell validator independently enforces the same contract for source and generated-artifact validation.

Exit codes

  • 0 — the artifact was written and no blocking expectation failed.

  • 1 — the record or results document was malformed. Nothing is written.

  • 2 — the record or results document could not be read.

  • 3 — the artifact was written and a blocking expectation failed.

  • 4 — the artifact was written and a blocking expectation was never evaluated.

Exit codes 3 and 4 are enforcement signals. A consuming project's CI step fails its build on either non-zero exit, exactly as it would for any other command. The artifact is still written so the run can publish it. Which expectations block is the record's decision, through each expectation's blocking flag.

Graphics and diagram semantics have no runtime probe. Those expectations use assert: custom and resolve through human review; see the Graphics ARIA and SVG-AAM reference for the boundary between what automation can decide and what it cannot.

Rendering a record for review

A record states what must be true and how it is checked, but carries no implementation or delivery scope. Reviewers who want prose rather than YAML can render one:

uv run --project <skill-root> <skill-root>/scripts/runtime_a11y/__main__.py project-intent \
  --record design-intent/<surface-id>.intent.yaml \
  --out handoff.md

Output is deterministic and renders only what the record already says, adding no analysis and no verification results. Generate it on demand rather than committing it, so it cannot drift from the record it describes. Without --out the Markdown goes to stdout.

Usage notes

  • Treat this skill as the default accessibility entrypoint for planning and review workflows.

  • Resolve framework and phase guidance through this skill instead of duplicating its internal reference paths in agents or instructions.

  • Use the scanner CLI when you need normalized findings from an accessibility scan.

Files

references/frameworks/wcag-22.md

title: WCAG 2.2 framework reference description: Web Content Accessibility Guidelines (WCAG) 2.2 success criteria packaged as an accessibility assessment knowledge base for the Accessibility Planner and Skill Assessor subagent

WCAG 2.2 framework reference

This SKILL.md is the entrypoint for the Web Content Accessibility Guidelines (WCAG) 2.2 framework skill used by the Accessibility Planner and the Accessibility Skill Assessor subagent.

WCAG 2.2 is published by the W3C Web Accessibility Initiative as a W3C Recommendation. It organises 86 active success criteria (plus 1 obsolete criterion, SC 4.1.1 Parsing) under four foundational principles (Perceivable, Operable, Understandable, Robust) and 13 guidelines. Each success criterion is assigned one of three conformance levels: A, AA, or AAA.

Source: W3C Web Content Accessibility Guidelines (WCAG) 2.2, https://www.w3.org/TR/WCAG22/.

Licensing posture

WCAG 2.2 is published under the W3C Document License. This skill paraphrases success-criterion intent rather than reproducing normative text verbatim, in line with the paraphrase-preferred posture defined in accessibility-license-posture.instructions.md. Every per-guideline reference file cites the canonical W3C URL for each success criterion, and any future verbatim quotation must carry the W3C copyright attribution line specified in that instruction file. When that instruction content is unavailable, apply the paraphrase-only posture stated here and do not quote normative text verbatim, because the required attribution line cannot be confirmed.

Success-criterion roll-up

The table below lists every WCAG 2.2 success criterion. The Reference column links into the per-guideline reference file using an anchor that matches the section header for that criterion.

SCTitleLevelPrincipleReference
1.1.1Non-text ContentAPerceivableguideline-1-1.md#sc-1-1-1
1.2.1Audio-only and Video-only (Prerecorded)APerceivableguideline-1-2.md#sc-1-2-1
1.2.2Captions (Prerecorded)APerceivableguideline-1-2.md#sc-1-2-2
1.2.3Audio Description or Media Alternative (Prerecorded)APerceivableguideline-1-2.md#sc-1-2-3
1.2.4Captions (Live)AAPerceivableguideline-1-2.md#sc-1-2-4
1.2.5Audio Description (Prerecorded)AAPerceivableguideline-1-2.md#sc-1-2-5
1.2.6Sign Language (Prerecorded)AAAPerceivableguideline-1-2.md#sc-1-2-6
1.2.7Extended Audio Description (Prerecorded)AAAPerceivableguideline-1-2.md#sc-1-2-7
1.2.8Media Alternative (Prerecorded)AAAPerceivableguideline-1-2.md#sc-1-2-8
1.2.9Audio-only (Live)AAAPerceivableguideline-1-2.md#sc-1-2-9
1.3.1Info and RelationshipsAPerceivableguideline-1-3.md#sc-1-3-1
1.3.2Meaningful SequenceAPerceivableguideline-1-3.md#sc-1-3-2
1.3.3Sensory CharacteristicsAPerceivableguideline-1-3.md#sc-1-3-3
1.3.4OrientationAAPerceivableguideline-1-3.md#sc-1-3-4
1.3.5Identify Input PurposeAAPerceivableguideline-1-3.md#sc-1-3-5
1.3.6Identify PurposeAAAPerceivableguideline-1-3.md#sc-1-3-6
1.4.1Use of ColorAPerceivableguideline-1-4.md#sc-1-4-1
1.4.2Audio ControlAPerceivableguideline-1-4.md#sc-1-4-2
1.4.3Contrast (Minimum)AAPerceivableguideline-1-4.md#sc-1-4-3
1.4.4Resize TextAAPerceivableguideline-1-4.md#sc-1-4-4
1.4.5Images of TextAAPerceivableguideline-1-4.md#sc-1-4-5
1.4.6Contrast (Enhanced)AAAPerceivableguideline-1-4.md#sc-1-4-6
1.4.7Low or No Background AudioAAAPerceivableguideline-1-4.md#sc-1-4-7
1.4.8Visual PresentationAAAPerceivableguideline-1-4.md#sc-1-4-8
1.4.9Images of Text (No Exception)AAAPerceivableguideline-1-4.md#sc-1-4-9
1.4.10ReflowAAPerceivableguideline-1-4.md#sc-1-4-10
1.4.11Non-text ContrastAAPerceivableguideline-1-4.md#sc-1-4-11
1.4.12Text SpacingAAPerceivableguideline-1-4.md#sc-1-4-12
1.4.13Content on Hover or FocusAAPerceivableguideline-1-4.md#sc-1-4-13
2.1.1KeyboardAOperableguideline-2-1.md#sc-2-1-1
2.1.2No Keyboard TrapAOperableguideline-2-1.md#sc-2-1-2
2.1.3Keyboard (No Exception)AAAOperableguideline-2-1.md#sc-2-1-3
2.1.4Character Key ShortcutsAOperableguideline-2-1.md#sc-2-1-4
2.2.1Timing AdjustableAOperableguideline-2-2.md#sc-2-2-1
2.2.2Pause, Stop, HideAOperableguideline-2-2.md#sc-2-2-2
2.2.3No TimingAAAOperableguideline-2-2.md#sc-2-2-3
2.2.4InterruptionsAAAOperableguideline-2-2.md#sc-2-2-4
2.2.5Re-authenticatingAAAOperableguideline-2-2.md#sc-2-2-5
2.2.6TimeoutsAAAOperableguideline-2-2.md#sc-2-2-6
2.3.1Three Flashes or Below ThresholdAOperableguideline-2-3.md#sc-2-3-1
2.3.2Three FlashesAAAOperableguideline-2-3.md#sc-2-3-2
2.3.3Animation from InteractionsAAAOperableguideline-2-3.md#sc-2-3-3
2.4.1Bypass BlocksAOperableguideline-2-4.md#sc-2-4-1
2.4.2Page TitledAOperableguideline-2-4.md#sc-2-4-2
2.4.3Focus OrderAOperableguideline-2-4.md#sc-2-4-3
2.4.4Link Purpose (In Context)AOperableguideline-2-4.md#sc-2-4-4
2.4.5Multiple WaysAAOperableguideline-2-4.md#sc-2-4-5
2.4.6Headings and LabelsAAOperableguideline-2-4.md#sc-2-4-6
2.4.7Focus VisibleAAOperableguideline-2-4.md#sc-2-4-7
2.4.8LocationAAAOperableguideline-2-4.md#sc-2-4-8
2.4.9Link Purpose (Link Only)AAAOperableguideline-2-4.md#sc-2-4-9
2.4.10Section HeadingsAAAOperableguideline-2-4.md#sc-2-4-10
2.4.11Focus Not Obscured (Minimum)AAOperableguideline-2-4.md#sc-2-4-11
2.4.12Focus Not Obscured (Enhanced)AAAOperableguideline-2-4.md#sc-2-4-12
2.4.13Focus AppearanceAAAOperableguideline-2-4.md#sc-2-4-13
2.5.1Pointer GesturesAOperableguideline-2-5.md#sc-2-5-1
2.5.2Pointer CancellationAOperableguideline-2-5.md#sc-2-5-2
2.5.3Label in NameAOperableguideline-2-5.md#sc-2-5-3
2.5.4Motion ActuationAOperableguideline-2-5.md#sc-2-5-4
2.5.5Target Size (Enhanced)AAAOperableguideline-2-5.md#sc-2-5-5
2.5.6Concurrent Input MechanismsAAAOperableguideline-2-5.md#sc-2-5-6
2.5.7Dragging MovementsAAOperableguideline-2-5.md#sc-2-5-7
2.5.8Target Size (Minimum)AAOperableguideline-2-5.md#sc-2-5-8
3.1.1Language of PageAUnderstandableguideline-3-1.md#sc-3-1-1
3.1.2Language of PartsAAUnderstandableguideline-3-1.md#sc-3-1-2
3.1.3Unusual WordsAAAUnderstandableguideline-3-1.md#sc-3-1-3
3.1.4AbbreviationsAAAUnderstandableguideline-3-1.md#sc-3-1-4
3.1.5Reading LevelAAAUnderstandableguideline-3-1.md#sc-3-1-5
3.1.6PronunciationAAAUnderstandableguideline-3-1.md#sc-3-1-6
3.2.1On FocusAUnderstandableguideline-3-2.md#sc-3-2-1
3.2.2On InputAUnderstandableguideline-3-2.md#sc-3-2-2
3.2.3Consistent NavigationAAUnderstandableguideline-3-2.md#sc-3-2-3
3.2.4Consistent IdentificationAAUnderstandableguideline-3-2.md#sc-3-2-4
3.2.5Change on RequestAAAUnderstandableguideline-3-2.md#sc-3-2-5
3.2.6Consistent HelpAUnderstandableguideline-3-2.md#sc-3-2-6
3.3.1Error IdentificationAUnderstandableguideline-3-3.md#sc-3-3-1
3.3.2Labels or InstructionsAUnderstandableguideline-3-3.md#sc-3-3-2
3.3.3Error SuggestionAAUnderstandableguideline-3-3.md#sc-3-3-3
3.3.4Error Prevention (Legal, Financial, Data)AAUnderstandableguideline-3-3.md#sc-3-3-4
3.3.5HelpAAAUnderstandableguideline-3-3.md#sc-3-3-5
3.3.6Error Prevention (All)AAAUnderstandableguideline-3-3.md#sc-3-3-6
3.3.7Redundant EntryAUnderstandableguideline-3-3.md#sc-3-3-7
3.3.8Accessible Authentication (Minimum)AAUnderstandableguideline-3-3.md#sc-3-3-8
3.3.9Accessible Authentication (Enhanced)AAAUnderstandableguideline-3-3.md#sc-3-3-9
4.1.1Parsing (Obsolete and removed)DeprecatedRobustguideline-4-1.md#sc-4-1-1
4.1.2Name, Role, ValueARobustguideline-4-1.md#sc-4-1-2
4.1.3Status MessagesAARobustguideline-4-1.md#sc-4-1-3

Assessment heuristics

Per-criterion assessment heuristics, common failure patterns, and scope notes live inside the per-guideline reference files in references/. The Accessibility Skill Assessor subagent consumes the appropriate guideline-<n>-<m>.md#sc-<n>-<m>-<k> section when evaluating a finding against a specific success criterion.

Skill layout

  • SKILL.md — this file (skill entrypoint and roll-up table).

  • references/ — one markdown file per WCAG 2.2 guideline. Each file contains the guideline statement, a paraphrased intent for every success criterion under that guideline, and a canonical W3C source URL.

Guideline 1.1 — Text Alternatives

Guideline 1.1 (Text Alternatives) requires that every non-text element in the experience carry a text alternative that conveys the same purpose, so that the content can be re-rendered in any form that the user needs — large print, braille, speech, symbols, or simpler language.

Source: W3C Web Content Accessibility Guidelines (WCAG) 2.2, Guideline 1.1, https://www.w3.org/TR/WCAG22/#text-alternatives.

sc-1-1-1

SC 1.1.1 Non-text Content (Level A)

Every non-text element exposed in the user interface needs a programmatically associated text alternative that serves the same purpose. Decorative or formatting-only elements may carry an empty or ignorable alternative so that assistive technology skips them, and time-based media, tests, sensory experiences, CAPTCHAs, and pure decoration each have their own narrower exception described in the W3C source.

Applies to: Images, icons, image buttons, image maps, charts, complex graphics, video and audio (for the placeholder text-equivalent), form controls, audio-only and video-only content (placeholder text), CAPTCHAs, and any embedded object exposed to the user.

Assessment heuristics:

  • Confirm that every image conveying meaning carries a non-empty alt, aria-label, or aria-labelledby that paraphrases the information conveyed by the image, not the file name.

  • Confirm that decorative images carry alt="" or role="presentation" so assistive technology skips them.

  • Confirm that image buttons announce the action (for example, "Submit application") rather than the icon name.

  • Confirm that complex graphics carry a short text equivalent plus a longer description accessible via link or aria-describedby.

  • Confirm that CAPTCHAs offer at least two alternative modalities (visual plus audio, plus a non-cognitive option where feasible).

Source: https://www.w3.org/TR/WCAG22/#non-text-content

Guideline 1.2 — Time-based Media

Guideline 1.2 (Time-based Media) requires alternatives for prerecorded and live audio and video content so that users who cannot hear or cannot see the media can still receive the same information through captions, transcripts, audio description, or sign-language interpretation.

Source: W3C Web Content Accessibility Guidelines (WCAG) 2.2, Guideline 1.2, https://www.w3.org/TR/WCAG22/#time-based-media.

sc-1-2-1

SC 1.2.1 Audio-only and Video-only (Prerecorded) (Level A)

For prerecorded audio-only media, provide a text transcript that conveys the same information. For prerecorded video-only media, provide either a text or audio alternative that conveys the equivalent information.

Assessment heuristics:

  • Confirm a transcript is available adjacent to or linked from the audio-only player.

  • Confirm video-only media has either a narrated audio track or a text description that captures the visual narrative.

  • Confirm the transcript identifies speakers and describes meaningful non-speech sounds when present.

Source: https://www.w3.org/TR/WCAG22/#audio-only-and-video-only-prerecorded

sc-1-2-2

SC 1.2.2 Captions (Prerecorded) (Level A)

Synchronised captions accompany all prerecorded audio content that is part of synchronised media, except when the media itself is a media alternative for text and is clearly labelled as such.

Assessment heuristics:

  • Confirm captions are synchronised with speech, identify speakers, and capture meaningful non-speech audio.

  • Confirm captions are an actual caption track (closed or open) rather than auto-generated speech-to-text without human review.

  • Confirm caption playback controls are reachable by keyboard.

Source: https://www.w3.org/TR/WCAG22/#captions-prerecorded

sc-1-2-3

SC 1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A)

For prerecorded synchronised media, provide either an audio description of the video track or a full text alternative that conveys the same information as the combined audio plus video.

Assessment heuristics:

  • Confirm either an audio-described version of the media is offered or a transcript that includes visual description is linked.

  • Confirm the alternative covers actions, characters, scene changes, and on-screen text that are not in the dialogue.

Source: https://www.w3.org/TR/WCAG22/#audio-description-or-media-alternative-prerecorded

sc-1-2-4

SC 1.2.4 Captions (Live) (Level AA)

Synchronised captions accompany all live audio content delivered as part of synchronised media (for example, live webinars, town halls, and streaming events).

Assessment heuristics:

  • Confirm live captioning is staffed by a human captioner or a vetted real-time captioning service for any scheduled live event.

  • Confirm captions are visible on the same surface as the video and remain legible against the underlying picture.

Source: https://www.w3.org/TR/WCAG22/#captions-live

sc-1-2-5

SC 1.2.5 Audio Description (Prerecorded) (Level AA)

Audio description of the video track is provided for all prerecorded synchronised media; a text-only alternative is no longer sufficient at Level AA.

Assessment heuristics:

  • Confirm an audio-described track is offered either as the default audio or as a selectable secondary track.

  • Confirm the audio description fits within natural pauses in the dialogue or that an extended description (SC 1.2.7) is offered.

Source: https://www.w3.org/TR/WCAG22/#audio-description-prerecorded

sc-1-2-6

SC 1.2.6 Sign Language (Prerecorded) (Level AAA)

Sign-language interpretation accompanies prerecorded audio content in synchronised media.

Assessment heuristics:

  • Confirm a sign-language interpreter video is offered in a regional sign language relevant to the audience.

  • Confirm the interpreter window is large enough to read facial expressions and hand shape.

Source: https://www.w3.org/TR/WCAG22/#sign-language-prerecorded

sc-1-2-7

SC 1.2.7 Extended Audio Description (Prerecorded) (Level AAA)

Where pauses in foreground audio are insufficient for standard audio description, an extended audio-described version (pausing the video to allow description) is provided.

Assessment heuristics:

  • Confirm the extended description pauses the video where needed and resumes synchronisation cleanly.

  • Confirm a control is provided to skip or speed through extended descriptions for users who have already heard them.

Source: https://www.w3.org/TR/WCAG22/#extended-audio-description-prerecorded

sc-1-2-8

SC 1.2.8 Media Alternative (Prerecorded) (Level AAA)

A full text alternative is provided for all prerecorded synchronised media and for prerecorded video-only media, covering both dialogue and visual content.

Assessment heuristics:

  • Confirm a full transcript is available that includes speaker tags, non-speech audio cues, and visual scene descriptions.

  • Confirm the transcript is reachable from the same surface as the media.

Source: https://www.w3.org/TR/WCAG22/#media-alternative-prerecorded

sc-1-2-9

SC 1.2.9 Audio-only (Live) (Level AAA)

An alternative for live audio-only content that conveys equivalent information is provided (for example, a live human transcription or sign-language interpretation).

Assessment heuristics:

  • Confirm live audio-only programmes (radio-style streams, telephony bridges) offer a real-time captioning or transcription channel.

Source: https://www.w3.org/TR/WCAG22/#audio-only-live

Guideline 1.3 — Adaptable

Guideline 1.3 (Adaptable) requires that content can be presented in different ways without losing information or structure, so assistive technology can convey relationships, sequence, and meaning that sighted users perceive visually.

Source: W3C Web Content Accessibility Guidelines (WCAG) 2.2, Guideline 1.3, https://www.w3.org/TR/WCAG22/#adaptable.

sc-1-3-1

SC 1.3.1 Info and Relationships (Level A)

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

Assessment heuristics:

  • Confirm headings use semantic heading elements with a sensible nesting order rather than styled paragraphs.

  • Confirm data tables use <th> with appropriate scope or headers/id association rather than visual layout alone.

  • Confirm lists, fieldsets, and landmarks use their native semantic markup.

  • Confirm form controls have programmatically associated labels (label-for, aria-labelledby, or wrapping label).

  • Confirm visual groupings (boxes, columns, bold headings) carry equivalent programmatic structure.

Technique depth:

  • Tables (W3C technique H63): every header cell carries an explicit scope="col" or scope="row". Markdown-generated tables emit <th> without scope, leaving association to assistive-technology inference, which is partial for single-header tables and fails for row-header and complex tables. For a build pipeline, inject scope on all header cells at build time rather than retrofitting source. Complex spanning tables use headers/id; layout tables carry role="presentation".

  • Table names (W3C technique H39, recommended): give each data table an accessible name via <caption> or aria-labelledby/aria-label, so it is announced on entry. A table with no name announces only as a grid of cells.

  • Group names: give each visually-titled group (footer column, sidebar group, table-of-contents list) an accessible name that associates its title with its list, via aria-labelledby the title id or a wrapping role="group"/<nav aria-label>, so the group title is announced before its items.

  • Faux headings: a section title produced by a CSS ::before label, bold text, or a <div class="*__title"> is not a heading element and is absent from the heading outline. Replace it with a real <h*> and move the styling onto the heading selector so appearance is unchanged.

  • The table-name, group-name, faux-heading, and header-association outcomes are announcement-class: decide them with an accessibility-tree assertion or a manual assistive-technology pass per at-announcement-model.md; attribute presence alone only informs 1.3.1.

Source: https://www.w3.org/TR/WCAG22/#info-and-relationships

sc-1-3-2

SC 1.3.2 Meaningful Sequence (Level A)

When the sequence of content affects its meaning, the reading order is programmatically determinable.

Assessment heuristics:

  • Confirm DOM order matches the visual reading order on left-to-right and right-to-left locales.

  • Confirm CSS positioning (float, flex-direction: row-reverse, order) does not desynchronise visual order from DOM order in a way that changes meaning.

  • Confirm tabular and multi-column layouts read in a logical sequence when CSS is disabled.

Source: https://www.w3.org/TR/WCAG22/#meaningful-sequence

sc-1-3-3

SC 1.3.3 Sensory Characteristics (Level A)

Instructions do not rely solely on sensory characteristics such as shape, colour, size, visual location, orientation, or sound.

Assessment heuristics:

  • Confirm instructions like "click the red button" are accompanied by a text label ("click Submit").

  • Confirm instructions that reference shape ("the round icon") add a non-sensory identifier.

  • Confirm spatial instructions ("the menu on the right") include an alternative identifier.

Source: https://www.w3.org/TR/WCAG22/#sensory-characteristics

sc-1-3-4

SC 1.3.4 Orientation (Level AA)

Content does not restrict its view to a single display orientation (portrait or landscape) unless a specific orientation is essential.

Assessment heuristics:

  • Confirm the app, page, or media does not lock to one orientation through CSS, screen.orientation.lock(), or platform manifest entries except where essential (for example, a piano keyboard).

  • Confirm orientation changes do not lose user input or context.

Source: https://www.w3.org/TR/WCAG22/#orientation

sc-1-3-5

SC 1.3.5 Identify Input Purpose (Level AA)

The purpose of each input field that collects information about the user can be programmatically determined when the field corresponds to one of the WCAG-defined input purposes.

Assessment heuristics:

  • Confirm fields collecting personal data (name, email, phone, address, payment) use the autocomplete attribute with the appropriate token.

  • Confirm autocomplete values match the WCAG input-purpose vocabulary.

  • Confirm autofill works as the user expects with the browser's stored data.

Source: https://www.w3.org/TR/WCAG22/#identify-input-purpose

sc-1-3-6

SC 1.3.6 Identify Purpose (Level AAA)

The purpose of user-interface components, icons, and regions can be programmatically determined (for example, through ARIA landmark roles, aria-label, or microdata).

Assessment heuristics:

  • Confirm landmarks (<main>, <nav>, <aside>, <header>, <footer> or equivalent ARIA roles) cover the page.

  • Confirm icons that act as controls expose a programmatic name and role.

  • Confirm symbolic UI controls (icons) carry consistent and machine-readable purpose metadata.

Source: https://www.w3.org/TR/WCAG22/#identify-purpose

Guideline 1.4 — Distinguishable

Guideline 1.4 (Distinguishable) requires that content be easy to see and hear, including separating foreground from background, supporting text resizing and reflow, and providing sufficient contrast for text and non-text UI elements.

Source: W3C Web Content Accessibility Guidelines (WCAG) 2.2, Guideline 1.4, https://www.w3.org/TR/WCAG22/#distinguishable.

sc-1-4-1

SC 1.4.1 Use of Color (Level A)

Colour is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

Assessment heuristics:

  • Confirm required form fields are indicated by text or icon in addition to colour.

  • Confirm errors, warnings, and status callouts carry an icon or text label, not just a colour.

  • Confirm chart legends, link styling, and stateful UI elements use a non-colour cue (underline, pattern, icon, text).

Source: https://www.w3.org/TR/WCAG22/#use-of-color

sc-1-4-2

SC 1.4.2 Audio Control (Level A)

If audio plays automatically for more than 3 seconds, either provide a mechanism to pause or stop the audio or a mechanism to control its volume independently from the overall system volume.

Assessment heuristics:

  • Confirm autoplaying audio carries a visible pause/stop control that is keyboard reachable within the first three seconds.

  • Confirm a media player provides an independent volume control rather than relying solely on OS volume.

Source: https://www.w3.org/TR/WCAG22/#audio-control

sc-1-4-3

SC 1.4.3 Contrast (Minimum) (Level AA)

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for large text (3:1), incidental text, and logotypes.

Assessment heuristics:

  • Confirm body text reaches 4.5:1 against its background using a contrast tool.

  • Confirm large text (18pt regular or 14pt bold) reaches at least 3:1.

  • Confirm placeholder text and disabled-looking states that still convey information meet 4.5:1.

  • Confirm text over images, gradients, or video uses a backplate or shadow that brings effective contrast to 4.5:1.

Source: https://www.w3.org/TR/WCAG22/#contrast-minimum

sc-1-4-4

SC 1.4.4 Resize Text (Level AA)

Text can be resized up to 200 per cent without loss of content or functionality, except for captions and images of text.

Assessment heuristics:

  • Confirm zooming the browser to 200% does not clip content, hide controls, or create horizontal scrolling on text blocks.

  • Confirm text is sized in relative units (rem, em, %) rather than fixed pixels for body copy.

  • Confirm fixed-width controls do not clip their own text at 200%. A recurring failure is a fixed-width search input whose placeholder truncates (for example, "Search" to "Sear") and whose keyboard-shortcut badge collides with the text. Replace fixed width/height with min-width: 0 plus clamp()/%/rem so the field grows or the placeholder ellipsizes gracefully, let the shortcut badge wrap or hide near 200%, and keep images at max-width: 100%.

  • This class is adaptive-rendering: decide it by rendering at 200% zoom (the zoom-200 state), not by reading CSS. Static analysis only informs it.

Source: https://www.w3.org/TR/WCAG22/#resize-text

sc-1-4-5

SC 1.4.5 Images of Text (Level AA)

Text is used to convey information rather than images of text, unless the image is essential (for example, a logotype) or fully customisable by the user.

Assessment heuristics:

  • Confirm marketing banners, navigation labels, and instructional content use HTML text styled with CSS rather than baked-in image text.

  • Confirm logotype images are the only allowed image-of-text exception.

Source: https://www.w3.org/TR/WCAG22/#images-of-text

sc-1-4-6

SC 1.4.6 Contrast (Enhanced) (Level AAA)

Text and images of text have a contrast ratio of at least 7:1 (4.5:1 for large text).

Assessment heuristics:

  • Confirm body text reaches 7:1 contrast for AAA-targeted experiences.

Source: https://www.w3.org/TR/WCAG22/#contrast-enhanced

sc-1-4-7

SC 1.4.7 Low or No Background Audio (Level AAA)

Prerecorded audio that contains primarily speech in the foreground has no background sound, the background sound can be turned off, or the background is at least 20 dB lower than the foreground speech.

Assessment heuristics:

  • Confirm narration tracks reduce or remove background music during speech.

  • Confirm an alternative track with no background music is offered when background sound is desired.

Source: https://www.w3.org/TR/WCAG22/#low-or-no-background-audio

sc-1-4-8

SC 1.4.8 Visual Presentation (Level AAA)

For blocks of text, users can select foreground and background colours, line width does not exceed 80 characters, text is not justified, line and paragraph spacing reach defined minimums, and text resizes to 200% without horizontal scroll.

Assessment heuristics:

  • Confirm a high-contrast or user-themed mode is offered for long-form text.

  • Confirm line length stays below 80 characters in the default presentation.

Source: https://www.w3.org/TR/WCAG22/#visual-presentation

sc-1-4-9

SC 1.4.9 Images of Text (No Exception) (Level AAA)

Images of text are used only for decoration or where a particular presentation of text is essential (no general customisation exemption).

Assessment heuristics:

  • Confirm even customisable imagery rendered with text is replaced with live text for AAA scope.

Source: https://www.w3.org/TR/WCAG22/#images-of-text-no-exception

sc-1-4-10

SC 1.4.10 Reflow (Level AA)

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions, at a viewport width of 320 CSS pixels (or 256 CSS pixels height for vertical scrolling content), except for parts that require two-dimensional layout.

Assessment heuristics:

  • Confirm a 320-pixel-wide viewport (or 400% zoom on a 1280-pixel viewport) does not produce horizontal scrolling on text content.

  • Confirm tables, code blocks, and large images may scroll horizontally only when two-dimensional layout is essential.

  • Confirm an expanded control does not layer over adjacent content at narrow width. A recurring failure is a navbar search field that, when expanded at 320px, overlaps the site brand or H1 and clips its shortcut hint. Reflow the navbar to a single row-with-wrap (or stack the search below the title), collapse the search to its icon until invoked, remove fixed widths, and verify there is no two-dimensional scroll.

  • This class is adaptive-rendering: decide it by rendering at the reflow-320 state, not by reading CSS. Static analysis only informs it.

Source: https://www.w3.org/TR/WCAG22/#reflow

sc-1-4-11

SC 1.4.11 Non-text Contrast (Level AA)

Visual presentation of user-interface components and graphical objects required to understand the content has a contrast ratio of at least 3:1 against adjacent colours.

Assessment heuristics:

  • Confirm form-control borders, focus indicators, and active/selected states reach 3:1 against adjacent colours.

  • Confirm icons that convey information reach 3:1 against their background.

  • Confirm chart elements distinguishable by shape rely on 3:1 contrast for those shape outlines.

Source: https://www.w3.org/TR/WCAG22/#non-text-contrast

sc-1-4-12

SC 1.4.12 Text Spacing (Level AA)

No loss of content or functionality when users override line height (1.5x font), paragraph spacing (2x font), letter spacing (0.12x font), and word spacing (0.16x font).

Assessment heuristics:

  • Confirm injecting the WCAG text-spacing CSS does not clip text, overlap content, or hide controls.

  • Confirm container heights do not constrain text such that the spacing override truncates content.

Source: https://www.w3.org/TR/WCAG22/#text-spacing

sc-1-4-13

SC 1.4.13 Content on Hover or Focus (Level AA)

Additional content triggered by hover or focus is dismissible, hoverable (the pointer can move into it without dismissing), and persistent (remains visible until dismissed or no longer relevant).

Assessment heuristics:

  • Confirm tooltips, popovers, and submenus can be dismissed with the Escape key without moving focus.

  • Confirm hover-triggered overlays do not disappear when the pointer moves over the overlay itself.

  • Confirm the overlay persists until the triggering condition ends or the user dismisses it.

Source: https://www.w3.org/TR/WCAG22/#content-on-hover-or-focus

Guideline 2.1 — Keyboard Accessible

Guideline 2.1 (Keyboard Accessible) requires that all functionality be available through a keyboard interface, without time-based input dependencies, so users who cannot use a mouse can operate the experience.

Source: W3C Web Content Accessibility Guidelines (WCAG) 2.2, Guideline 2.1, https://www.w3.org/TR/WCAG22/#keyboard-accessible.

sc-2-1-1

SC 2.1.1 Keyboard (Level A)

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement (for example, freehand drawing).

Assessment heuristics:

  • Confirm every interactive control receives focus via Tab order and activates with Enter or Space (or the role-appropriate key).

  • Confirm drag-and-drop, hover-only menus, swipe gestures, and right-click context menus have a keyboard-operable equivalent.

  • Confirm custom controls (role="button", role="checkbox") implement the expected key handling.

Source: https://www.w3.org/TR/WCAG22/#keyboard

sc-2-1-2

SC 2.1.2 No Keyboard Trap (Level A)

When keyboard focus can be moved to a component, focus can also be moved away using only the keyboard, and the user is told how if a non-standard key is required.

Assessment heuristics:

  • Confirm modal dialogs trap focus while open but release it on close (Escape or close button).

  • Confirm embedded iframes, plugins, or third-party widgets allow Tab and Shift+Tab to exit them.

  • Confirm any non-standard exit key is documented in the surrounding UI.

Source: https://www.w3.org/TR/WCAG22/#no-keyboard-trap

sc-2-1-3

SC 2.1.3 Keyboard (No Exception) (Level AAA)

All functionality of the content is operable through a keyboard interface without exception for path-dependent input.

Assessment heuristics:

  • Confirm freehand signature, drawing, or gesture inputs each provide a fully keyboard-driven equivalent path.

Source: https://www.w3.org/TR/WCAG22/#keyboard-no-exception

sc-2-1-4

SC 2.1.4 Character Key Shortcuts (Level A)

If a keyboard shortcut is implemented using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of: the shortcut can be turned off, the shortcut can be remapped, or the shortcut is active only when the relevant component has focus.

Assessment heuristics:

  • Confirm single-key shortcuts are scoped to focused components, remappable, or have an off switch.

  • Confirm modifier-key combinations (Ctrl, Alt, Cmd) used as shortcuts are not affected by this criterion but are still documented.

Source: https://www.w3.org/TR/WCAG22/#character-key-shortcuts

Guideline 2.2 — Enough Time

Guideline 2.2 (Enough Time) requires that users have enough time to read and use content, including adjustable time limits and pause/stop/hide controls for moving content.

Source: W3C Web Content Accessibility Guidelines (WCAG) 2.2, Guideline 2.2, https://www.w3.org/TR/WCAG22/#enough-time.

sc-2-2-1

SC 2.2.1 Timing Adjustable (Level A)

For each time limit set by the content, at least one of: the user can turn off the limit, the user can adjust it to at least 10 times the default, the user is warned before the limit expires and can extend it with a simple action, the limit is essential (auction, real-time event), or the limit is longer than 20 hours.

Assessment heuristics:

  • Confirm session-timeout warnings appear before expiry with an option to extend by a simple action.

  • Confirm timed quizzes and forms offer an accessibility-aware extension or alternative.

Source: https://www.w3.org/TR/WCAG22/#timing-adjustable

sc-2-2-2

SC 2.2.2 Pause, Stop, Hide (Level A)

For moving, blinking, scrolling, or auto-updating information that starts automatically, lasts more than 5 seconds, and is presented in parallel with other content, the user has a mechanism to pause, stop, or hide it (or to control its update frequency).

Assessment heuristics:

  • Confirm auto-rotating carousels and tickers carry a pause control reachable by keyboard.

  • Confirm animated content longer than 5 seconds can be stopped without disabling the rest of the page.

Source: https://www.w3.org/TR/WCAG22/#pause-stop-hide

sc-2-2-3

SC 2.2.3 No Timing (Level AAA)

Timing is not an essential part of the event or activity presented, except for non-interactive synchronised media and real-time events.

Assessment heuristics:

  • Confirm any non-essential time limits are removed for AAA targets.

Source: https://www.w3.org/TR/WCAG22/#no-timing

sc-2-2-4

SC 2.2.4 Interruptions (Level AAA)

Interruptions (notifications, alerts, banners) can be postponed or suppressed by the user, except interruptions involving an emergency.

Assessment heuristics:

  • Confirm users can configure or pause non-emergency push notifications.

Source: https://www.w3.org/TR/WCAG22/#interruptions

sc-2-2-5

SC 2.2.5 Re-authenticating (Level AAA)

When an authenticated session expires, the user can continue the activity without loss of data after re-authentication.

Assessment heuristics:

  • Confirm forms preserve user-entered data through a re-authentication flow.

Source: https://www.w3.org/TR/WCAG22/#re-authenticating

sc-2-2-6

SC 2.2.6 Timeouts (Level AAA)

Users are warned about the duration of any user inactivity that could cause data loss, unless the data is preserved for more than 20 hours when the user does not take any actions.

Assessment heuristics:

  • Confirm a clearly visible warning describes the inactivity timeout duration.

  • Confirm draft-saving behaviour is documented to the user.

Source: https://www.w3.org/TR/WCAG22/#timeouts

Guideline 2.3 — Seizures and Physical Reactions

Guideline 2.3 (Seizures and Physical Reactions) requires that content not be designed in a way known to cause seizures or physical reactions, especially through flashing content.

Source: W3C Web Content Accessibility Guidelines (WCAG) 2.2, Guideline 2.3, https://www.w3.org/TR/WCAG22/#seizures-and-physical-reactions.

sc-2-3-1

SC 2.3.1 Three Flashes or Below Threshold (Level A)

Web pages do not contain anything that flashes more than three times in any one-second period, or the flash is below the general flash and red flash thresholds defined by WCAG.

Assessment heuristics:

  • Confirm video, animations, and decorative effects do not exceed three flashes per second.

  • Confirm flashing red content is checked against the WCAG red-flash threshold using a recognised tool such as PEAT.

Source: https://www.w3.org/TR/WCAG22/#three-flashes-or-below-threshold

sc-2-3-2

SC 2.3.2 Three Flashes (Level AAA)

Web pages do not contain anything that flashes more than three times in any one-second period (no general or red flash exception threshold).

Assessment heuristics:

  • Confirm AAA-targeted experiences contain no content that flashes more than three times per second under any luminance condition.

Source: https://www.w3.org/TR/WCAG22/#three-flashes

sc-2-3-3

SC 2.3.3 Animation from Interactions (Level AAA)

Motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed.

Assessment heuristics:

  • Confirm a prefers-reduced-motion media query disables decorative motion.

  • Confirm the user can disable scroll-linked or parallax animations through a setting where the OS preference is unavailable.

Source: https://www.w3.org/TR/WCAG22/#animation-from-interactions

Guideline 2.4 — Navigable

Guideline 2.4 (Navigable) requires that users have ways to navigate, find content, and determine where they are within the experience, through bypass mechanisms, titles, focus order, link purpose, headings, and visible focus indicators.

Source: W3C Web Content Accessibility Guidelines (WCAG) 2.2, Guideline 2.4, https://www.w3.org/TR/WCAG22/#navigable.

sc-2-4-1

SC 2.4.1 Bypass Blocks (Level A)

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

Assessment heuristics:

  • Confirm a skip-to-main-content link is the first focusable element on the page and becomes visible on focus.

  • Confirm landmarks (<main>, <nav>, <aside>) are used so assistive technology users can jump between regions.

Source: https://www.w3.org/TR/WCAG22/#bypass-blocks

sc-2-4-2

SC 2.4.2 Page Titled (Level A)

Pages have titles that describe their topic or purpose.

Assessment heuristics:

  • Confirm <title> reflects the page topic and updates on client-side navigation in single-page applications.

  • Confirm titles disambiguate similar pages (for example, "Cart - 3 items" rather than just "Cart").

Source: https://www.w3.org/TR/WCAG22/#page-titled

sc-2-4-3

SC 2.4.3 Focus Order (Level A)

If content can be navigated sequentially and the order affects meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

Assessment heuristics:

  • Confirm Tab order follows the visual reading order and does not jump unexpectedly across the page.

  • Confirm tabindex values greater than zero are avoided.

  • Confirm modals move focus into the dialog when opened and back to the trigger when closed.

Source: https://www.w3.org/TR/WCAG22/#focus-order

sc-2-4-4

SC 2.4.4 Link Purpose (In Context) (Level A)

The purpose of each link is determined from the link text alone or from the link text together with its programmatically determined link context.

Assessment heuristics:

  • Confirm link text is meaningful on its own or with adjacent text (avoid "click here", "read more" alone).

  • Confirm icon-only links carry an accessible name via aria-label or visually hidden text.

Source: https://www.w3.org/TR/WCAG22/#link-purpose-in-context

sc-2-4-5

SC 2.4.5 Multiple Ways (Level AA)

More than one way is available to locate a page within a set of pages, except where the page is the result of, or a step in, a process.

Assessment heuristics:

  • Confirm the site provides at least two of: site map, search, table of contents, navigation menu, or related-links list.

Source: https://www.w3.org/TR/WCAG22/#multiple-ways

sc-2-4-6

SC 2.4.6 Headings and Labels (Level AA)

Headings and labels describe the topic or purpose of the section or control they identify.

Assessment heuristics:

  • Confirm heading text concisely describes the section content.

  • Confirm form labels describe the input rather than restating the placeholder.

Source: https://www.w3.org/TR/WCAG22/#headings-and-labels

sc-2-4-7

SC 2.4.7 Focus Visible (Level AA)

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

Assessment heuristics:

  • Confirm the default browser focus ring is preserved or replaced with a custom indicator of equal or greater visibility.

  • Confirm focus indicators meet the SC 1.4.11 non-text contrast threshold against adjacent colours.

Source: https://www.w3.org/TR/WCAG22/#focus-visible

sc-2-4-8

SC 2.4.8 Location (Level AAA)

Information about the user's location within a set of pages is available.

Assessment heuristics:

  • Confirm breadcrumbs, current-page indicators in navigation, or site-map highlights are present.

Source: https://www.w3.org/TR/WCAG22/#location

sc-2-4-9

SC 2.4.9 Link Purpose (Link Only) (Level AAA)

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

Assessment heuristics:

  • Confirm link text is fully self-describing without surrounding context.

Source: https://www.w3.org/TR/WCAG22/#link-purpose-link-only

sc-2-4-10

SC 2.4.10 Section Headings (Level AAA)

Section headings are used to organise content where applicable.

Assessment heuristics:

  • Confirm long-form content uses headings at appropriate levels to segment topics.

Source: https://www.w3.org/TR/WCAG22/#section-headings

sc-2-4-11

SC 2.4.11 Focus Not Obscured (Minimum) (Level AA)

When a user-interface component receives keyboard focus, the component is not entirely hidden by author-created content.

Assessment heuristics:

  • Confirm sticky headers, footers, cookie banners, or chat widgets do not entirely cover the currently focused control.

  • Confirm scrolling brings the focused control into a visible position when overlays are present.

Source: https://www.w3.org/TR/WCAG22/#focus-not-obscured-minimum

sc-2-4-12

SC 2.4.12 Focus Not Obscured (Enhanced) (Level AAA)

When a user-interface component receives keyboard focus, no part of the component is hidden by author-created content.

Assessment heuristics:

  • Confirm overlays leave the entire focused control visible, not just a portion.

Source: https://www.w3.org/TR/WCAG22/#focus-not-obscured-enhanced

sc-2-4-13

SC 2.4.13 Focus Appearance (Level AAA)

The keyboard focus indicator meets defined minimum size, contrast, and area requirements (an outline at least 2 CSS pixels thick with 3:1 contrast against unfocused state, and no obscuring of the focused component).

Assessment heuristics:

  • Confirm focus indicators are at least 2 CSS pixels thick on the perimeter or equivalent area.

  • Confirm 3:1 contrast between focused and unfocused states.

Source: https://www.w3.org/TR/WCAG22/#focus-appearance

Guideline 2.5 — Input Modalities

Guideline 2.5 (Input Modalities) requires that users can operate functionality through various inputs beyond the keyboard, including pointer, touch, motion, and voice, with adequate target size and cancellation.

Source: W3C Web Content Accessibility Guidelines (WCAG) 2.2, Guideline 2.5, https://www.w3.org/TR/WCAG22/#input-modalities.

sc-2-5-1

SC 2.5.1 Pointer Gestures (Level A)

All functionality that uses multipoint or path-based gestures can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

Assessment heuristics:

  • Confirm swipe, pinch, and rotate gestures have a single-tap or single-click alternative.

  • Confirm path-based interactions (drag along a curve) have an equivalent tap-based path.

Source: https://www.w3.org/TR/WCAG22/#pointer-gestures

sc-2-5-2

SC 2.5.2 Pointer Cancellation (Level A)

For functionality operated using a single pointer, at least one of the following is true: no down-event activates the function, the function completes on up-event and a mechanism is available to abort or undo, the up-event reverses the down-event, or completing on down-event is essential.

Assessment heuristics:

  • Confirm clicks fire on pointerup or mouseup rather than on pointerdown for non-essential actions.

  • Confirm dragging off a button before release cancels the activation.

Source: https://www.w3.org/TR/WCAG22/#pointer-cancellation

sc-2-5-3

SC 2.5.3 Label in Name (Level A)

For user-interface components with labels that include text or images of text, the accessible name contains the text that is presented visually.

Assessment heuristics:

  • Confirm aria-label strings include the visible text exactly rather than rephrasing it.

  • Confirm speech-input users can activate a control by saying its visible label.

Source: https://www.w3.org/TR/WCAG22/#label-in-name

sc-2-5-4

SC 2.5.4 Motion Actuation (Level A)

Functionality that can be operated by device motion or user motion can also be operated by user-interface components, and response to motion can be disabled to prevent accidental actuation, except when motion is essential or the motion is used through an accessibility-supported interface.

Assessment heuristics:

  • Confirm shake-to-undo and tilt-based controls have an on-screen equivalent.

  • Confirm a setting disables motion-triggered actions for users with motor impairments.

Source: https://www.w3.org/TR/WCAG22/#motion-actuation

sc-2-5-5

SC 2.5.5 Target Size (Enhanced) (Level AAA)

The size of the target for pointer inputs is at least 44 by 44 CSS pixels, except where the target is inline, user-agent-controlled, essential, or has an equivalent target meeting the size requirement.

Assessment heuristics:

  • Confirm touch targets are at least 44x44 CSS pixels in the dominant interaction surface.

Source: https://www.w3.org/TR/WCAG22/#target-size-enhanced

sc-2-5-6

SC 2.5.6 Concurrent Input Mechanisms (Level AAA)

Web content does not restrict the use of input modalities available on a platform except where the restriction is essential, required to ensure security of the content, or required to respect user settings.

Assessment heuristics:

  • Confirm switching between touch, mouse, and keyboard within a session does not disable input modalities.

Source: https://www.w3.org/TR/WCAG22/#concurrent-input-mechanisms

sc-2-5-7

SC 2.5.7 Dragging Movements (Level AA)

All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or determined by the user agent.

Assessment heuristics:

  • Confirm drag-to-reorder lists offer up/down buttons or keyboard shortcuts as alternatives.

  • Confirm slider controls accept tap-and-arrow input as an alternative to drag.

Source: https://www.w3.org/TR/WCAG22/#dragging-movements

sc-2-5-8

SC 2.5.8 Target Size (Minimum) (Level AA)

The size of the target for pointer inputs is at least 24 by 24 CSS pixels, with defined exceptions for spacing, inline targets, user-agent controls, and essential presentations.

Assessment heuristics:

  • Confirm touch targets are at least 24x24 CSS pixels or that smaller targets carry sufficient surrounding space so the effective target reaches 24x24.

Source: https://www.w3.org/TR/WCAG22/#target-size-minimum

Guideline 3.1 — Readable

Guideline 3.1 (Readable) requires that text content be readable and understandable, including identifying the language of the page and unusual content, and providing reading-level support where needed.

Source: W3C Web Content Accessibility Guidelines (WCAG) 2.2, Guideline 3.1, https://www.w3.org/TR/WCAG22/#readable.

sc-3-1-1

SC 3.1.1 Language of Page (Level A)

The default human language of each web page can be programmatically determined.

Assessment heuristics:

  • Confirm the root <html> element carries a lang attribute with a valid BCP 47 language tag.

  • Confirm single-page applications set the language attribute to reflect the current content language when locale changes.

Source: https://www.w3.org/TR/WCAG22/#language-of-page

sc-3-1-2

SC 3.1.2 Language of Parts (Level AA)

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

Assessment heuristics:

  • Confirm passages in a different language carry a lang attribute on the enclosing element.

  • Confirm inline language switches (quotations, terms) use a <span lang="...">.

Source: https://www.w3.org/TR/WCAG22/#language-of-parts

sc-3-1-3

SC 3.1.3 Unusual Words (Level AAA)

A mechanism is available for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms and jargon.

Assessment heuristics:

  • Confirm jargon and idioms link to a glossary entry or expose a tooltip-style definition.

Source: https://www.w3.org/TR/WCAG22/#unusual-words

sc-3-1-4

SC 3.1.4 Abbreviations (Level AAA)

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

Assessment heuristics:

  • Confirm abbreviations are expanded on first use or exposed via <abbr title> or a glossary.

Source: https://www.w3.org/TR/WCAG22/#abbreviations

sc-3-1-5

SC 3.1.5 Reading Level (Level AAA)

When text requires a reading ability more advanced than the lower secondary education level, supplemental content or a simpler version is available.

Assessment heuristics:

  • Confirm long-form content has a plain-language summary or a simpler variant.

Source: https://www.w3.org/TR/WCAG22/#reading-level

sc-3-1-6

SC 3.1.6 Pronunciation (Level AAA)

A mechanism is available for identifying specific pronunciation of words where pronunciation is essential to understanding meaning.

Assessment heuristics:

  • Confirm homographs or pronunciation-sensitive terms include pronunciation hints (audio, IPA, or ruby annotation).

Source: https://www.w3.org/TR/WCAG22/#pronunciation

Guideline 3.2 — Predictable

Guideline 3.2 (Predictable) requires that web pages appear and operate in predictable ways, with consistent navigation and identification across the experience and no unexpected context changes.

Source: W3C Web Content Accessibility Guidelines (WCAG) 2.2, Guideline 3.2, https://www.w3.org/TR/WCAG22/#predictable.

sc-3-2-1

SC 3.2.1 On Focus (Level A)

When any user-interface component receives focus, it does not initiate a change of context.

Assessment heuristics:

  • Confirm receiving focus does not auto-submit forms, open new windows, or navigate to a new URL.

  • Confirm focus on a dropdown does not open a menu unless the user explicitly opts in (then via Enter or arrow key, not focus alone).

Source: https://www.w3.org/TR/WCAG22/#on-focus

sc-3-2-2

SC 3.2.2 On Input (Level A)

Changing the setting of any user-interface component does not automatically cause a change of context unless the user has been advised of the behaviour before using the component.

Assessment heuristics:

  • Confirm selecting an option in a dropdown does not auto-submit a form without prior warning.

  • Confirm typing into a text field does not navigate away from the page.

Source: https://www.w3.org/TR/WCAG22/#on-input

sc-3-2-3

SC 3.2.3 Consistent Navigation (Level AA)

Navigational mechanisms that are repeated on multiple pages occur in the same relative order each time, unless a change is initiated by the user.

Assessment heuristics:

  • Confirm the main navigation appears in the same place and same order on every page of the site.

Source: https://www.w3.org/TR/WCAG22/#consistent-navigation

sc-3-2-4

SC 3.2.4 Consistent Identification (Level AA)

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

Assessment heuristics:

  • Confirm "Search", "Submit", and other recurring controls use the same label and icon across the site.

Source: https://www.w3.org/TR/WCAG22/#consistent-identification

sc-3-2-5

SC 3.2.5 Change on Request (Level AAA)

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

Assessment heuristics:

  • Confirm automatic redirects, refresh, or modal pop-ups are user-initiated or can be disabled.

Source: https://www.w3.org/TR/WCAG22/#change-on-request

sc-3-2-6

SC 3.2.6 Consistent Help (Level A)

If a page includes a help mechanism (contact info, contact link, self-help, FAQ, or human contact mechanism), the help mechanism appears in the same relative order across the set of pages.

Assessment heuristics:

  • Confirm help links or contact widgets appear in a consistent location across all pages where they exist.

Source: https://www.w3.org/TR/WCAG22/#consistent-help

Guideline 3.3 — Input Assistance

Guideline 3.3 (Input Assistance) requires that users be helped to avoid and correct mistakes, including error identification, labels, instructions, error suggestions, error prevention, accessible authentication, and redundant entry support.

Source: W3C Web Content Accessibility Guidelines (WCAG) 2.2, Guideline 3.3, https://www.w3.org/TR/WCAG22/#input-assistance.

sc-3-3-1

SC 3.3.1 Error Identification (Level A)

When an input error is automatically detected, the item in error is identified and the error is described to the user in text.

Assessment heuristics:

  • Confirm error messages identify the field by name and explain what is wrong in text rather than relying on colour or icon.

  • Confirm validation errors are exposed to assistive technology (for example, through aria-invalid and an aria-describedby link to the message).

Source: https://www.w3.org/TR/WCAG22/#error-identification

sc-3-3-2

SC 3.3.2 Labels or Instructions (Level A)

Labels or instructions are provided when content requires user input.

Assessment heuristics:

  • Confirm every form control has a visible label, instructions, or an aria-label.

  • Confirm complex inputs (date format, password rules) carry instructions before submission, not only on error.

Source: https://www.w3.org/TR/WCAG22/#labels-or-instructions

sc-3-3-3

SC 3.3.3 Error Suggestion (Level AA)

If an input error is automatically detected and suggestions for correction are known, the suggestions are provided to the user, unless doing so would jeopardise the security or purpose of the content.

Assessment heuristics:

  • Confirm format-specific errors (date, email, phone) include an example or suggestion.

  • Confirm sensitive inputs (passwords) provide rule-based feedback rather than the specific failing characters.

Source: https://www.w3.org/TR/WCAG22/#error-suggestion

sc-3-3-4

SC 3.3.4 Error Prevention (Legal, Financial, Data) (Level AA)

For pages that cause legal commitments or financial transactions, that modify or delete user-controllable data, or that submit user test responses, at least one of the following is true: submissions are reversible, data is checked for input errors with an opportunity to correct, or a mechanism for review and confirmation is provided.

Assessment heuristics:

  • Confirm checkout, contract acceptance, and data deletion flows offer review-and-confirm steps.

  • Confirm financial transactions surface a confirmation summary before final submission.

Source: https://www.w3.org/TR/WCAG22/#error-prevention-legal-financial-data

sc-3-3-5

SC 3.3.5 Help (Level AAA)

Context-sensitive help is available.

Assessment heuristics:

  • Confirm complex forms surface inline help text or links to a topic-specific help article.

Source: https://www.w3.org/TR/WCAG22/#help

sc-3-3-6

SC 3.3.6 Error Prevention (All) (Level AAA)

For all pages that require the user to submit information, submissions are reversible, data is checked for input errors with an opportunity to correct, or a mechanism for review and confirmation is provided.

Assessment heuristics:

  • Confirm review-and-confirm steps apply to all submission flows in AAA-targeted experiences.

Source: https://www.w3.org/TR/WCAG22/#error-prevention-all

sc-3-3-7

SC 3.3.7 Redundant Entry (Level A)

Information previously entered by or provided to the user that is required to be entered again in the same process is either auto-populated or available for the user to select, except when re-entering the information is essential, the information is required to ensure security, or previously entered information is no longer valid.

Assessment heuristics:

  • Confirm multi-step forms pre-populate values the user already provided.

  • Confirm address fields offer a "same as billing" or saved-address selection.

Source: https://www.w3.org/TR/WCAG22/#redundant-entry

sc-3-3-8

SC 3.3.8 Accessible Authentication (Minimum) (Level AA)

A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless an alternative is provided, the test is one that recognises objects or non-text content the user provided, or the test is supported by a mechanism that assists the user.

Assessment heuristics:

  • Confirm passwordless flows (magic link, passkey), password-manager support (autocomplete="current-password"), or biometric login is offered.

  • Confirm CAPTCHAs offer a non-cognitive alternative such as device-based attestation or accessible audio.

Source: https://www.w3.org/TR/WCAG22/#accessible-authentication-minimum

sc-3-3-9

SC 3.3.9 Accessible Authentication (Enhanced) (Level AAA)

A cognitive function test is not required for any step in an authentication process unless the test is to recognise objects or non-text content the user provided.

Assessment heuristics:

  • Confirm AAA flows do not include puzzle-based or transcription-based authentication challenges.

Source: https://www.w3.org/TR/WCAG22/#accessible-authentication-enhanced

Guideline 4.1 — Compatible

Guideline 4.1 (Compatible) requires that content be robust enough to work with current and future user agents and assistive technologies. Note that SC 4.1.1 Parsing has been removed in WCAG 2.2 (marked obsolete) and is included here only for traceability.

Source: W3C Web Content Accessibility Guidelines (WCAG) 2.2, Guideline 4.1, https://www.w3.org/TR/WCAG22/#compatible.

sc-4-1-1

SC 4.1.1 Parsing (Obsolete in WCAG 2.2)

This success criterion has been removed in WCAG 2.2 because modern user agents recover from the kinds of parsing issues it covered. Existing audits referencing this criterion should be retargeted to the responsible robustness criteria (notably SC 4.1.2).

Assessment heuristics:

  • Do not raise new findings against SC 4.1.1; treat outstanding 2.1 findings as resolved when the underlying behaviour now passes 4.1.2.

Source: https://www.w3.org/TR/WCAG22/#parsing

sc-4-1-2

SC 4.1.2 Name, Role, Value (Level A)

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

Assessment heuristics:

  • Confirm every interactive element exposes a non-empty accessible name (via label, aria-label, or aria-labelledby).

  • Confirm custom controls implement the appropriate ARIA role and corresponding required ARIA properties.

  • Confirm state changes (expanded, checked, selected, pressed) are reflected in ARIA attributes synchronously with the visual state.

Source: https://www.w3.org/TR/WCAG22/#name-role-value

sc-4-1-3

SC 4.1.3 Status Messages (Level AA)

Status messages can be programmatically determined through role or properties so they can be presented to the user by assistive technology without receiving focus.

Assessment heuristics:

  • Confirm form-validation summaries, toast notifications, and async loading messages use ARIA live regions (role="status", role="alert", or aria-live).

  • Confirm status updates do not steal focus and that polite vs. assertive live-region policies match the urgency of the message.

Source: https://www.w3.org/TR/WCAG22/#status-messages

Requirements and compatibility

Written for: GitHub Copilot, Claude Code

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Claude Code frontmatter, Needs Python, Needs Node.js

The author says: Requires Python 3.11+ and uv; the scanner additionally needs Node.js and network access to fetch the pinned axe-core CLI from the public npm registry.

Security

What our scanner noticed· Low risk

  • Instructions that use the network
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Microsoft
Publisher
Microsoft (Official)
Source
microsoft/hve-core · .github/skills/accessibility/accessibility · commit f425e94
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Microsoft or Microsoft.

Get it from the source

1 of this skill’s files are not mirrored here, so there is no ZIP. Get the complete skill from its source: microsoft/hve-core