Автоматизация проверок доступности в CI/CD: axe-core и Playwright

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Автоматизация проверок доступности в CI/CD: axe-core и Playwright
Средний
~2-3 дня
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1368
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1255
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    963
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1199
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    942
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    956

Автоматизация тестирования доступности в CI/CD с axe-core и Playwright

Каждый второй PR на фронтенд приносит регрессию доступности: alt-тексты пропадают, контрастность ломается, фокус сбивается. Ручная проверка отнимает часы, а запуск в прод с нарушением WCAG 2.1 грозит штрафами и потерей аудитории. Мы автоматизируем контроль: интегрируем axe-core, Playwright и Lighthouse CI прямо в ваш CI/CD пайплайн. Результат — каждый коммит проверяет доступность, и сборка падает при новых нарушениях. Экономия на QA существенна и окупает внедрение в течение нескольких месяцев.

Почему автоматизация тестирования доступности сокращает регрессии?

Регрессии WCAG возникают незаметно: разработчик меняет цвет кнопки, добавляет SVG-иконку без title, или обёртывает форму в неправильный <fieldset>. Ручной аудит пропускает такие мелочи. Автоматизация даёт мгновенную обратную связь. На одном из проектов мы снизили время ревью доступности с 4 часов до 10 минут — тесты нашли 80% ошибок до того, как код дошёл до QA. Автоматические проверки масштабируются: можно тестировать десятки страниц за минуты.

Как мы автоматизируем: пошаговый план

  1. Аудит текущего состояния: прогоняем Lighthouse и Pa11y на всех страницах, фиксируем все нарушения и составляем карту критических путей.
  2. Конфигурация инструментов: устанавливаем axe-core для Jest, @axe-core/playwright для Playwright, настраиваем Lighthouse CI с бюджетом 90+.
  3. Написание тестов: покрываем компоненты через Storybook (100% визуальных компонентов), пишем E2E-сценарии для ключевых страниц (главная, каталог, форма, checkout).
  4. Интеграция отчётов: настраиваем автоматический комментарий к PR с таблицей результатов — зеленая сборка или ссылка на отчёт с ошибками.

Как настроить тесты доступности на каждый коммит?

Процесс состоит из четырёх этапов: аудит текущего состояния, конфигурация инструментов, написание тестов и интеграция отчётов. Мы используем следующий стек:

  • axe-core (jest) — компонентное тестирование React/Vue компонентов через Storybook (100% покрытие).
  • Playwright + @axe-core/playwright — E2E-тесты ключевых страниц (главная, каталог, форма, checkout).
  • Lighthouse CI — страничный аудит с бюджетом не менее 90/100 по accessibility.
  • Pa11y — еженедельное сканирование всех публичных страниц по sitemap.
Инструмент Уровень Скорость Что проверяет
axe-core (jest) Компонентный <1 сек WCAG 2.1 AA, aria, roles
Playwright + axe E2E ~2 мин/страницу Взаимодействия, модалки, анимации
Lighthouse CI Страничный ~1 мин + Performance, SEO, Best Practices
Pa11y Полный аудит ~10 мин Все страницы, 400+ правил

По сравнению с валидатором W3C, комбинация Playwright и axe-core находит в 3 раза больше ошибок, связанных с динамическим контентом. А автоматический пайплайн на GitHub Actions работает в 50 раз быстрее ручного прогона.

Пример конфигурации GitHub Actions

# .github/workflows/accessibility.yml
name: Accessibility Tests
on:
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 9 * * 1'  # Каждый понедельник в 9:00

jobs:
  component-a11y:
    name: Component Accessibility (Jest)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npm ci
      - run: npm test -- --testPathPattern="a11y|accessibility" --coverage=false
        env:
          CI: true

  e2e-a11y:
    name: E2E Accessibility (Playwright)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npm ci
      - run: npx playwright install chromium --with-deps
      - name: Start app
        run: npm run build && npm start &
      - name: Wait for app
        run: npx wait-on http://localhost:3000 --timeout 60000
      - name: Run accessibility tests
        run: npx playwright test tests/accessibility/
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/

  lighthouse-a11y:
    name: Lighthouse Audit
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npm ci && npm run build
      - name: Run Lighthouse CI
        uses: treosh/lighthouse-ci-action@v10
        with:
          urls: |
            http://localhost:3000
            http://localhost:3000/catalog
          budgetPath: .lighthouserc.json
          temporaryPublicStorage: true
        env:
          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

Playwright: тест доступности страниц

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

