Аудит доступності сайту за WCAG: перевірка, звіт, рекомендації

Користувач із порушенням зору не може заповнити форму на вашому сайті — кнопка відправлення недоступна з клавіатури, а програма екранного читання (скринрідер) не озвучує помилки. За статистикою WebAIM Million Report, 96% із мільйона домашніх сторінок містять помилки WCAG. Ми проводимо аудит доступності сайту, який виявляє такі бар'єри та дає точні інструкції щодо їх усунення, щоб ваш сайт відповідав стандарту WCAG 2.2 рівня AA. Аудит доступності сайту допомагає уникнути юридичних ризиків: штрафи за недоступність у США сягають $50 000 за перше порушення, а в Європі — до €75 000 за GDPR (для держсайтів). Економія на доопрацюваннях після своєчасного аудиту може становити до $10 000.

Аудит доступності сайту — це не разова перевірка, а вбудовування культури інклюзивності в процес розробки. Комбінований метод (автоматизоване + ручне) виявляє в 2.5 рази більше помилок, ніж самотужки автоматизоване. Своєчасний аудит дозволяє уникнути судових витрат і підвищити лояльність користувачів.

Чому WCAG AA — не просто галочка?

Державні сайти в багатьох країнах зобов'язані дотримуватися WCAG AA. Комерційні проекти слідують йому де-факто: це знижує юридичні ризики та розширює аудиторію на 15–20%. Поточна версія стандарту — WCAG 2.2 — включає нові критерії успішності: фокус-індикація (2.4.13), цільовий розмір (2.5.8) та стійкість введення (2.5.7). Наш аудит покриває всі ці вимоги.

Як ми перевіряємо доступність: від автоматизації до ручного тестування

Автоматизоване сканування виявляє близько 30–40% порушень: відсутність alt-текстів, низький контраст, неправильну структуру заголовків, пропущені ARIA-атрибути. Використовуємо axe-core, Lighthouse та Pa11y.

# axe-core CLI
npm install -g @axe-core/cli
axe https://mysite.com --reporter=json > axe-report.json

Ручне тестування — обов'язковий етап. Перевіряємо навігацію з клавіатури, роботу зі скринрідерами (NVDA + Firefox, VoiceOver + Safari, TalkBack + Android). Модальні вікна, форми, кастомні компоненти — кожен інтерактивний елемент проходить 20+ тестів. Наприклад, при перевірці alt-текстів ми відзначаємо: <img src="banner.jpg" alt="Аудит доступності сайту: знижка 30%"> — коректний alt, а порожній alt на декоративному зображенні — помилка.

Фокус-пастки в модальних вікнах — одна з найчастіших помилок. Правильний код на React:

const Modal = ({ isOpen, onClose, children }) => {
  const modalRef = useRef(null);

  useEffect(() => {
    if (isOpen) {
      const previouslyFocused = document.activeElement;
      modalRef.current?.focus();
      return () => {
        previouslyFocused?.focus();
      };
    }
  }, [isOpen]);

  return (
    <div ref={modalRef} role="dialog" aria-modal="true" aria-labelledby="modal-title" tabIndex={-1}>
      {children}
    </div>
  );
};

Порівняння методів тестування

Що ми перевіряємо: ключові критерії WCAG AA

Як виправити типові помилки?

Іконка-кнопка без опису:

// ПОГАНО
<div onClick={handleDelete}><TrashIcon /></div>

// ДОБРЕ
<button onClick={handleDelete} aria-label="Видалити запис"><TrashIcon aria-hidden="true" /></button>

Посилання пропуску навігації:

<a href="#main-content" class="skip-link">Перейти до основного вмісту</a>
<style>
.skip-link { position: absolute; left: -9999px; }
.skip-link:focus { left: 0; top: 0; z-index: 9999; }
</style>

Структура звіту

• Повний список порушень із прив'язкою до критеріїв WCAG (критичні, серйозні, помірні).
• Скріншоти та HTML-селектори кожного проблемного елемента.
• Рекомендації щодо виправлення з готовими прикладами коду.
• Чек-лист ручної перевірки для розробників.
• Інтеграційні рекомендації для CI/CD (Playwright, axe).

Приклад запису:

• Порушення: Відсутність alt-тексту на зображенні (1.1.1).
• Селектор: #main img.banner.
• Пріоритет: Критичний.
• Рекомендація: Додати alt="Банер: знижка 30% на зимову колекцію".

Що входить у процес аудиту?

1. Аналітика — визначаємо ключові сторінки та сценарії (до 20 сторінок за 1 день).
2. Автоматизація — прогін axe/Pa11y, збір 30–40% помилок (1 година).
3. Ручне тестування — клавіатура, скринрідери, логічний порядок (1–2 дні).
4. Звіт — структурований список з пріоритетами.
5. Рекомендації — готові виправлення з кодом (2–3 дні).

Терміни та вартість

Аудит доступності сайту до 20 сторінок займає 2–3 робочих дні. Вартість аудиту під ключ розраховується індивідуально — напишіть нам для оцінки вашого проекту. Зв'яжіться з нами для консультації.

Наш досвід: 5+ років у веб-доступності, 100+ перевірених проектів для банків, держорганів та e-commerce. Гарантуємо відповідність WCAG AA.

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