patterntypescriptnoneModerate
Accessibility Testing with jest-axe
Viewed 0 times
accessibilitya11yaxejest-axeARIAWCAGautomated audit
Error Messages
Problem
Accessibility issues are often discovered only after deployment during manual audits. Automated checks for contrast, ARIA labels, and semantic HTML are skipped because they seem hard to integrate into unit tests.
Solution
Use jest-axe (or vitest-axe) to run automated accessibility checks in component tests.
import { render } from '@testing-library/react';
import { axe, toHaveNoViolations } from 'jest-axe';
expect.extend(toHaveNoViolations);
test('UserCard has no accessibility violations', async () => {
const { container } = render(
<UserCard user={{ name: 'Alice', role: 'admin' }} />
);
const results = await axe(container);
expect(results).toHaveNoViolations();
});
// Test interactive elements
test('form is accessible', async () => {
const { container } = render(<LoginForm />);
expect(await axe(container)).toHaveNoViolations();
});
// Common issues caught by axe:
// - Images without alt text
// - Form inputs without labels
// - Insufficient color contrast
// - Invalid ARIA attributes
// - Missing landmark regions
// - Buttons without accessible namesWhy
Axe-core (used by jest-axe) catches ~57% of accessibility issues automatically. Running it in tests catches regressions immediately rather than at audit time.
Gotchas
- jest-axe only catches automatable violations — it cannot test keyboard navigation, focus management, or screen reader announcements.
- The axe() call is async — always await it.
- Axe checks the rendered DOM including inherited styles — use a realistic test environment (jsdom).
Revisions (0)
No revisions yet.