# Wcag 22 Accessibility Audit > Audit frontend markup, components, and design-system primitives against WCAG 2.2 Level A/AA success criteria and ARIA APG interaction patterns, separating automated-detectable violations from manual-verification-required items and flagging legal exposure, with reference material loaded progressively per success-criteria category. - Skill: `vincentchuwaichow/wcag-22-accessibility-audit` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add vincentchuwaichow/wcag-22-accessibility-audit` - Raw SKILL.md: https://api.skillmd.com/api/skills/vincentchuwaichow/wcag-22-accessibility-audit/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: VincentChuWaiChow (https://skillmd.com/u/vincentchuwaichow) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/vincentchuwaichow/wcag-22-accessibility-audit --- # WCAG 2.2 Accessibility Audit ## Purpose Frontend teams routinely ship components that pass visual QA but fail assistive-technology usage — missing accessible names, keyboard traps, insufficient contrast, non-conformant custom widgets. This skill audits against WCAG 2.2's exact success criteria (all four principles: Perceivable, Operable, Understandable, Robust) and the ACT Rules' machine-testable/manual-only split, without dumping the full 87-criterion spec into every review; it loads only the success-criteria category and evidence tier relevant to the review in scope. It complements — and does not duplicate — `html-semantics-accessibility-review`, which owns deep native-element/ARIA-APG keyboard-pattern matching; this skill owns the full-spectrum SC conformance sweep, automated-vs-manual evidence separation, and legal-exposure triage. ## When to use Use this skill when the user asks to: - run a WCAG 2.2 conformance audit across a page, flow, or component library (not just a single widget's ARIA pattern), - triage an accessibility bug report, audit finding, or demand letter against specific success criteria, - prepare input for a VPAT / accessibility conformance statement, - determine whether a finding is machine-testable (cite an ACT rule) or requires manual/assistive-technology verification before it can be closed as passing, - assess legal/litigation exposure of a known or suspected accessibility gap. ## Context7 Documentation Protocol WCAG 2.2 SC wording, technique/failure lists, and ACT rule coverage are living documents (WCAG 2.2 added SC in 2023; techniques and ACT rules are updated independently of the SC text) — never assert SC numbering, level, or technique applicability from memory. 1. Call `ToolSearch` with query `"context7"` (or `"select:mcp__Context7__resolve-library-id,mcp__Context7__query-docs"`) to load the Context7 tools if not already loaded in this session. 2. Call `mcp__Context7__resolve-library-id` for `web.dev` (prefer `/googlechrome/web.dev` or `/websites/web_dev_learn`) when grounding testing-methodology claims (automated vs manual coverage limits, tool selection factors) — these are documented, not folklore. 3. Call `mcp__Context7__query-docs` for the specific claim in question — e.g. "automated accessibility testing coverage limitations", "color contrast calculation formula", "focus not obscured success criterion" — before stating it as fact. Do this per audit, not once from a prior session's memory. 4. For primary normative text (exact SC wording, Level, technique/failure IDs, ACT rule text), prefer the W3C URLs in `official_docs` over Context7 paraphrase — Context7 is for grounding testing-methodology and coverage claims, not for replacing the normative spec text itself. 5. If Context7 is unavailable or returns no relevant match, fall back to the `official_docs` URLs and `references/` files, and mark the claim `documentation-based (Context7 unavailable)` instead of presenting it as freshly verified. 6. Never invent a WCAG 2.2 success-criterion number, Level, technique ID, or ACT rule ID that no queried source confirms. ## Lean operating rules - First classify the review scope: full-conformance audit (all applicable SC) vs targeted-criteria review (e.g. "just check contrast and focus") vs single-finding triage. Do not run a full sweep when the user asked about one criterion. - Separate every finding into exactly one of two evidence tiers — automated-detectable (contrast ratio, missing alt text, form-label association, duplicate IDs, missing document language, empty links/buttons) or manual-required (meaningful sequence, focus order intent, sensory characteristics, actual assistive-technology walkthrough, cognitive-load judgment calls) — and never present a manual-required item as closed by automated tooling alone. - Automated tooling (axe-core-class scanners, Lighthouse) is documented as catching a minority of real-world WCAG issues and can produce false positives — treat a clean automated scan as a floor, not a conformance claim, and say so explicitly in the report. - For any custom interactive widget, defer keyboard-pattern/ARIA-role correctness to `html-semantics-accessibility-review`'s APG matching rather than re-deriving it here; this skill's job is mapping the widget's *failure* to the correct SC and Level, and the litigation-exposure severity, not re-doing the pattern audit. - Never recommend an accessibility overlay or "auto-remediation" widget script as a fix; recommend the underlying semantic-markup, contrast, or structural change and cite the SC it resolves. - Cite the exact WCAG 2.2 success-criterion id and Level for every finding (e.g. "2.4.11 Focus Not Obscured (Minimum) — AA"), never a vague "accessibility issue" or bare SC number without Level. - Flag SC with documented high litigation exposure (1.4.3 Contrast Minimum, 2.1.1/2.1.2 Keyboard, 2.4.7 Focus Visible, 2.4.11 Focus Not Obscured, 4.1.2 Name Role Value, 1.1.1 Non-text Content) with elevated severity and an explicit legal-exposure note. - Load reference files only for the SC category and evidence question actually in scope; do not preload the full SC index for a single-criterion triage. ## References Load these only when needed: - [WCAG 2.2 success-criteria index](references/wcag22-sc-index.md) — use for the full A/AA success-criteria list grouped by POUR principle, with automated-vs-manual detectability and new-in-2.2 flags, when scoping which criteria apply to a review. - [ACT Rules detection boundary](references/act-rules-detection-boundary.md) — use when a finding needs an explicit machine-testable-vs-manual-only determination, citing the relevant ACT rule id, before closing or escalating it. - [Legal exposure and severity model](references/legal-exposure-severity.md) — use when triaging a finding's litigation risk, prioritizing a remediation backlog, or preparing input for a VPAT/conformance statement. ## Response minimum Return, at minimum: - the component/page/criteria category in scope, - each finding mapped to an exact WCAG 2.2 SC id, Level (A/AA), and automated-vs-manual evidence label, - evidence level for the finding itself (automated scan output, manual code review, live AT verification, or documentation-based inference), - safest remediation with a technique/SC reference, not an overlay or workaround, - explicit statement of what was NOT verified (manual checks not performed, AT combinations not tested) so no false conformance claim is implied, - legal-exposure flag (elevated/standard) for any finding touching a high-litigation-risk SC.