Автоматизація перевірок доступності в 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 стає єдиним способом уникнути дискримінації та юридичних ризиків. Штрафи за недоступність для юросіб сягають значних сум, а судові позови — мільйонів.

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