What it does
Wires or runs automated accessibility scans against the WCAG level in config across key page states, applies the configured blocking-severity gate, files each blocking violation as a defect, and flags the manual checks a tool cannot cover. Maps to ISO/IEC 25010 Usability (accessibility sub-characteristic).
When to use it
For an accessibility audit, or to add a11y tests to a page or flow.
Prerequisites
qa.config.yml with tooling.accessibility set (e.g. axe), gates.accessibility_standard, gates.a11y_block_on, stack.base_url_web; a reachable environment to run.
Output
ISO/IEC/IEEE 29119-3 Test Execution Log -> docs_dir/A11Y-RESULTS-<target>.md, with raw scan output under reports_dir and an Incident (Defect) Report per blocking violation.
Mechanics
How it works
- Read config; gate that tooling.accessibility is enabled
- Resolve target page(s) (default to risk_areas.critical when empty)
- Wire the axe scan via a reusable helper at the configured WCAG level
- Scan each key page state (logged out/in, forms, modals, error states)
- Apply the gate: fail on gates.a11y_block_on severities; burndown the rest
- Run or scaffold, capturing results; log each blocking violation as a defect
- State the manual residual axe cannot prove (keyboard, focus, screen-reader, contrast, zoom)
Why it works
The theory behind it
Non-functional accessibility testing mapped to ISO/IEC 25010 Usability (accessibility sub-characteristic); evaluation lineage is CT-UT. WCAG provides the external, measurable criterion.
CT-UT / accessibility (Specialist) · WCAG · ISO/IEC 25010 Usability · CTFL v4.0 §2.2.2
Example
See it in use
> /qa:a11y-audit "/checkout"✓ Correct when It audits against WCAG 2.1 AA and blocks on critical/serious per gates.a11y_block_on.
Related commands
Used by