Аудит веб-доступності: перевірка сайту на WCAG 2.1 AA

Типова ситуація: після запуску сайту виявляється, що 20% користувачів не можуть оформити замовлення через відсутність alt-текстів та неправильного фокусування. Або приходить припис від регулятора — забезпечити доступність згідно з WCAG 2.1 AA. Ми проводимо аудит доступності сайту: автоматизоване та ручне тестування, детальний звіт та план усунення порушень.

WCAG 2.1 AA — міжнародний стандарт, обов'язковий для держсайтів у ЄС (EN 301 549) та США (Section 508). Рівень AA включає 50+ критеріїв, що охоплюють сприйняття, керованість, зрозумілість та надійність. Наш досвід показує: ручне тестування виявляє в 2 рази більше проблем, ніж автоматичні інструменти, тому ми використовуємо обидва підходи.

Що таке WCAG 2.1 AA?

WCAG 2.1 AA — міжнародний стандарт веб-доступності, що включає 50+ критеріїв успіху. Рівень AA обов'язковий для державних сайтів у ЄС та США. Він охоплює сприйнятливість, керованість, зрозумілість та надійність інтерфейсу.

Які інструменти використовуються для аудиту?

Ми комбінуємо автоматизовані інструменти (axe DevTools, Lighthouse, Pa11y) та ручне тестування. Автоматика знаходить ~30% проблем, ручне тестування — 60-70% (навігація з клавіатури, screen reader, тести масштабування).

Скільки часу займає аудит?

Термін залежить від обсягу сайту: лендинг (5-10 сторінок) — 2-3 дні, корпоративний сайт (20-50 сторінок) — 4-7 днів, SaaS або веб-застосунок — 7-14 днів. Виправлення за результатами займає в 1.5 рази довше.

Що входить у звіт?

Звіт містить перелік порушень із зазначенням критерію WCAG, пріоритету (критичний, значний, попередження), скріншоти та рекомендації щодо виправлення. Також додається план усунення з оцінкою трудозатрат.

Як виправити порушення?

Ми надаємо детальний план із технічними рекомендаціями для кожного порушення. За бажанням можемо взяти виправлення на себе — від додавання alt-текстів до рефакторингу компонентів. Ціна розраховується індивідуально.

Для чого потрібен аудит доступності сайту?

Юридичні вимоги — не єдина причина. Доступний сайт охоплює аудиторію з обмеженими можливостями (близько 15% населення). Це покращує SEO: пошукові системи враховують семантику page structure та alt-тексти. Крім того, це доказ compliance при перевірках.

Які проблеми ми вирішуємо?

• Недостатня контрастність тексту (SC 1.4.3) — сірий текст на білому фоні часто нижче 4.5:1. Помилка типова для кнопок та підказок.
• Відсутність alt у зображень — особливо на сторінках продуктів, де screen reader не може передати візуальну інформацію.
• Кастомні UI-компоненти (селекти, слайдери) без підтримки клавіатури та ARIA-атрибутів. Наприклад, datepicker без ARIA label або неправильного role.
• Форми з placeholder замість label — screen reader не ідентифікує поля, а текст зникає при вводі.
• Порядок фокусу (Focus Order) не відповідає візуальному потоку — користувач губиться при табуляції.

Ось реальний кейс: на лендингу фінтех-стартапу кастомний випадаючий список не виводив опції при кліку, якщо використовуються клавіші. Наш аудит показав відсутність aria-expanded та обробників keydown. Виправлення зайняло 2 години, але до цього 30% користувачів з моторними порушеннями не могли вибрати тариф.

Інструментарій аудиту

Автоматичні інструменти (знаходять ~30% проблем):

// axe DevTools — розширення Chrome/Firefox
// Запустити на кожній сторінці: F12 → Accessibility

// axe-core через Playwright
npm install -D @axe-core/playwright

// audit.spec.ts
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

const pagesToAudit = [
    '/', '/about', '/contact', '/login', '/dashboard'
];

for (const path of pagesToAudit) {
    test(`${path} has no WCAG 2.1 AA violations`, async ({ page }) => {
        await page.goto(`/`); // тестування на локальному або власному домені

        const results = await new AxeBuilder({ page })
            .withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
            .analyze();

        expect(results.violations).toEqual([]);
    });
}

# WAVE
https://wave.webaim.org/

# Pa11y
pa11y --standard WCAG2AA [URL вашого сайту] --reporter html > report.html

# Lighthouse
lighthouse [URL вашого сайту] --only-categories=accessibility --output html

Ручне тестування (60-70% проблем):

• Навігація тільки з клавіатури — пройти весь user flow
• Перевірка з NVDA + Chrome / JAWS + IE / VoiceOver + Safari
• Тест зі збільшенням 200% та 400% (SC 1.4.10 Reflow)
• Тест у режимі високого контрасту Windows
• Вимкнути CSS — структура повинна залишатися осмисленою

Чому ручне тестування незамінне?

Автоматика знаходить синтаксичні помилки: відсутність alt, низьку контрастність, пропущені roles. Але вона не здатна оцінити, наскільки осмислений порядок табуляції або коректно чи оголошуються динамічні зміни. Наприклад, при відкритті модального вікна screen reader повинен почути його заголовок, а після закриття — повернутися до початкового елемента. Це перевіряється тільки вручну.

Порівняння автоматичного та ручного тестування

Комбінація обох підходів дає максимальну повноту. Ручне тестування виявляє в 2 рази більше проблем, ніж автоматичне, особливо в сценаріях з динамічним контентом.

Що входить в аудит?

• Повний звіт з переліком порушень за кожним критерієм WCAG 2.1 AA
• Пріоритизація (Critical, Major, Minor) з поясненням впливу
• Скріншоти та HTML-шляхи до проблемних елементів
• Рекомендації щодо виправлення з прикладами коду
• План усунення з оцінкою трудозатрат
• Консультація за результатами (1 година онлайн)

Вартість аудиту залежить від обсягу: лендинг — від 500 до 1500 доларів, корпоративний сайт — від 1500 до 5000 доларів, веб-застосунок — від 5000 доларів. Точна вартість визначається після попереднього аналізу.

Типові знахідки на українських сайтах

• Відсутність lang атрибута на HTML-елементі
• Погана контрастність сірого тексту на білому фоні
• Кастомні селекти та дропдауни без keyboard support
• Форми з placeholder замість label
• Слайдери та каруселі без кнопок керування
• Вимкнений zoom (maximum-scale=1)

Як швидко можна усунути порушення?

Терміни залежать від обсягу та складності. Прості виправлення (додавання alt, виправлення контрасту) виконуються за день. Глибока переробка компонентів з переписуванням ARIA-атрибутів може зайняти кілька тижнів. Ми надаємо план із покроковими рекомендаціями та можемо взяти реалізацію на себе.

Термін проведення аудиту

Наші інженери — сертифіковані експерти з досвідом понад 5 років у веб-доступності. Ми гарантуємо якісний аудит доступності сайту та надаємо звіт з чіткими рекомендаціями. Замовте аудит доступності вашого сайту — оцінимо масштаб робіт за 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.

<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 або на пошту — відповімо протягом години.