How to Test Website Accessibility: Step-by-Step Guide 2026

Тестування доступності — це не разова галочка перед запуском. Це систематичний процес, який захищає ваших користувачів від бар'єрів і ваш бізнес від судових позовів. Але з чого почати? Існують три основних підходи: автоматичне тестування інструментами, ручне тестування клавіатурою та тестування зі скрін-рідером. Жоден із них окремо не дає повної картини — потрібна комбінація всіх трьох.

У цьому гайді ми пройдемося по кожному кроку детально — від запуску Lighthouse до тестування з NVDA — і покажемо, що автоматика просто не може знайти.

Крок 1 — Автоматичне тестування

Автоматичні інструменти — найшвидший спосіб знайти очевидні технічні помилки: відсутні alt-тексти, неконтрастні кольори, поля форм без міток. Запускайте їх регулярно — в ідеалі, в CI/CD-пайплайні при кожному коміті.

Google Lighthouse

Lighthouse — вбудований аудитор у Chrome DevTools. Відкрийте DevTools (F12), перейдіть на вкладку Lighthouse, оберіть категорію "Accessibility" і натисніть "Analyze page load". Через 15–30 секунд отримаєте оцінку від 0 до 100 і список конкретних порушень.

Що показує: перевіряє понад 30 правил доступності на основі axe-core — контраст тексту, alt-тексти, aria-атрибути, структуру заголовків, доступність форм.

Обмеження: тестує лише поточний стан завантаженої сторінки. Не перевіряє динамічну поведінку (відкриття модальних вікон, оновлення через AJAX), не тестує взаємодію з клавіатурою і не замінює тестування зі скрін-рідером. Оцінка 100/100 не означає повну доступність.

WAVE (WebAIM)

WAVE — браузерне розширення від WebAIM для Chrome та Firefox. Після встановлення натисніть іконку WAVE на будь-якій сторінці, і побачите накладені прямо на сторінку іконки помилок, попереджень і структурних елементів.

Що тестує: структуру заголовків, landmark-регіони, мітки форм, alt-тексти, контраст кольорів, ARIA-розмітку. Особливо зручний для візуальної оцінки — одразу видно, де і яка проблема на сторінці.

axe DevTools

axe DevTools — розширення від Deque, доступне як безкоштовна версія для Chrome. Це найпотужніший автоматичний сканер: перевіряє відповідність WCAG 2.1 рівнів A та AA за більш ніж 50 правилами.

Що перевіряє: порушення, що гарантовано є проблемами доступності (без false positives), а також "найкращі практики". Безкоштовна версія дає детальний перелік з посиланнями на документацію. Платна версія додає guided testing для ручної перевірки.

InclusiveWeb Audit

Якщо вам потрібен комплексний автоматичний аудит без налаштування DevTools — InclusiveWeb Audit перевіряє ваш сайт за 90+ правилами WCAG 2.1 і видає пріоритезований звіт з конкретними рекомендаціями. Підходить для команд, яким потрібен регулярний моніторинг або підготовка до аудиту відповідності.

Крок 2 — Ручне тестування клавіатурою

Мільйони людей користуються вебом лише за допомогою клавіатури — через рухові порушення, тремор, паралічі, або просто тому що так швидше. Тестування клавіатурою займає 15–30 хвилин, але виявляє критичні бар'єри, які автоматика пропускає.

Основні клавіші:

• Tab — переміщення вперед між інтерактивними елементами
• Shift + Tab — переміщення назад
• Enter — активація посилань і кнопок
• Space — активація кнопок, чекбоксів; прокрутка сторінки
• Escape — закриття модальних вікон, дропдаунів, скасування
• ↑ ↓ ← → — навігація в меню, слайдерах, табах, радіогрупах

Що перевіряти під час тестування клавіатурою:

1. 1Видимість фокуса. На кожному елементі при навігації Tab має бути видиме виділення (outline). Якщо не видно, де знаходиться фокус — це критична проблема.
2. 2Логічний порядок фокуса. Tab повинен переміщуватись у природному порядку читання — зліва направо, зверху вниз. Стрибки "в нікуди" свідчать про проблеми з tabindex або DOM-порядком.
3. 3Пастки клавіатури. Перевірте, чи можна вийти з будь-якого компонента (модального вікна, дропдауну) за допомогою Escape або Tab. Якщо фокус "застряє" — це пастка клавіатури.
4. 4Skip-посилання. Натисніть Tab одразу після завантаження сторінки. Чи є посилання "Перейти до основного контенту"? Воно має з'являтися і вести до main-блоку.
5. 5Інтерактивні елементи керуються з клавіатури. Дропдауни, табби, акордеони, модальні вікна — всі вони мають власні ARIA-патерни взаємодії з клавіатурою.
6. 6Форми повністю заповнюються без миші. Пройдіться по кожній формі тільки Tab/Enter/Space і переконайтесь, що форму можна відправити без миші.
7. 7Після закриття модального вікна фокус повертається. Якщо відкрили модальне вікно і закрили його, фокус має повернутись на елемент, який ініціював відкриття.
8. 8Немає елементів з tabindex більше 0. tabindex="1" або вище порушує природний порядок фокуса і майже завжди є помилкою. Допустимі значення: 0 (включити в потік) і -1 (виключити).

Крок 3 — Тестування зі скрін-рідером

