How would you enforce WCAG compliance across multiple frontend teams?

Make accessibility the default, not a review-time gate: accessible design-system components, automated linting + axe in CI, accessible-by-default patterns, training, and manual audits (keyboard, screen reader) for what automation can't catch. Bake it into the process, not heroics.

6 min read·~10 min to think through

Enforcing WCAG across teams is a systems and process problem. You can't audit your way to accessibility one PR at a time — you make the accessible path the easy path.

1. Shift left — bake it into the foundation

Accessible design-system components. If Button, Modal, Input, Tabs ship with correct roles, focus management, and keyboard support, every team gets accessibility for free. This is the single highest-leverage move.
Design-time — color contrast, focus states, and text alternatives specified in Figma; designers own this too.

2. Automate the catchable failures

Linting — eslint-plugin-jsx-a11y flags missing alt text, bad ARIA, non-interactive elements with handlers.
CI gates — axe-core / jest-axe in component tests; @axe-core/playwright or Lighthouse CI on key pages. Fail the build on violations.
Storybook a11y addon so issues surface during component development.
Automation catches ~30–40% of issues — necessary but not sufficient.

3. Manual testing for what automation misses

Keyboard-only pass — tab order, focus traps, visible focus, no keyboard traps.
Screen reader testing — NVDA, VoiceOver, JAWS on critical flows.
Zoom to 200%, reduced motion, high contrast.
Make these part of QA and the definition of done for key features.

4. Process & culture

Definition of done includes accessibility — not a separate phase.
PR checklist item; a11y reviewers or champions per team.
Training & docs — patterns library, common pitfalls, "how to test with a screen reader."
Periodic audits — internal or third-party against WCAG 2.1/2.2 AA; track issues like any other tech debt.

5. Accountability

A clear target (e.g. WCAG 2.2 AA) and ownership.
Accessibility bugs triaged with real severity, not perpetually deprioritized.
Track a metric (axe violations, audit scores) so it's visible.

The core principle

Relying on every engineer remembering every WCAG rule on every PR doesn't scale. Encode it: accessible components, automated gates, clear DoD, and manual testing where it counts. Make non-compliance the thing that takes extra effort.

Follow-up questions

•What share of WCAG issues can automation actually catch?
•Why is an accessible design system the highest-leverage investment?
•How do you test something automation can't — like a focus trap?
•How do you keep accessibility from being perpetually deprioritized?

Common mistakes

•Treating accessibility as a one-time audit instead of an ongoing process.
•Relying only on automated tools — they catch a minority of issues.
•No accessible component library, so every team reinvents (badly).
•Accessibility as a separate phase rather than part of definition of done.

Performance considerations

Edge cases

•Third-party components and embeds that aren't accessible.
•Complex custom widgets (data grids, drag-and-drop) with no native equivalent.
•Legacy areas of the app predating the standards.
•Dynamic content updates not announced to screen readers.

Real-world examples

•An accessible design system (roles, focus, keyboard baked in) so product teams inherit compliance.
•axe + Lighthouse CI gates failing builds on regressions; quarterly third-party WCAG audits.

Senior engineer discussion

Seniors treat this as process design, not policing: highest leverage is an accessible design system, then automated gates in CI, then manual keyboard/screen-reader testing for the majority of issues automation misses. They bake it into definition-of-done, assign ownership and a measurable target, and manage remaining gaps as tracked tech debt.