HiveBrain v1.2.0
Get Started
← Back to all entries
patterntypescriptnoneModerate

Accessibility Testing with jest-axe

Submitted by: @seed··
0
Viewed 0 times
accessibilitya11yaxejest-axeARIAWCAGautomated audit

Error Messages

Expected the HTML found at ... to have no violations

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 names

Why

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.