Q24 of 24 · Accessibility
How do you build and sustain an accessibility testing programme across an engineering organisation?
Short answer
Short answer: Embed accessibility requirements in the Definition of Done and design review checklist. Provide centralised tooling (shared axe-core config, an accessible component library). Train developers and QA engineers on keyboard and screen reader basics. Track a quarterly conformance score and prioritise accessibility debt with the same rigour as security vulnerabilities.
Detail
A programme is more than tooling — it requires policy, process, training, and measurement.
Policy layer: define your accessibility standard (WCAG 2.1 AA) and embed it explicitly in the Definition of Done for new features. Add an accessibility checkpoint to the design review process — catching issues in Figma is far cheaper than finding them in code. Produce a Voluntary Product Accessibility Template (VPAT) annually.
Tooling layer: publish a shared axe-core configuration (agreed ruleset, agreed excludes) as an internal package so every team runs the same checks. If you have a design system, ensure the component library is tested for accessibility — every accessible component reduces the audit burden for every team that uses it. Provide a shared Lighthouse CI configuration teams can adopt.
Training layer: all QA engineers and developers should be able to: (1) run axe in the browser extension and interpret results, (2) do a basic keyboard navigation check, (3) use VoiceOver or NVDA for a brief page walkthrough. A 90-minute workshop covers this. Specialist screen reader expertise should be centralised with dedicated accessibility QA engineers or an external audit partner.
Measurement layer: run quarterly accessibility scoring across key user journeys. Treat the score like a test coverage metric — visible, tracked, and with a trend line. Critical accessibility defects should have an SLA matching security vulnerabilities (e.g. patch within 7 days for Critical). Track the backlog separately from the general defect backlog so accessibility debt is visible and not silently deprioritised.
The tension to name: accessibility work competes directly with feature delivery. Frame it to leadership in terms of legal risk (potential ADA/EAA litigation), market size (15% of the global population has a disability), and engineering efficiency (retrofitting accessibility is 10× more expensive than building it in from the start).