Treat accessibility as part of the platform and part of the definition of done. Here is how, in four parts.
Built in: design system components are accessible by default. They handle focus management, roles, labels and keyboard support. So most of the work is done once. Lint rules like jsx-a11y catch common mistakes in the editor. "a11y" is short for accessibility.
Automated checks: axe, an accessibility testing tool, runs in component tests and end-to-end tests in CI. It fails the build on violations. Automated tools catch only some of the issues. So they are a minimum level, not proof.
Manual checks:
- A short keyboard and screen reader checklist in the PR template, for UI changes.
- Regular audits of key flows with people who use assistive technology.
Ownership:
- A target standard: WCAG 2.2 AA.
- Accessibility champions in each team.
- Training.
- Accessibility bugs triaged with the same severity scale as other bugs.
Design reviews check contrast, focus order and target sizes before anyone writes code. This is called shifting left: catching problems earlier in the process.
- Design system components are accessible by default.
- Lint rules plus axe in CI give a minimum level of checking.
- Manual keyboard and screen reader checks are still needed.
- Set a clear standard, have champions in teams, and triage a11y bugs like other bugs.
- Shift left: check accessibility in design, before code is written.
- MDN: Accessibility (https://developer.mozilla.org/en-US/docs/Web/Accessibility)developer.mozilla.org