Design & quality · Human verification required

Accessibility
Auditor.

A blueprint for reviewing a real user journey against WCAG 2.2—not mistaking an automated score for proof that the interface works with a keyboard or screen reader.

When to use this agent

Use it before a release, after adding a complex component, or when customer feedback suggests a barrier. Give it one bounded journey—such as sign-up or checkout—rather than asking it to certify an entire product from screenshots.

Boundary: an agent can inspect supplied markup, screenshots, test output, and notes. A person still needs to operate the interface with a keyboard and representative assistive technology.

What to provide

  • URLs or components in scope and the primary user task.
  • HTML/CSS snippets, design states, and existing axe or Lighthouse output.
  • Supported browser, device, screen reader, zoom, and contrast combinations.
  • Known constraints, owners, and release date.

Recommended workflow

  1. Define the journey and map every state, including errors and loading.
  2. Separate machine-detectable checks from manual checks.
  3. Review semantics, names, roles, values, focus order, announcements, contrast, zoom, motion, and error recovery.
  4. Map each confirmed issue to a WCAG 2.2 success criterion.
  5. Prioritize by user impact and provide a reproducible fix and retest step.

Output contract

FieldRequired detail
FindingObserved barrier and affected journey
EvidenceElement, state, reproduction steps, and test method
StandardWCAG criterion and conformance level
PriorityCritical, serious, moderate, or minor—based on impact
FixSpecific design or code change plus retest

Worked example

For a checkout modal, the agent notices that focus stays behind the dialog after opening. It records keyboard steps, identifies the missing dialog focus strategy, recommends initial focus and focus restoration, and adds VoiceOver and NVDA retest steps. It does not call the whole checkout “compliant.”

Starter prompt

Act as an accessibility audit partner. Review the supplied journey against WCAG 2.2 AA. Separate automated evidence from checks that require a person. For every confirmed issue, return impact, reproduction steps, criterion, remediation, owner type, and retest method. Do not claim compliance from a scan alone.

Journey: [task]
Artifacts: [URLs, markup, screenshots, reports]
Test matrix: [browser, keyboard, screen reader, zoom]
Constraints: [release and platform limits]

Portable agent package

Download the Accessibility Auditor plugin

The ZIP contains a standalone Codex plugin with this blueprint as a validated SKILL.md. It has no MCP dependency, executable hook, bundled credential, or private data source.

  1. Download and extract the ZIP.
  2. Review .codex-plugin/plugin.json and skills/accessibility-auditor/SKILL.md.
  3. Add the extracted plugin with the plugin installer supported by your agent host.

Version 1.0.0 · MIT · Review instructions before installing any agent package.

FAQ

Can this replace a professional audit?

No. It can organize evidence and remediation, but representative manual testing and accountable review remain essential.

Should every issue get ARIA?

No. Prefer native semantic HTML; ARIA is useful when native elements cannot express the required interaction.

Related blueprints and tools