Automated accessibility testing passes with zero critical or serious violations; known issues documented

Accessibility defects are among the most regression-prone class of bugs—a layout change, a new component, or a dependency update can silently break contrast, focus management, or ARIA attribution. Manual testing catches defects at a point in time; automated tools like axe-core, jest-axe, and pa11y catch regressions continuously. WCAG 2.2 SC 4.1.1 targets robustness of implementation, and Section 508 2018 Refresh 508.2.2 requires that covered products be designed to support AT. Without automated testing, every release is a gamble that a new commit hasn't reintroduced a previously fixed Section 508 violation.

Add jest-axe for component-level checks and run it in CI:

npm install --save-dev jest-axe @testing-library/react

// __tests__/Button.test.tsx
import { render } from '@testing-library/react';
import { axe, toHaveNoViolations } from 'jest-axe';
import Button from '../src/components/Button';

expect.extend(toHaveNoViolations);

test('Button has no accessibility violations', async () => {
  const { container } = render(<Button>Submit</Button>);
  expect(await axe(container)).toHaveNoViolations();
});

For page-level coverage in Playwright, add @axe-core/playwright to your e2e suite. Add a pa11y step in .github/workflows/ci.yml:

- name: Accessibility check
  run: npx pa11y http://localhost:3000 --runner axe --threshold 0