Скрін-рідери перетворюють контент сторінки на мовлення або шрифт Брайля. Тестування з ними дозволяє зрозуміти, що саме чують незрячі користувачі — і це часто разюче відрізняється від того, що ви бачите на екрані.

NVDA (Windows, безкоштовний)

NVDA (NonVisual Desktop Access) — найпоширеніший безкоштовний скрін-рідер для Windows. Встановлення займає 5 хвилин.

Основні команди в браузері:

• H / Shift+H — переміщення між заголовками вперед/назад
• D — переміщення між landmark-регіонами (main, nav, header)
• F — переміщення між полями форм
• K — переміщення між посиланнями
• Insert+F7 — список усіх посилань або заголовків на сторінці

VoiceOver (macOS / iOS)

VoiceOver вбудований у macOS і iOS — окремого встановлення не потрібно.

• macOS: увімкнути через Cmd+F5 або Системні налаштування → Доступність → VoiceOver
• iOS: Налаштування → Доступність → VoiceOver → увімкнути
• Основна клавіша модифікатора: VO = Ctrl+Option. Навігація: VO+→ і VO+←.

TalkBack (Android)

TalkBack — вбудований скрін-рідер Android. Активація: Налаштування → Спеціальні можливості → TalkBack → увімкнути. Навігація жестами: свайп вправо — наступний елемент, подвійний тап — активація.

Що перевіряти зі скрін-рідером:

• Навігація по заголовках. Натискаючи H в NVDA, чи охоплює структура заголовків весь ключовий контент? Чи відповідає ієрархія (h1 → h2 → h3)?
• Landmark-навігація. Чи є на сторінці landmarks: banner, main, navigation, contentinfo? Без них скрін-рідер не може швидко перейти до потрібної секції.
• Мітки форм. Прослухайте кожне поле — чи озвучує скрін-рідер назву поля і тип введення? "Прізвище, редагувати текст" — правильно. "Редагувати текст" — помилка.
• Alt-текст зображень. Чи прослуховується інформативний опис для зображень? Декоративні зображення мають alt="" і не читаються скрін-рідером.

Крок 4 — Тестування контрасту

WCAG 2.1 вимагає мінімальний коефіцієнт контрасту 4.5:1 для звичайного тексту і 3:1 для великого тексту (18pt+ або 14pt+ жирний). Порушення контрасту — одна з найпоширеніших помилок на сайтах.

Інструменти для перевірки:

• Colour Contrast Analyser від TPGi — безкоштовний десктоп-інструмент для Windows і macOS. Дозволяє взяти піпеткою будь-який колір з екрана і одразу побачити співвідношення.
• Chrome DevTools. У вкладці Elements при наведенні на колір тексту показує коефіцієнт контрасту з фоном і позначає, чи відповідає він AA/AAA.
• WAVE розширення позначає елементи з недостатнім контрастом прямо на сторінці.

Що автоматика не бачить

Пам'ятайте: 30–57% проблем з доступності виявляються лише вручну. Ось конкретні речі, які автоматичні інструменти не можуть перевірити:

1. 1Якість alt-тексту. Автоматика перевіряє, що alt-атрибут є. Але чи описує він зображення значущо? Чи відповідає контексту? Це може оцінити тільки людина.
2. 2Логічний порядок фокуса. Tab-послідовність технічно може бути правильною, але логічно нераціональною — це оцінюється лише при ручному тестуванні.
3. 3Корисність міток форм. <label> може бути технічно пов'язаний, але мати текст "Поле 1" замість "Прізвище".
4. 4Зрозумілість повідомлень про помилки. Технічно форма може мати aria-invalid і aria-describedby, але текст помилки — незрозумілий жаргон.
5. 5Пастки клавіатури в динамічних компонентах. Поки компонент не відкрито — пастки немає. Автоматика перевіряє поточний стан DOM.
6. 6Відповідне управління фокусом. Чи повертається фокус після закриття модального вікна? Чи переміщується до першої помилки після відправки форми?
7. 7Тайм-аути та рухомий контент. Чи є попередження перед закінченням сесії? Чи можна зупинити автоматично прокручуваний банер?
8. 8Читання зі скрін-рідером у "реальному" сценарії. Як звучить заповнення форми від початку до кінця? Чи зрозуміло озвучується кожен крок процесу оплати?
9. 9Когнітивна доступність. Чи достатньо зрозуміла мова? Чи не перевантажена сторінка відволікаючими елементами? Чи є достатньо часу для виконання завдань?
10. 10Доступність PDF та інших документів. Автоматичні сканери сайту, як правило, не перевіряють завантажувані документи — а вони також повинні бути доступними.

Автоматизований аудит з InclusiveWeb

InclusiveWeb Audit — це платформа для регулярного автоматичного моніторингу доступності вашого сайту. На відміну від разового запуску Lighthouse, InclusiveWeb:

• Перевіряє 90+ правил WCAG 2.1 рівнів A та AA
• Сканує декілька сторінок сайту, включаючи динамічні стани
• Дає пріоритезований звіт — від критичних порушень до покращень рівня AA
• Надає конкретні рекомендації з кодом для кожного типу проблеми
• Відстежує динаміку покращень при повторних аудитах

Це ідеальний перший крок: отримайте повну картину проблем за 5 хвилин, а потім приступайте до ручного тестування пріоритетних сторінок.