AXE-core: автоматизация WCAG 2.1 с Jest и Playwright

Часто нарушения доступности (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

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

Доступность сайтов: WCAG, скринриндеры, клавиатурная навигация

На сайте крупного банка кнопка «Подать заявку» в разметке была <div class="btn" onclick="...">. Скринридер NVDA её не анонсировал, Tab пропускал, Enter не срабатывал. Для тысяч незрячих пользователей этот банк просто не существовал как онлайн-сервис. Мы видим такие проблемы каждый день в десятках проектов — и разработка доступных сайтов по стандарту WCAG 2.2 AA становится единственным способом избежать дискриминации и юридических рисков. Штрафы за недоступность для юрлиц достигают 300 000 ₽, а судебные иски — миллионы.

В этой карточке — как мы делаем веб-доступность a11y работающей, на реальных кейсах, с конкретным стеком и цифрами. Без общих фраз.

Почему семантическая разметка — основа веб-доступности a11y?

Большинство проблем доступности решается правильным HTML, а не дополнительными ARIA-атрибутами. <button> вместо <div onclick>, <nav> вместо <div class="navigation">, <h1>–<h6> в правильной иерархии, <label for="field-id"> вместо <div class="label">. Это базовый уровень, но на практике каждая вторая форма в российских интернет-магазинах не имеет корректных <label>.

ARIA нужна там, где нативный HTML не справляется: кастомные компоненты — выпадающие меню, тултипы, модальные окна, табы, accordion. И вот тут начинается сложность.

Типичная ошибка в кастомных дропдаунах: скринридер не знает, что это combobox, не объявляет количество опций, не говорит какая выбрана, фокус не переходит в список при открытии. Правильная реализация:

• role="combobox" на инпуте
• aria-expanded="true/false" при открытии/закрытии
• aria-controls="listbox-id" указывает на список
• aria-activedescendant — ID текущего выбранного элемента
• role="option" и aria-selected на каждом варианте

Это не теория, это то, что тестируется скринридером. NVDA + Chrome или VoiceOver + Safari — обязательная часть QA.

<div role="combobox" aria-expanded="false" aria-controls="listbox-1" aria-activedescendant="" tabindex="0">
  <label for="input-1">Выберите город</label>
  <input id="input-1" type="text" role="combobox" aria-autocomplete="list" />
  <ul id="listbox-1" role="listbox" aria-label="Города">
    <li role="option" aria-selected="false" id="opt-1">Москва</li>
    <li role="option" aria-selected="false" id="opt-2">Санкт-Петербург</li>
  </ul>
</div>

Стоимость исправления одного нарушения уровня A — от 5 000 до 15 000 ₽ в зависимости от сложности. Внедрение a11y с этапа проектирования сокращает бюджет на рефакторинг в 2–3 раза по сравнению с доработкой готового сайта.

Как правильно построить клавиатурную навигацию?

Tab-порядок должен совпадать с визуальным порядком элементов. Если в HTML кнопка «Отмена» стоит перед «Подтвердить», но CSS их меняет местами — пользователь клавиатуры в замешательстве.

Focus trap в модальных окнах. Когда модалка открывается, Tab должен циклиться только внутри неё. При закрытии — возврат фокуса на элемент, который открыл модалку. Без этого пользователь после закрытия оказывается в начале страницы.

tabindex="-1" — элемент не попадает в Tab-последовательность, но может получить фокус программно. Используется для элементов, которые получают фокус через JavaScript (заголовки секций после навигации по якорям).

tabindex="1" и выше — почти всегда ошибка. Явный порядок ломает естественный и создаёт непредсказуемое поведение. Управляйте порядком через DOM, не через tabindex.

Skip links — ссылка «Перейти к содержимому», скрытая визуально, видимая при Tab. Позволяет пользователям скринридеров пропустить повторяющуюся навигацию.

Цвет и контраст: требования и частые нарушения

WCAG 2.2 AA требует контраст 4.5:1 для обычного текста, 3:1 для крупного (18px+ или 14px+ bold). AAA требует 7:1 и 4.5:1.

Самые частые нарушения: серый placeholder в инпутах (#999 на белом = 2.9:1), светло-серый secondary текст, белый текст на пастельном фоне.

Цвет не должен быть единственным индикатором: «поля обязательные выделены красным» без звёздочки — нарушение для людей с цветовой слепотой.

Инструменты проверки: axe DevTools, WAVE, Accessibility Inspector в Chrome DevTools. axe-core интегрируется в Playwright-тесты: автоматическая проверка на 80+ правил при каждом деплое. Ручное тестирование находит примерно на 60% больше ошибок, чем автоматическое.

Медиаконтент и динамика: что важно?

Изображения без alt — частый базовый провал. alt должен быть смысловым: не alt="image_123.jpg", а описание содержимого, релевантное контексту. Декоративные изображения — alt="" (пустой, не отсутствующий атрибут).

Видео должно иметь субтитры. YouTube автосубтитры — не стандарт, они ошибаются. WebVTT-файлы с корректными субтитрами для всего образовательного и маркетингового видеоконтента.

Анимации — проблема для пользователей с вестибулярными расстройствами. @media (prefers-reduced-motion: reduce) — медиа-запрос, отключающий или замедляющий анимации для пользователей с такой настройкой в ОС.

Что изменилось в WCAG 2.2?

Версия 2.2 вступила в силу с новыми критериями:

Эти критерии повышают порог входа, но мы уже включаем их в стандартный чек-лист.

Аудит и устранение нарушений

Автоматические инструменты находят около 30–40% нарушений. Остальное — только ручное тестирование. Минимальный сценарий: пройти весь критический user flow (регистрация, покупка, форма) только клавиатурой и со скринридером.

Процесс работы

1. Автоматический аудит — axe-core, Lighthouse, WAVE — выдача 80+ правил.
2. Ручное тестирование — NVDA, VoiceOver, клавиатура — 2–3 дня на типовой сайт.
3. Приоритизация нарушений — P1 (блокирует использование), P2 (создаёт сложности), P3 (улучшения).
4. Исправление — итерациями, встраиваем проверки в CI через Playwright + axe.
5. Повторный аудит — закрытие всех P1/P2 перед релизом.
6. Документация и передача — отчёт с результатами, рекомендации по поддержке, обучение команды.

Результаты и объём работ

• Полный отчёт по аудиту с приоритизацией нарушений (PDF/HTML)
• Исправленный код: семантическая разметка, ARIA, клавиатурная навигация
• Интеграция axe-core в CI/CD для регрессионного контроля
• Обучение разработчиков заказчика по работе с a11y (2-часовая сессия)
• Доступ к репозиторию с примерами корректных компонентов
• Гарантия соответствия WCAG 2.2 AA на момент сдачи

Сроки

Бюджет рассчитывается индивидуально после аудита. Свяжитесь с нами — оценим ваш проект за 1 день. Получите консультацию и чек-лист бесплатно при заказе аудита.

Опыт и гарантии

Мы занимаемся веб-доступностью a11y более 8 лет. Реализовали более 50 проектов для банков, ритейла и госсектора. Сертифицированные специалисты (IAAP CPACC, WAS). Гарантируем прохождение аудита третьей стороной или дорабатываем бесплатно.

Стандарт WCAG 2.2 — официальная рекомендация W3C, определяющая требования к доступности веб-контента.

Wikipedia: Web Content Accessibility Guidelines
Wikipedia: ARIA

— уровни веб-доступности a11y по версии 2.2.

Закажите аудит сейчас — получите чек-лист и предварительную оценку бесплатно. Пишите в Telegram или на почту — ответим в течение часа.