WCAG conformance review

When to use it

Produce a WCAG 2.1 or 2.2 A/AA conformance assessment for WordPress journeys: scope, sampling, per-criterion Pass/Fail/Needs evidence/N-A, evidence and retest. Use for audits, ACR/VPAT input and go-live acceptance; fixing widget behavior goes to wp-devkit-accessibility-review.

Boundaries and hand-offs

• This skill decides status against normative criteria for a defined scope and keeps the evidence trail. It never fixes components; each Fail is handed to wp-devkit-accessibility-review (how to build and repair the control) with the criterion attached.
• It is also not a legal opinion. Name the standard and version the client commits to; legal applicability (ADA, EAA, Section 508) is context to confirm with counsel (references/standards-and-legal-context.md).
• If the user only wants "is this dialog accessible / why can't I tab here", use the accessibility skill. Use this one when the answer must be a criterion-by-criterion status, a sampled audit, a conformance statement or an acceptance gate.

Ask Claude

With the plugin loaded, start a read-only review of a bounded target:

/wp-devkit:wcag-review <target-path>

The short form /wp-devkit:wcag requests a quick scan.

Ask Codex, ChatGPT or Antigravity

Name the installed skill and keep the request bounded. Replace the target with your files or journey.

$wp-devkit-wcag-review
Review the target without editing files.
Read the project instructions and the skill's engineering contract first.
Separate confirmed findings from candidates and state the evidence and checks you could not run.

What it covers

The agent loads only the reference that matches the task:

• audit-method.md: WCAG evidence collection method
• deliverable-templates.md: Deliverable templates
• standards-and-legal-context.md: Standards and legal context
• wcag-criteria.md: WCAG 2.1 and 2.2 A/AA test index
• wcag-review-workbook.md: WCAG review workbook

How a review runs

1. Define the claim: version, level, scope, accessibility-supported baseline (browsers and AT). Record exclusions and third-party boundaries.
2. Build the sample with references/audit-method.md: structured set (templates, components, states), complete processes and a small random set.
3. Select criteria from references/wcag-criteria.md for the chosen version (2.1: 50 A/AA criteria incl. 4.1.1; 2.2: 55, 4.1.1 removed). Open the normative text and its exceptions before judging.
4. Gather evidence per criterion: source, rendered DOM, automated, keyboard, zoom/reflow/spacing, contrast measurements, assistive technology. Mix as each criterion demands.
5. Assign a status with reason: Pass (evidence cited), Fail (reproduced, with steps), Needs evidence (not tested or inconclusive), Not applicable (reason tied to scope). Never infer Pass from silence or a clean scan.
6. For each Fail record user impact, severity per the contract, owner, proposed remediation direction and a same-build retest. Use references/deliverable-templates.md for the deliverable. Read references/wcag-review-workbook.md first for the decision rules, false positives and acceptance cases.

What you get back

Lead with scope and claim (version, level, sample, matrix, build, date) and the overall result in one sentence that never says "compliant" unless every in-scope criterion has a Pass with evidence. Then the criterion table (criterion, version/level, status, evidence reference), then Fail entries: criterion, journey and state, file:line or URL, steps to reproduce, affected users, impact and severity, confidence, remediation direction, retest. Keep Needs evidence separate from Fail and list untested technologies, processes and AT. State coverage limits: a sampled pass is a pass for the sample only.

Where to go next

Use review to fix for a bounded implementation and Doctor and reports for environment and evidence tooling.