CodePark/ questions / i18n & accessibility at scale
START PRACTICINGPRACTICE
Frontend question · Frontend system design › i18n & accessibility at scale

How do you make accessibility sustainable across a large organisation with many teams, instead of a one-off audit?

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.