Доступність сайтів: 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 (реєстрація, покупка, форма) тільки клавіатурою та зі скрінридером.
Процес роботи
- Автоматичний аудит — axe-core, Lighthouse, WAVE — видача 80+ правил.
- Ручне тестування — NVDA, VoiceOver, клавіатура — 2–3 дні на типовий сайт.
- Пріоритизація порушень — P1 (блокує використання), P2 (створює складності), P3 (покращення).
- Виправлення — ітераціями, вбудовуємо перевірки в CI через Playwright + axe.
- Повторний аудит — закриття всіх P1/P2 перед релізом.
- Документація та передача — звіт з результатами, рекомендації по підтримці, навчання команди.
Результати та обсяг робіт
- Повний звіт по аудиту з пріоритизацією порушень (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 за версією 2.2.
Замовте аудит зараз — отримайте чек-лист та попередню оцінку безкоштовно. Пишіть в Telegram або на пошту — відповімо протягом години.