Часто нарушения доступности (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 в ваш проект. Закажите аудит доступности — это снизит риски и сэкономит время.
