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

• ID: gov-section-508.wcag-core.automated-testing

• Severity: info

• Weight: 1

• What to look for: Count all relevant instances and enumerate each. Look for evidence of automated accessibility testing in the project. Check package.json for axe-core, jest-axe, pa11y, @axe-core/playwright, or @axe-core/react dependencies. Check test files for accessibility assertions. Check CI/CD configuration files (.github/workflows/, netlify.toml, vercel.json) for accessibility checks in the pipeline. Check README or docs for mention of automated a11y testing.

• Pass criteria: At least one automated accessibility testing tool is configured. At least 1 implementation must be verified. Tests are integrated into the test suite or CI pipeline. Any violations caught by the tool are either resolved or documented as known issues.

• Fail criteria: No automated accessibility testing tooling is present in the project.

• Skip (N/A) when: Never — automated testing catches regressions and is applicable to all projects.

• Detail on fail: Example: "No accessibility testing dependencies found in package.json. No jest-axe, axe-core, or pa11y configuration found. No accessibility checks in CI pipeline. Accessibility issues have no automated safety net."

• Remediation: Add jest-axe to your test suite for component-level accessibility checking:

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

  // __tests__/HomePage.test.tsx
  import { render } from '@testing-library/react';
  import { axe, toHaveNoViolations } from 'jest-axe';
  import HomePage from '../app/page';
  
  expect.extend(toHaveNoViolations);
  
  test('homepage has no accessibility violations', async () => {
    const { container } = render(<HomePage />);
    const results = await axe(container);
    expect(results).toHaveNoViolations();
  });
  

  For end-to-end testing, add @axe-core/playwright to Playwright tests. Run npx pa11y http://localhost:3000 for quick site-wide checks.

• Cross-reference: For related patterns and deeper analysis, see the corresponding checks in other AuditBuffet audits covering this domain.