Ви викотили реліз інтернет-магазину на 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.
Чи варто прагнути до score 90+?
Так, оскільки score нижче 90 свідчить про наявність критичних проблем. Lighthouse Accessibility використовує axe-core, який перевіряє понад 30 правил WCAG 2.1 AA. Score 90+ означає, що провалено не більше 10% аудитів (зазвичай низькопріоритетні попередження). Наші клієнти після впровадження фіксують зниження звернень у підтримку на 40%.
Проблеми, які вирішуємо
Проблема 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 сторінках, а вартість автоматизації на порядок нижча — для типових проєктів економія становить до 80%.
Запуск вручну для налагодження
lighthouse http://localhost:3000 --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 http://localhost:3000 --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 | Використовувати коректні ролі та стани |
Процес роботи
- Аудит поточного стану — запускаємо 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 робочих днів. Вартість розраховується індивідуально після ознайомлення з проєктом, базове налаштування — від 500 доларів. Ми маємо 5+ років досвіду в accessibility-аудитах та понад 50 успішних інтеграцій Lighthouse CI.
Замовте налаштування Lighthouse Accessibility — за 2 дні отримайте автоматичний контроль доступності. Зв'яжіться з нами, щоб оцінити ваш проєкт.