Accessible components

When to use it

Build, debug or review accessible WordPress controls: forms, errors, dialogs, menus, tabs, focus, live announcements, block, admin and WooCommerce UI. Use for keyboard and screen-reader behavior of a component; criterion-by-criterion status and audit scope belong to wp-devkit-wcag-review.

Boundaries and hand-offs

• This skill answers "does this control work for keyboard, screen-reader, zoom and voice users, and how do we fix it?". It works per component or journey and ends in a fix plus a retest.
• wp-devkit-wcag-review answers "what is the conformance status of this scope against WCAG 2.1/2.2 A/AA?". It owns sampling, per-criterion Pass / Fail / Needs evidence / Not applicable, and conformance wording.
• Findings here may cite a criterion as a pointer. Do not issue a Pass or a conformance claim from this skill. If the user wants a status table, an ACR/VPAT input or a go-live gate, switch to the WCAG skill and pass it the evidence gathered here.

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

Ask Codex, ChatGPT or Antigravity

Name the installed skill and keep the request bounded. 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.

What it covers

The agent loads only the reference that matches the task:

• accessibility-review-workbook.md: Accessibility review workbook
• forms-and-errors.md: Forms, validation, authentication and status messages
• interactive-patterns.md: Interactive patterns and focus management
• testing-and-evidence.md: Testing and evidence for accessibility work
• wordpress-a11y-surfaces.md: WordPress accessibility surfaces

How a review runs

1. Reproduce the journey in rendered output before trusting markup searches. Capture each state, not only the initial one. Identify who owns the markup (core, theme, block, plugin, third-party script).
2. Check the native-first rule: a real button, link, input, select, details or dialog beats a role on a div. For each custom control record accessible name, role, state/value and the keyboard contract of the chosen APG pattern.
3. Trace keyboard order, activation (Enter, Space), Escape, focus placement on open and focus return on close. Confirm nothing hidden stays focusable and nothing visible is unreachable.
4. Check forms and dynamic changes: label, instructions, error association, error summary, status announcements without focus theft, preserved input.
5. Check zoom/reflow (320 CSS px), text spacing, sticky-element obstruction, reduced motion and forced-colors in the browser.
6. Classify with the contract: confirmed finding (reproduced or proven from code path), candidate (needs AT or runtime evidence), or insufficient evidence. State which assistive-technology evidence is missing. Read references/accessibility-review-workbook.md first for decision rules, false positives and the finding format.

What you get back

Start with the verdict, the reviewed scope (journeys, states, browsers/AT) and what was not tested. For each confirmed finding give: file:line, component and state, actor (keyboard, screen-reader, low-vision, voice, motor), trigger and steps, observed versus expected behavior, impact, confidence, minimal fix in the owning component, regression check, and an optional criterion pointer. Severity follows demonstrated impact (blocked task = CRITICAL for a core journey; degraded but workable = WARNING; polish = INFO). Keep candidates and "insufficient evidence" in separate lists. For implementation, add changed boundaries, commands with exit codes, and manual checks still owed.

Where to go next

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