test/axe-in-e2e

Dlaczego

Accessibility regressions (an unlabeled field, a contrast change, a broken dialog name) arrive with ordinary feature work. A scan in the e2e suite catches the automatable part on every pull request, including states the static audit cannot see (open menus, error messages, dialogs).

Poprawka

Use @axe-core/playwright (or cypress-axe, jest-axe / vitest-axe for component tests as a smoke check), restrict to the WCAG tags you target (wcag2a, wcag2aa, wcag21a, wcag21aa, wcag22aa), scan again after opening menus and dialogs, and track known issues by rule id and selector, not by snapshotting the whole result. Say in reports that automated checks find only part of the problems.

Przykłady

import AxeBuilder from '@axe-core/playwright'
test('checkout has no detectable accessibility violations', async ({ page }) => {
  await page.goto('/checkout')
  const results = await new AxeBuilder({ page }).withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa']).analyze()
  expect(results.violations).toEqual([])
})

Źródła

• Playwright, Accessibility testing
• axe-core, API (tags)

Przeczytaj w terminalu

npx github:dawidolko/frontend-skills explain test/axe-in-e2e