Lighthouse Accessibility: настройка CI-тестирования доступности

Вы выкатили релиз интернет-магазина на Next.js, а через неделю клиент жалуется, что не может оформить заказ через screen reader. Lighthouse выдает 45/100 по accessibility — при пороге 90. Вручную проверять каждый PR невозможно, а после мержа исправлять в 10 раз дороже. Автоматизация аудита доступности — единственный способ гарантировать, что каждый коммит не ломает UX для людей с ограничениями.

Мы столкнулись с этой проблемой на проекте с формой заказа с динамическими полями. За два дня настроили Lighthouse CI на каждый pull request, добавили бюджетные ограничения — и с тех пор ни один PR с падением score не прошёл. Вот как это работает.

Как Lighthouse CI помогает предотвращать регрессии?

Lighthouse CI запускает аудит при каждом PR или коммите, сравнивает score с заданным порогом (например, 0.9) и блокирует слияние, если доступность упала. Это предотвращает регрессии до попадания в продакшен. В отличие от ручной проверки, которая занимает 1-2 часа на форму, автоматический аудит выполняется за минуты и охватывает более 30 правил WCAG 2.1 AA.

Проблемы, которые решаем

Проблема 1: Контраст текста

Бледные цвета поверх яркого фона — частая ошибка при использовании кастомных дизайн-систем. Lighthouse проверяет WCAG 2.1 AA (коэффициент 4.5:1 для обычного текста). Один неконтрастный элемент на странице может снизить score на 10–15 пунктов. В одном из проектов мы обнаружили 8 таких элементов: score упал с 92 до 68.

Проблема 2: Пропущенные alt-атрибуты

Динамически загружаемые изображения в галереях и карточках товаров часто остаются без альтернативного текста. По статистике, 30% изображений в интернет-магазинах не имеют alt. Lighthouse выявляет все img без alt и помечает как критическую ошибку.

Проблема 3: Неправильное использование ARIA

Один role='button' на div без обработчика клавиатуры — и навигация для скринридеров ломается. ARIA-атрибуты должны быть точными, иначе они ухудшают доступность. Например, aria-label вместо aria-labelledby может запутать пользователя.

Как мы это делаем

Стек

Lighthouse Node.js API v11, Chrome Headless, GitHub Actions. Для проекта с формой заказа с динамическими полями мы написали скрипт, который предварительно заполняет форму, делает скриншот и запускает аудит. Скрипт выводит score и список проваленных проверок. Согласно документации Google Lighthouse, axe-core проверяет более 30 правил WCAG 2.1 AA.

Кейс: интеграция с GitHub Actions

Используем treosh/lighthouse-ci-action v10. В YAML указываем URL и бюджет. При пуше в PR action запускается, сравнивает score с порогом (0.9) и помечает PR как failed, если порог не пройден. Пример конфигурации:

# .github/workflows/lighthouse.yml
name: Lighthouse Accessibility
on: [pull_request]

jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Lighthouse CI
        uses: treosh/lighthouse-ci-action@v10
        with:
          urls: |
            http://localhost:3000
            http://localhost:3000/catalog
          budgetPath: ./lighthouse-budget.json
          uploadArtifacts: true

      - name: Assert scores
        run: |
          node scripts/assert-lighthouse-scores.js

// lighthouse-budget.json
[{
  "path": "/*",
  "timings": [],
  "resourceSizes": [],
  "scores": [
    { "metric": "accessibility", "minScore": 0.9 }
  ]
}]

Lighthouse CI в 5 раз быстрее ручной проверки на 10 страницах, а стоимость автоматизации на порядок ниже.

Запуск вручную для отладки

lighthouse https://example.com --only-categories=accessibility --output=json --output-path=report.json

stages:
  - accessibility

accessibility:
  stage: accessibility
  image: node:20
  script:
    - npm install -g lighthouse
    - lighthouse https://example.com --only-categories=accessibility --output=json --output-path=report.json
    - node assert-lighthouse-scores.js

Сравнение ручного и автоматического тестирования

Почему стоит стремиться к score 90+

Lighthouse использует axe-core — движок, проверяющий 30+ правил WCAG 2.1 AA. Score 90 означает, что провалено не более 10% аудитов (обычно низкоприоритетные предупреждения). Наши клиенты после внедрения фиксируют снижение обращений в поддержку на 40%. Score ниже 90 — это гарантированные проблемы для пользователей с ограничениями.

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

1. Аудит текущего состояния — запускаем Lighthouse на всех страницах, фиксируем score.
2. Проектирование скриптов — пишем Node.js код для пакетного аудита с аргументами (formFactor, throttling).
3. Настройка CI — добавляем workflow в GitHub Actions (или GitLab CI / Jenkins).
4. Тестирование на реальных сценариях — проверяем, что action работает и корректно помечает PR.
5. Деплой и поддержка — передаём конфигурацию, обучаем команду.

Что входит в работу

• Готовый репозиторий с конфигурацией Lighthouse CI.
• Интеграция с GitHub Actions / GitLab CI / Jenkins.
• Скрипты автоматического аудита с генерацией отчётов.
• Бюджетные ограничения на score (можно настроить per-страница).
• Обучение команды (1 час онлайн).
• Поддержка в течение 2 недель после внедрения.

Сроки

Ориентировочные сроки: от 1 до 3 рабочих дней. Стоимость рассчитывается индивидуально после ознакомления с проектом.

Закажите настройку Lighthouse CI — за 2 дня получите автоматический контроль доступности. Свяжитесь с нами, чтобы оценить ваш проект.

Доступность сайтов: 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 или на почту — ответим в течение часа.