Accessible components

When to use it

Use this skill for one component or one user journey: forms, error messages, dialogs, menus, tabs, focus, live announcements, and block, admin or WooCommerce UI. It answers one question: does this control work for people who use a keyboard, a screen reader, zoom or voice, and how do you fix it if not?

The skill works on a component and ends with a fix and a retest. It does not decide whether a whole site meets WCAG.

Accessible components or WCAG review

wp-devkit-wcag-review gives the conformance status of a scope against WCAG 2.1 and 2.2 levels A and AA. It samples pages and marks each criterion as Pass, Fail, Needs evidence or Not applicable. It also writes the conformance wording.

This skill may point to a WCAG criterion in a finding, but it never issues a Pass or a conformance claim. If you need a status table, input for an ACR or VPAT report, or a go-live gate, switch to the WCAG skill and give it the evidence gathered here. See WCAG review.

Run a review with Claude

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

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

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

Run a review with Codex, ChatGPT or Antigravity

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

$wp-devkit-accessibility-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.

The engineering contract is the set of rules every DevKit skill follows, such as staying read-only during a review and sorting findings by how well they are proven.

Reference files the skill loads

The skill reads only the files that match your task.

• accessibility-review-workbook.md holds the decision rules, common false alarms and the format for findings. The skill reads it first.
• forms-and-errors.md covers labels, validation, sign-in forms, checkout forms and status messages.
• interactive-patterns.md covers dialogs, menus, tabs, accordions and focus handling.
• testing-and-evidence.md is used before the skill proposes retests. It covers the manual keyboard, zoom and screen reader script, and what automated tools cannot see.
• wordpress-a11y-surfaces.md covers WordPress specifics for themes, blocks, the admin area and WooCommerce.

How a review runs

1. The skill reproduces the journey in the rendered page before it trusts a search of the markup. It captures each state, not only the first one, and finds out who owns the markup: core, theme, block, plugin or a third-party script.
2. It applies the native-first rule: a real button, link, input, select, details or dialog beats a role on a div. For each custom control it records the accessible name, role, state and the keyboard behavior of the matching pattern.
3. It traces keyboard order, activation with Enter and Space, Escape, where focus lands when something opens and where it returns when it closes. Hidden items must not take focus, and visible items must be reachable.
4. It checks forms and dynamic changes: label, instructions, error association, error summary, status messages that do not steal focus, and preserved input.
5. It checks zoom and reflow at 320 CSS px, text spacing, sticky elements that cover content, reduced motion and forced colors in the browser.
6. It sorts each result into a confirmed finding (reproduced or proven from the code path), a candidate (needs assistive technology or runtime evidence) or insufficient evidence. It says which assistive technology evidence is missing.

What you get back

The report starts with the verdict, the scope reviewed (journeys, states, browsers and assistive technology) and what was not tested.

Each confirmed finding lists:

• the file and line, the component and its state
• who is affected: keyboard, screen reader, low vision, voice or motor users
• the trigger and steps, with observed and expected behavior
• the impact and the confidence
• the smallest fix in the component that owns the problem
• a regression check, and optionally a WCAG criterion as a pointer

Severity follows the impact you can show. A blocked task in a core journey is CRITICAL, a degraded but workable task is WARNING, and polish is INFO. Candidates and "insufficient evidence" items appear in separate lists.

An implementation report adds the changed boundaries, the commands with exit codes and the manual checks still owed.

Where to go next

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