Вы выкатили релиз интернет-магазина на 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 Пример интеграции с GitLab CI
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 Сравнение ручного и автоматического тестирования
| Метод | Время на проверку | Охват правил | Частота | Стоимость |
|---|---|---|---|---|
| Ручная | 1–2 часа на форму | Субъективный | По необходимости | Высокая |
| Lighthouse CI | 5 минут на 10 страниц | 30+ правил WCAG 2.1 | Каждый PR | Низкая |
| Типичная ошибка | Влияние на score | Решение |
|---|---|---|
| Недостаточный контраст | -10..-15 | Увеличить контраст до 4.5:1 |
| Отсутствие alt у img | -5..-10 | Добавить описательный alt |
| Неправильный ARIA | -8..-12 | Использовать корректные роли и состояния |
Почему стоит стремиться к score 90+
Lighthouse использует axe-core — движок, проверяющий 30+ правил WCAG 2.1 AA. Score 90 означает, что провалено не более 10% аудитов (обычно низкоприоритетные предупреждения). Наши клиенты после внедрения фиксируют снижение обращений в поддержку на 40%. Score ниже 90 — это гарантированные проблемы для пользователей с ограничениями.
Процесс работы
- Аудит текущего состояния — запускаем Lighthouse на всех страницах, фиксируем score.
- Проектирование скриптов — пишем Node.js код для пакетного аудита с аргументами (formFactor, throttling).
- Настройка CI — добавляем workflow в GitHub Actions (или GitLab CI / Jenkins).
- Тестирование на реальных сценариях — проверяем, что action работает и корректно помечает PR.
- Деплой и поддержка — передаём конфигурацию, обучаем команду.
Что входит в работу
- Готовый репозиторий с конфигурацией Lighthouse CI.
- Интеграция с GitHub Actions / GitLab CI / Jenkins.
- Скрипты автоматического аудита с генерацией отчётов.
- Бюджетные ограничения на score (можно настроить per-страница).
- Обучение команды (1 час онлайн).
- Поддержка в течение 2 недель после внедрения.
Сроки
Ориентировочные сроки: от 1 до 3 рабочих дней. Стоимость рассчитывается индивидуально после ознакомления с проектом.
Закажите настройку Lighthouse CI — за 2 дня получите автоматический контроль доступности. Свяжитесь с нами, чтобы оценить ваш проект.