The team almost always knows what to do. What’s usually missing is a moment in the schedule where doing it is explicitly someone’s job. This page names that moment at every stage, and who owns it. It applies to product management, design, engineering, and QA, on a cadence of every release.
The lifecycle
- Discovery — Accessibility requirements are captured alongside functional requirements, not after them. If the feature touches a regulated customer segment (public sector, EU, U.S. federal), the applicable standard from Global standards reference is named in the brief.
- Design — Designers apply the checks in Accessibility in design before handoff: contrast, focus order, keyboard equivalents for gestures, and content review. Design review includes an explicit accessibility pass, not an assumption that engineering will catch it.
- Build — Engineers build against the component-level Definition of Done in Accessibility in engineering. Automated scanning runs on every pull request.
- Verify — Manual keyboard and screen reader passes happen before a feature is marked ready for release. Major features are scheduled for testing with assistive technology users during the sprint they’re built in, not retrofitted afterward — see Recruiting and testing with assistive technology users below for how that’s resourced.
- Release — Release notes disclose any known accessibility limitation shipping with the feature, with a target remediation release. Nothing ships with an undisclosed regression.
- Monitor — Conformance status for the affected product is kept current within one review cycle of release.
Recruiting and testing with assistive technology users
An automated scan and an internal keyboard pass tell us a feature meets a written standard. They can’t tell us whether it actually works for someone who relies on a screen reader, a switch, or voice control every day. That confidence only comes from testing with the people themselves, so it’s a standing part of our process, not a one-off activity we run when a project happens to have budget for it.
- A standing participant panel. We recruit and maintain a pool of test participants who use assistive technology as their primary means of access, covering a spread of tools (screen readers, switch access, voice control, screen magnification) and needs, so a squad isn’t starting recruitment from zero every time a feature needs testing.
- Sessions built around the real flow. Research is scoped to the specific flow or component in question, using the same tasks a sighted, mouse-using participant would be asked to attempt, so the results are directly comparable rather than a separate, lesser track of feedback.
- Built into the lifecycle, not bolted on. As set out under The lifecycle above, major features are scheduled for this testing during the sprint they’re built in, alongside the usual keyboard and screen reader passes described on the Accessibility in engineering page.
- Monitoring continues after release. We track how these users actually interact with a shipped feature once it’s live, since real usage surfaces friction a moderated session doesn’t always catch.
The point of this isn’t a one-time compliance exercise. Needs, assistive technology, and browser behaviour all keep changing, and testing on a standing basis is how we keep noticing that, rather than assuming a feature that passed once will keep passing.
Definition of Done, at the feature level
A feature isn’t “done” for release if any of the following is unresolved:
- Zero unresolved axe-core violations of Critical or Serious severity.
- Full keyboard operability, verified manually, with no focus traps.
- A manual screen reader pass with no missing accessible names, no unannounced state changes, and no content that’s visible but not exposed.
- Contrast checked for every new colour pairing introduced, not only the ones reused from existing components.
- Any known limitation documented with an owner and target release, rather than left implicit.
Roles and ownership
| Role | Owns |
|---|---|
| Product manager | Naming the applicable standard at discovery; accepting or escalating known limitations. |
| Designer | Design-time accessibility checks; inclusive research participation. |
| Engineer | Semantic implementation, ARIA correctness, automated test coverage. |
| QA | Manual keyboard and screen reader verification before release sign-off. |
| Design Systems & Accessibility Guild | Component-level conformance, VPAT authoring, the standards reference, and this process. |
Training
Every new designer and engineer completes an onboarding module covering keyboard navigation, screen reader basics, and the Definition of Done relevant to their role, before their first release. The Guild runs a quarterly session reviewing real issues found in production, not hypothetical ones.