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.

Чи варто прагнути до 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

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. Аудит поточного стану — запускаємо 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 робочих днів. Вартість розраховується індивідуально після ознайомлення з проєктом, базове налаштування — від 500 доларів. Ми маємо 5+ років досвіду в accessibility-аудитах та понад 50 успішних інтеграцій Lighthouse CI.

Замовте налаштування Lighthouse Accessibility — за 2 дні отримайте автоматичний контроль доступності. Зв'яжіться з нами, щоб оцінити ваш проєкт.

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

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

У цій картці — як ми робимо веб-доступність 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 — відповідно до складності (від невеликих до значних сум). Впровадження 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 або на пошту — відповімо протягом години.