How would you enforce WCAG 2.1 AA compliance across CI/CD?

WHAT THIS TESTS: This question evaluates whether you can design a defense-in-depth accessibility strategy that shifts left without creating noise. Interviewers want to see that you understand WCAG 2.1 AA is not a single check but a spectrum of rules that should be validated at different pipeline stages. They are looking for familiarity with automated tooling limits, the ability to distinguish lintable issues from those requiring runtime or visual validation, and experience gating deploys without paralyzing the team with false positives.

A GOOD ANSWER COVERS: First, static analysis in the inner loop using eslint-plugin-jsx-a11y or similar IDE and pre-commit rules to catch missing alt text and invalid ARIA roles before code review. Second, component-level unit tests with jest-axe or vitest-axe that mount individual components and assert zero violations for critical and serious impact levels. Third, integration and end-to-end scanning using Playwright or Cypress with axe-core injected after page load and after state changes like modal opens, because many WCAG failures only surface in the DOM after hydration or interaction. Fourth, visual regression testing specifically for focus indicators, hover states, and color contrast using tools like Chromatic or Applitools with forced-focus emulation, since automated DOM scanners cannot reliably judge contrast ratios on complex gradients or image-backed text. Fifth, deployment gates that parse axe results by severity and impact, failing builds on violations with no matching baseline exception ticket and allowing teams to suppress known issues with expiration dates. Sixth, custom checks for application-specific patterns such as heading hierarchy violations, skip-link presence on every route, or touch target size minimums using custom axe rules or Playwright assertions.

COMMON WRONG ANSWERS: Suggesting only Lighthouse CI as the accessibility gate, since it misses interactive state issues and provides only a sampled snapshot. Proposing to block deploys on every single warning including false positives like color contrast on generated charts without exception workflows, which shows inexperience with tooling adoption. Mentioning manual audits as a pipeline stage without explaining how they integrate into release cadence. Ignoring the difference between unit testable rules and those requiring a real browser layout engine. Failing to mention focus management or keyboard navigation, which automated scanners flag incompletely.

LIKELY FOLLOW-UPS: How do you handle dynamic content like single page application route changes or infinite scroll where axe must be re-run after DOM updates. What is your strategy for third-party widget accessibility when you cannot control the source code. How do you balance strictness with velocity when a legacy page has thousands of pre-existing violations. Which WCAG success criteria are not automatable and how do you ensure those are covered through other means.

ONE CONCRETE EXAMPLE: At a previous company, we integrated axe-core into a Playwright test suite that ran against ten critical user flows on every pull request. We configured the runner to inject axe after each navigation and after every click that triggered a modal or dropdown. Violations were categorized by impact, and only serious or critical issues failed the build. We added a custom Playwright check that tabbed through each page and captured screenshots of focus rings, then compared them in Chromatic to catch regressions where CSS outline removal broke keyboard visibility. For deployment, we fed the JSON axe results into a custom GitHub check that blocked merge unless the violation delta was zero or each new issue was ticketed in Jira with an a11y label and a two-sprint remediation deadline. This dropped production accessibility regressions by over 90 percent in three months while keeping build times under eight minutes.