home / skills / yonatangross / orchestkit / a11y-testing

a11y-testing skill

/plugins/ork/skills/a11y-testing

This skill helps you ensure WCAG compliance by automating accessibility tests with jest-axe and Playwright across unit and end-to-end scenarios.

npx playbooks add skill yonatangross/orchestkit --skill a11y-testing

Review the files below or copy the command above to add this skill to your agents.

Files (5)
SKILL.md
4.7 KB
---
name: a11y-testing
description: Automated accessibility testing with axe-core, Playwright, and jest-axe for WCAG compliance. Use when adding or validating a11y tests, running WCAG checks, or auditing UI accessibility.
context: fork
agent: test-generator
version: 1.1.0
tags: [accessibility, testing, axe-core, playwright, wcag, a11y, jest-axe]
allowed-tools: [Read, Write, Bash, Grep, Glob]
author: OrchestKit
user-invocable: false
---

# Accessibility Testing

Automated accessibility testing with axe-core for WCAG 2.2 compliance. Catches 30-50% of issues automatically.

## Overview

- Implementing CI/CD accessibility gates
- Running pre-release compliance audits
- Testing component accessibility in unit tests
- Validating page-level accessibility with E2E tests
- Ensuring keyboard navigation works correctly

## Quick Reference

### jest-axe Unit Testing

```typescript
// jest.setup.ts
import { toHaveNoViolations } from 'jest-axe';
expect.extend(toHaveNoViolations);

// Button.test.tsx
import { render } from '@testing-library/react';
import { axe } from 'jest-axe';

it('has no a11y violations', async () => {
  const { container } = render(<Button>Click me</Button>);
  expect(await axe(container)).toHaveNoViolations();
});
```

### Playwright + axe-core E2E

```typescript
// e2e/accessibility.spec.ts
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('page has no a11y violations', async ({ page }) => {
  await page.goto('/');
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag22aa'])
    .analyze();
  expect(results.violations).toEqual([]);
});

test('modal state has no violations', async ({ page }) => {
  await page.goto('/');
  await page.click('[data-testid="open-modal"]');
  await page.waitForSelector('[role="dialog"]');

  const results = await new AxeBuilder({ page })
    .include('[role="dialog"]')
    .withTags(['wcag2a', 'wcag2aa'])
    .analyze();
  expect(results.violations).toEqual([]);
});
```

### CI/CD Integration

```yaml
# .github/workflows/accessibility.yml
name: Accessibility
on: [pull_request]

jobs:
  a11y:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20', cache: 'npm' }
      - run: npm ci
      - run: npm run test:a11y
      - run: npm run build
      - run: npx playwright install --with-deps chromium
      - run: npm start & npx wait-on http://localhost:3000
      - run: npx playwright test e2e/accessibility
```

## Key Decisions

| Decision | Choice | Rationale |
|----------|--------|-----------|
| Test runner | jest-axe + Playwright | Unit + E2E coverage |
| WCAG level | AA (wcag2aa) | Industry standard, legal compliance |
| CI gate | Block on violations | Prevent regression |
| Browser matrix | Chromium + Firefox | Cross-browser coverage |
| Exclusions | Third-party widgets only | Minimize blind spots |
| Tags | wcag2a, wcag2aa, wcag22aa | Full WCAG 2.2 AA |
| State testing | Test all interactive states | Modal, error, loading |

## Anti-Patterns (FORBIDDEN)

```typescript
// BAD: Disabling rules globally
const results = await axe(container, {
  rules: { 'color-contrast': { enabled: false } }  // NEVER disable rules
});

// BAD: Excluding too much
new AxeBuilder({ page })
  .exclude('body')  // Defeats the purpose
  .analyze();

// BAD: Only testing happy path
it('form is accessible', async () => {
  const { container } = render(<Form />);
  expect(await axe(container)).toHaveNoViolations();
  // Missing: error state, loading state, disabled state
});

// BAD: No CI enforcement
// Accessibility tests exist but don't block PRs

// BAD: Manual-only testing
// Relying solely on human review - catches issues too late
```

## Related Skills

- `e2e-testing` - Playwright E2E testing patterns
- `unit-testing` - Jest unit testing fundamentals
- `design-system-starter` - Accessible component foundations

## Capability Details

### jest-axe-testing
**Keywords:** jest, axe, unit test, component test, react-testing-library
**Solves:**
- Component-level accessibility validation
- Fast feedback in development
- CI/CD unit test gates
- Testing all component states (disabled, error, loading)

### playwright-axe-testing
**Keywords:** playwright, e2e, axe-core, page scan, wcag, integration
**Solves:**
- Full page accessibility audits
- Testing interactive states (modals, menus, forms)
- Multi-browser accessibility verification
- WCAG compliance validation at page level

### ci-a11y-gates
**Keywords:** ci, cd, github actions, accessibility gate, automation
**Solves:**
- Blocking PRs with accessibility violations
- Automated regression prevention
- Compliance reporting and artifacts
- Integration with deployment pipelines

Overview

This skill provides automated accessibility testing using axe-core, Playwright, and jest-axe to help teams meet WCAG 2.2 AA standards. It combines fast component-level checks with robust end-to-end page audits and CI/CD gating to prevent regressions. Use it to add repeatable accessibility checks to tests and pipelines.

How this skill works

Unit tests use jest-axe with React Testing Library to assert that rendered components have no automated violations. End-to-end tests use Playwright plus axe-core to scan full pages and interactive states (modals, forms, menus) across browsers. CI jobs run both unit and E2E checks, and failures can block pull requests until violations are resolved.

When to use it

  • Add automated accessibility checks to new or existing components during development
  • Run page-level audits for releases or pre-release compliance validation
  • Enforce accessibility gates in CI to prevent regressions on PRs
  • Test interactive states such as modals, error displays, and loading states
  • Verify cross-browser WCAG compliance with Playwright across Chromium and Firefox

Best practices

  • Run jest-axe on every component state (default, disabled, error, loading) for fast feedback
  • Use AxeBuilder tags (wcag2a, wcag2aa, wcag22aa) to align scans with WCAG 2.2 AA requirements
  • Include interactive state tests in E2E suites (open modal, trigger validation, keyboard navigation)
  • Block CI on accessibility violations to make fixes part of the workflow, not optional
  • Avoid disabling rules globally or excluding large page sections—address root causes instead

Example use cases

  • Unit test a Button and its disabled and focus states with jest-axe to catch role/label issues
  • E2E scan the landing page and interactive modal flow with AxeBuilder in Playwright
  • Add a GitHub Actions job that runs a11y unit tests and Playwright scans on pull requests
  • Audit third-party integrations separately and limit exclusions to unavoidable widgets
  • Run periodic site-wide scans before major releases to generate compliance reports

FAQ

Will automated tests catch all accessibility issues?

No. Automated checks typically catch 30–50% of issues. Combine them with manual testing, keyboard navigation checks, and assistive technology testing for full coverage.

Which WCAG level should I test against?

Target WCAG 2.2 AA (wcag2aa and wcag22aa) for industry-standard compliance; include wcag2a for basic requirements.