Часто нарушения доступности (a11y) всплывают только на этапе ручного тестирования или, что хуже, в продакшне. Каждый пропущенный критический баг — например, отсутствие alt у изображения или неработающая навигация с клавиатуры — может стоить репутации и крупных штрафов. Мы автоматизируем проверку WCAG 2.1/2.2 через axe-core, чтобы отлавливать такие проблемы на этапе CI/CD. Библиотека от Deque Systems находит около 57% нарушений автоматически, оставляя оставшиеся на ручной аудит. Опыт показывает: после внедрения axe-core количество регрессий по доступности падает на 70–80%.
Как axe-core помогает автоматизировать проверку доступности?
axe-core работает как в браузере, так и в Node.js, и легко встраивается в существующие тестовые фреймворки. В основе лежат правила WCAG 2.1, сгруппированные по тегам (wcag2a, wcag2aa, wcag21aa). Для каждого элемента страницы библиотека проверяет: контрастность, семантику заголовков, доступность форм, ARIA-атрибуты и многое другое. Результат — структурированный отчёт с типом, уровнем серьёзности и ссылкой на элемент.
Интеграция с Jest + Testing Library
npm install --save-dev jest-axe @testing-library/react // __tests__/accessibility.test.tsx import { render } from '@testing-library/react'; import { axe, toHaveNoViolations } from 'jest-axe'; expect.extend(toHaveNoViolations); describe('Доступность компонентов', () => { it('Button не имеет нарушений', async () => { const { container } = render(<Button>Отправить</Button>); const results = await axe(container); expect(results).toHaveNoViolations(); }); it('Form не имеет нарушений', async () => { const { container } = render( <form> <label htmlFor="email">Email</label> <input id="email" type="email" /> <button type="submit">Войти</button> </form> ); const results = await axe(container, { rules: { 'color-contrast': { enabled: true }, 'label': { enabled: true }, }, }); expect(results).toHaveNoViolations(); }); }); Интеграция с Playwright
// tests/accessibility.spec.ts import { test, expect } from '@playwright/test'; import AxeBuilder from '@axe-core/playwright'; test('Главная страница проходит WCAG 2.1 AA', async ({ page }) => { await page.goto('/'); const results = await new AxeBuilder({ page }) .withTags(['wcag2a', 'wcag2aa', 'wcag21aa']) .exclude('.cookie-banner') // Исключаем компоненты третьих сторон .analyze(); expect(results.violations).toEqual([]); }); test('Форма регистрации — доступность', async ({ page }) => { await page.goto('/register'); const results = await new AxeBuilder({ page }) .include('#registration-form') .analyze(); // Детальный отчёт при падении if (results.violations.length > 0) { console.table(results.violations.map(v => ({ id: v.id, impact: v.impact, description: v.description, nodes: v.nodes.length, }))); } expect(results.violations).toEqual([]); }); Почему стоит интегрировать axe-core в CI/CD?
Ручную проверку доступности сложно масштабировать: на один аудит страницы уходит 2–3 часа. Интеграция axe-core в CI/CD (например, через Playwright тест перед каждым деплоем) автоматизирует эту проверку. Мы гарантируем, что критические нарушения не попадут в продакшн. В одном из проектов с 500+ страницами после настройки axe-core количество регрессий по a11y снизилось с 30 до 2–3 в месяц.
Сравнение ручного и автоматического аудита
| Характеристика | Ручной аудит | axe-core |
|---|---|---|
| Время на страницу | 15–30 минут | 5–10 секунд |
| Охват критических нарушений | 100% (с квалифицированным специалистом) | ~90% |
| Частота запуска | Раз в спринт | При каждом коммите |
| Точность | Зависит от усталости | Стабильна |
Уровни нарушений и их влияние
| Impact | Значение | Пример | Сертификация WCAG |
|---|---|---|---|
| critical | Блокирует доступ | Изображение без alt | Не проходит ни один уровень |
| serious | Значительно мешает | Форма без label | Не проходит AA |
| moderate | Затрудняет использование | Недостаточный контраст | Может проходить A, но не AA |
| minor | Небольшое неудобство | Неправильный lang | Проходит, но лучше исправить |
С чего начать: типичные ошибки при настройке axe-core
При первом запуске axe-core часто выдаёт ложные срабатывания на сторонних iframe, cookie-баннерах или динамически подгружаемом контенте. Чтобы избежать шума, настройте исключения через exclude() и задайте точные теги проверки (например, wcag2aa). Также важно правильно сконфигурировать правила: отключить те, что не применимы к проекту (например, color-contrast для компонентов с кастомными цветами).
Чек-лист внедрения axe-core
- Исключить iframe и виджеты третьих сторон.
- Настроить кастомные правила для специфичных компонентов.
- Интегрировать с Jest для модульных тестов компонентов.
- Интегрировать с Playwright для e2e тестов критических страниц.
- Добавить запуск в CI/CD (GitHub Actions, GitLab CI).
- Настроить уведомления о падениях.
Что входит в работу
- Документация: отчёт о текущих нарушениях, список правил, исключения для сторонних компонентов.
- Интеграция: настройка axe-core в Jest (модульные тесты компонентов), Playwright (e2e-тесты страниц) и Storybook (визуальная инспекция) — при необходимости.
- CI/CD пайплайн: добавление тестов доступности в GitLab CI, GitHub Actions или аналоги.
- Обучение команды: базовая лекция (1–2 часа) по WCAG и работе с axe-core.
- Поддержка: консультации по исправлению выявленных нарушений в течение месяца после внедрения.
Сроки
Настройка axe-core в Jest + Playwright, покрытие ключевых страниц и компонентов: 2–3 рабочих дня. Если проект использует нестандартные фреймворки (Angular, Vue 3 с SSR) или требуется глубокая кастомизация правил, срок может увеличиться до 5 дней. Мы работаем по предоплате 50%, окончательная стоимость рассчитывается индивидуально после аудита вашего кода.
Наша команда имеет 5+ лет опыта в a11y-аудите и более 50 успешных проектов. Свяжитесь с нами для консультации по внедрению axe-core в ваш проект. Закажите аудит доступности — это снизит риски и сэкономит время.