Quality & Testing · master area
Accessibility Testing
Keyboard, screen reader, contrast, focus order. Automated where possible; manual where the automation can't see. Failures block merge unless explicitly accepted with a remediation date.
Owners: QA, Designer Phase it lives in: How We Build (Volume IV) The corpus principle this enacts: UX/product ilities are first-class requirements.
Where it lives in the chain
- How We Build · Testing · QA craft — the canon
How to do this
Automated layer — runs in CI on every PR:
- axe-core / Pa11y / Lighthouse scans the rendered pages. Catches missing labels, contrast violations, ARIA misuse, heading hierarchy gaps.
- Threshold: zero criticals, zero serious. Warnings logged but not blocking.
Manual layer — runs at QA review, before release gate:
- Keyboard-only walkthrough — tab through the feature, no mouse. Can the named person complete the task?
- Screen reader walkthrough — VoiceOver / NVDA / TalkBack. Are the names meaningful? Does the focus order tell a story?
- Zoom to 200% — does the layout still work?
- Reduce motion — do animations respect the user's preference?
What good practice looks like
The automated layer catches the measurable. The manual layer catches the experiential. Both are needed.
A team that runs only the automated layer ships features that pass the audit and confuse the user. A label can be present but unhelpful ("Submit" with no context); a contrast ratio can be 4.6:1 (pass) but exhausting to read; a focus order can be technically valid and structurally chaotic.
The remediation conversation is explicit. If a release ships with a known accessibility gap, it is named, owned, dated. Not silently deferred to "later." The chain-aware label that applies is observation-mismatch — the brief described a user the design didn't accommodate.
Related crafts
- Accessibility Design — the design half
- UX/Product Ilities — where accessibility is named as a target