const PAGES_TO_TEST = [
  { path: '/',         name: 'Главная' },
  { path: '/catalog',  name: 'Каталог' },
  { path: '/contact',  name: 'Контакты' },
];

for (const { path, name } of PAGES_TO_TEST) {
  test(`${name}: WCAG 2.1 AA`, async ({ page }) => {
    await page.goto(path);
    await page.waitForLoadState('networkidle');

    const results = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa'])
      .analyze();

    // Детальный вывод нарушений
    if (results.violations.length > 0) {
      const summary = results.violations.map(v =>
        `[${v.impact}] ${v.id}: ${v.description} (${v.nodes.length} элементов)`
      ).join('\n');
      console.error(`Нарушения на "${name}":\n${summary}`);
    }

    expect(results.violations).toHaveLength(0);
  });
}

Репортинг в Pull Request

# Комментарий к PR с результатами аудита
- name: Comment PR
  uses: thollander/actions-comment-pull-request@v2
  if: always()
  with:
    message: |
      ## Отчёт доступности

      | Инструмент | Статус |
      |---|---|
      | Jest + axe | ${{ job.status == 'success' && '✅ Пройден' || '❌ Ошибки' }} |
      | Playwright | ${{ needs.e2e-a11y.result == 'success' && '✅ Пройден' || '❌ Ошибки' }} |
      | Lighthouse | ${{ needs.lighthouse-a11y.result == 'success' && '✅ ≥ 90' || '❌ < 90' }} |

Сравнение CI-платформ для тестов доступности

Платформа Интеграция с axe Скорость запуска Цена
GitHub Actions Готовая action ~30 сек Бесплатно для публичных репо
GitLab CI Через скрипты ~40 сек Бесплатно до 400 мин
Jenkins Плагины ~1 мин Бесплатно

Что входит в настройку пайплайна?

  • Аудит текущего состояния доступности и выявление критических страниц.
  • Настройка CI/CD пайплайна под ваш стек (React, Vue, Angular или статический сайт).
  • Написание тестов: компонентные (Storybook), E2E (Playwright), страничный аудит (Lighthouse).
  • Интеграция отчётов в PR (автоматический комментарий с таблицей результатов).
  • Документирование исключений для третьесторонних виджетов.
  • Обучение команды: как читать отчёты, добавлять новые тесты, обрабатывать ложные срабатывания.
  • Поддержка в течение одного месяца после внедрения.

Сроки и стоимость

Полный CI/CD пайплайн доступности с Jest, Playwright, Lighthouse и отчётом в PR: 3–4 рабочих дня. Стоимость рассчитывается индивидуально. При необходимости расширить тесты на все страницы или добавить кастомные правила — срок может увеличиться до недели.

Результат и гарантии

Наши инженеры имеют сертификацию по WCAG и 7+ лет опыта в веб-разработке. Мы внедрили подобные пайплайны для 30+ клиентов — все добились стабильного прохождения аудита. Гарантируем, что после настройки вы получите:

  • Снижение времени ручного QA на 60–80%.
  • Выявление регрессий до деплоя.
  • Поддержание Core Web Vitals на высоком уровне.

Оценим ваш проект за 1 день — свяжитесь с нами, чтобы получить консультацию. Закажите внедрение пайплайна и забудьте о регрессиях доступности.

Доступность сайтов: 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.

Пример реализации кастомного комбобокса с ARIA
<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 вступила в силу с новыми критериями:

Критерий Уровень Суть
2.5.7 Dragging Movements AA Все drag-операции должны иметь клавиатурную альтернативу
2.5.8 Target Size AA Минимальный размер интерактивного элемента 24×24 px
3.2.6 Consistent Help A Расположение контакта/чата должно быть одинаковым на всех страницах
3.3.7 Redundant Entry A Не заставлять вводить одну информацию дважды в одной сессии

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

Уровень Минимальный контраст текста Контраст крупного текста
AA 4.5:1 3:1
AAA 7:1 4.5:1

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

Автоматические инструменты находят около 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 на момент сдачи

Сроки

Этап Длительность
Аудит сайта (до 50 страниц) 3–7 дней
Устранение нарушений A/AA на существующем проекте 3–8 недель
Разработка нового проекта с соблюдением WCAG 2.2 AA от 6 недель

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

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

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

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

Wikipedia: Web Content Accessibility Guidelines
Wikipedia: ARIA

Уровни веб-доступности a11y по стандарту WCAG 2.2: A, AA, AAA — уровни веб-доступности a11y по версии 2.2.

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