Тестування доступності у 2026 році: WCAG 2.2, чек-лист і інструменти для тестувальника

Доступність (accessibility, скорочено a11y) означає, що сайтом чи застосунком можуть користуватися всі. Це незрячі люди з екранним читачем і люди зі слабким зором, які збільшують текст. Це люди з порушеннями кольорового зору, ті, хто керує комп'ютером лише клавіатурою чи голосом, люди з дислексією чи порушеннями слуху. А ще кожен, хто тримає телефон однією рукою на яскравому сонці.

Тестування доступності перевіряє, чи не залишили ми когось із них за дверима: чи можна дістатися до кнопки без мишки, чи озвучить екранний читач поле форми, чи видно сірий текст на білому фоні. Для бізнесу це ще й вимога закону: з 28 червня 2025 року в ЄС діє Європейський акт про доступність (EAA), який поширюється й на українські компанії, що продають свої послуги в ЄС.

Короткий вибір

Стандарти: WCAG 2.2, EAA і що з цим робити

WCAG (Web Content Accessibility Guidelines) — міжнародні настанови W3C, на які посилаються майже всі закони про цифрову доступність. Чинна версія — WCAG 2.2 (жовтень 2023 року). Вона стала й стандартом ISO/IEC 40500:2025. Вимоги згруповано за чотирма принципами, POUR:

• Сприйнятність (Perceivable). Інформацію можна сприйняти: зображення мають текстову альтернативу, відео — субтитри, контраст достатній.
• Керованість (Operable). Усім можна керувати з клавіатури, вистачає часу, нічого не блимає небезпечно.
• Зрозумілість (Understandable). Текст зрозумілий, інтерфейс передбачуваний, помилки у формах пояснено.
• Надійність (Robust). Розмітка коректна, і допоміжні технології, як-от екранні читачі, правильно її розуміють.

Кожна вимога має рівень A, AA або AAA. Закони й договори зазвичай вимагають рівня AA: саме його й варто брати за ціль тестування.

Що нового у WCAG 2.2:

• видимий фокус не можна повністю ховати під липкими шапками чи банерами;
• кліковий елемент має бути розміром щонайменше 24×24 CSS-пікселі або мати достатній відступ від сусідніх;
• для перетягування мишкою потрібна альтернатива простим кліком;
• довідка має бути в одному й тому самому місці на всіх сторінках;
• не можна змушувати повторно вводити вже введені дані;
• вхід не може вимагати лише запам'ятовування чи розгадування головоломки, тож не можна, наприклад, забороняти вставляти пароль.

Застарілий критерій 4.1.1 «Парсинг» з 2.2 вилучено.

WCAG 3.0 поки що лише робочий проєкт W3C, і він не замінює 2.2. Стежити за ним варто, а тестувати й надалі за 2.2.

Європейський акт про доступність (EAA) з 28 червня 2025 року вимагає доступності від інтернет-магазинів, банківських послуг, електронних книжок, квитків і сервісів пасажирського транспорту, телекомунікацій тощо. На практиці це означає відповідність гармонізованому стандарту EN 301 549, який для вебу спирається на WCAG AA. Мікропідприємства, що надають послуги, звільнені від вимог.

В Україні чинний ДСТУ EN 301 549:2022, ідентичний європейському стандарту, а Мінцифри разом із ПРООН щороку перевіряють доступність державних сайтів за критеріями WCAG 2.1 AA.

Чек-лист ручного тестування

Цей мінімум під силу будь-якому тестувальнику за 15–30 хвилин на сторінку.

Клавіатура

• Пройдіть сторінку клавішею Tab від початку до кінця. Чи можна дістатися до кожного посилання, кнопки й поля? Чи логічний порядок?
• Чи завжди видно, де зараз фокус? Чи не ховається він під шапкою (WCAG 2.2)?
• Чи відкриваються меню, вкладки, модальні вікна клавішами Enter і пробіл, чи закриваються клавішею Esc? Чи повертається фокус на місце після закриття вікна?
• Чи немає «пасток», з яких фокус не виходить?
• Чи є посилання «Перейти до основного вмісту» на початку сторінки?

Структура й семантика

• Чи є один заголовок H1, а решта заголовків ідуть за ієрархією без пропусків рівнів? Це допомагає перевірити ANDI чи Accessibility Insights.
• Чи мають зображення змістовний alt, а декоративні — порожній alt?
• Чи зрозумілі назви посилань без контексту («Детальніше» ×10 — погано)?
• Чи вказано мову сторінки (lang="uk")?

Форми

• Чи має кожне поле видимий підпис, пов'язаний із ним у коді, а не лише плейсхолдер?
• Чи пояснено помилки текстом, а не тільки червоним кольором? Чи зачитує їх екранний читач?
• Чи можна вставити пароль і код з SMS?

Колір і контраст

• Звичайний текст має контраст щонайменше 4,5:1, великий текст — 3:1, рамки полів, іконки й фокус — 3:1. Перевіряйте піпеткою Colour Contrast Analyser.
• Чи не передано інформацію лише кольором, наприклад «обов'язкові поля позначено червоним»? Подивіться сторінку крізь Color Oracle.

Масштаб і адаптивність

• Збільште масштаб браузера до 200 % і 400 % (ширина 320 px). Чи не обрізано текст, чи не з'явилась горизонтальна прокрутка?
• Чи не ламається верстка при збільшенні міжрядкового інтервалу й відступів?

Медіа й рух

• Чи мають відео субтитри, а аудіо — текстову розшифровку?
• Чи не запускається звук автоматично? Чи можна зупинити каруселі й анімації? Чи враховано налаштування «зменшити рух»?

Динамічний вміст

• Чи озвучуються повідомлення, що з'являються без перезавантаження: «Товар додано до кошика», помилки, сповіщення?

Екранні читачі: як тестувати

Перевірка з екранним читачем — найцінніший і найнезвичніший для новачка тест. Почніть з одного читача на своїй платформі:

• Windows: NVDA. Безкоштовний, з відкритим кодом і дуже поширений серед незрячих користувачів. Платний JAWS досі популярний у корпоративному середовищі. Вбудований Windows Narrator підходить для швидкої перевірки.
• macOS, iPhone, iPad: VoiceOver, вбудований, вмикається в налаштуваннях доступності.
• Android: TalkBack, вбудований.
• Linux: Orca.

Що перевіряти:

• Чи можна пройти сторінку за заголовками (у NVDA — клавіша H) і орієнтирами (landmarks)?
• Чи зрозуміло озвучуються кнопки й поля? «Кнопка, кнопка, кнопка» без назв — класичний дефект іконок без підпису.
• Чи оголошено стани: розгорнуто/згорнуто, вибрано, вимкнено?
• Чи можна пройти головний сценарій, наприклад реєстрацію чи покупку, не дивлячись на екран?

Порада: перші разів п'ять пройдіть з читачем сайт, який точно доступний, щоб навчитися керувати ним. Тоді, тестуючи свій продукт, ви відрізнятимете дефект продукту від власної незграбності.

Найкращий тест — участь самих людей з інвалідністю. Платформа Fable організовує юзабіліті-тестування з користувачами допоміжних технологій.

Автоматичні перевірки в браузері

Розширення знаходять технічні порушення за секунди. Запускайте їх на кожній новій сторінці:

• axe DevTools від Deque — безкоштовне розширення на рушії axe-core, відоме тим, що дає мало хибних спрацювань. Платна версія додає керовані тести й звіти.
• WAVE від WebAIM показує піктограми помилок просто поверх сторінки. Це наочно й зручно для дизайнерів і менеджерів.
• Accessibility Insights від Microsoft поєднує швидкий FastPass із покроковою оцінкою на відповідність WCAG 2.1 AA, зокрема з ручними тестами.
• Lighthouse, вбудований у Chrome DevTools, рахує бал доступності на основі axe-core. Це зручний орієнтир, але 100 балів ще не означають, що сайт доступний.
• ARC Toolkit від TPGi і IBM Equal Access Accessibility Checker — сильні безкоштовні альтернативи. ARC окремо показує порядок табуляції.
• Sa11y призначений для редакторів контенту: підсвічує порожні заголовки, відсутній alt і погані посилання прямо в CMS.
• Polypane — браузер для розробників, який вміє симулювати порушення зору й показує дерево доступності.

Перевіряйте не лише початковий стан сторінки, а й відкриті меню, модальні вікна та стани помилок у формах.

Доступність в автотестах і CI

Щоб доступність не ламалася з кожним релізом, додайте автоматичні перевірки в тести:

• axe-core — основа більшості інтеграцій: @axe-core/playwright для Playwright, cypress-axe для Cypress, @axe-core/webdriverjs для Selenium, jest-axe для Jest. Достатньо одного рядка в наявному e2e-тесті, щоб перевірити сторінку.
• Pa11y — Pa11y CI проходить списком адрес і падає, якщо знайде помилки. Pa11y Dashboard показує динаміку.
• Lighthouse CI дозволяє встановити мінімальний бал доступності для кожного pull request.
• IBM Equal Access Accessibility Checker має пакети для Node і Cypress.
• eslint-plugin-jsx-a11y ловить помилки в коді React ще до запуску: img без alt, div з onClick без ролі, неправильні ARIA.
• Storybook з аддоном доступності перевіряє кожен компонент дизайн-системи окремо.

Запускайте все це в GitHub Actions чи іншому CI. Почніть з режиму «лише попереджати», а коли виправите наявні помилки, перемкніть на «падати при нових».

Про налаштування автотестів читайте в статті «Інструменти для автоматизації тестування».

Мобільні застосунки

У мобільних застосунках ті самі принципи, але свої інструменти:

• Android. Accessibility Scanner сканує екран і показує замалі зони дотику, відсутні підписи й слабкий контраст. Android Studio має перевірки доступності в редакторі макетів і lint. Espresso вміє вмикати перевірки доступності прямо в UI-тестах.
• iOS. Accessibility Inspector у складі Xcode показує підписи й ролі елементів і запускає аудит. XCUITest має автоматичний аудит доступності для UI-тестів.
• Вручну. TalkBack і VoiceOver, збільшений шрифт у системі (Dynamic Type на iOS), темна тема, керування перемикачами чи голосом, наприклад Voice Access.

Зони дотику мають бути не менш як 48×48 dp на Android і 44×44 pt на iOS (рекомендації Google і Apple). Детальніше про мобільне тестування — у статті «Тестування мобільних застосунків».

Документи, дизайн і контент

• PDF. PAC PDF Accessibility Checker безкоштовно перевіряє PDF за стандартами PDF/UA і WCAG і показує, що зачитає екранний читач. У Microsoft Office є вбудована «Перевірка доступності».
• Дизайн. Плагін Stark для Figma перевіряє контраст і симулює дальтонізм ще в макеті. Виправити дефект там найдешевше.
• Текст. Простий і зрозумілий текст — теж доступність, особливо для людей з когнітивними порушеннями й дислексією. Допомагає Hemingway Editor.

Віджети-оверлеї: чому вони не замінюють тестування

Сервіси-«оверлеї» обіцяють зробити сайт доступним одним рядком коду: додають кнопку з налаштуваннями шрифту й контрасту та «автоматично виправляють» помилки. Проблема в тому, що вони не змінюють сам код сайту. Багато незрячих користувачів і експертів з доступності скаржаться, що такі віджети заважають екранним читачам. У 2025 році Федеральна торгова комісія США зобов'язала accessiBe сплатити 1 млн доларів за оманливі заяви, ніби її віджет робить будь-який сайт відповідним WCAG.

Висновок для тестувальника: якщо на сайті є оверлей, тестуйте сайт так само, як без нього. Дефекти виправляють у коді. Такі сервіси є в каталозі в підкатегорії Цифрова доступність для бізнесу, разом із платформами для аудиту й моніторингу.

Як звітувати про дефекти доступності

Добрий баг-репорт з доступності містить:

• критерій WCAG, наприклад «1.4.3 Контраст (мінімальний), AA»;
• хто постраждає: «користувачі NVDA не дізнаються, що кнопка відкриває меню»;
• кроки відтворення з указаним інструментом (браузер, читач, версія);
• очікуваний результат, бажано з підказкою, як виправити: «додати aria-expanded» чи «збільшити контраст до 4,5:1».

Пріоритет визначайте за впливом. Якщо оформити замовлення неможливо без мишки, це блокер. Якщо в декоративної картинки є зайвий alt, це дрібниця.

План навчання на місяць

1. Тиждень 1. Прочитайте короткий огляд WCAG на сайті W3C WAI. Встановіть axe DevTools і WAVE, перевірте 5 улюблених сайтів.

2. Тиждень 2. Клавіатура й контраст: пройдіть чек-лист вище на своєму проєкті. Навчіться користуватися Colour Contrast Analyser.

3. Тиждень 3. Екранний читач: щодня по 20 хвилин з NVDA або VoiceOver. Спершу на доступних сайтах, потім на своєму.

4. Тиждень 4. Автоматизація: додайте axe-core у наявні e2e-тести або Pa11y CI у конвеєр. Оформіть знайдені дефекти за шаблоном вище.

Після цього можна готуватися до сертифікацій IAAP (CPACC, WAS), якщо доступність стане вашою спеціалізацією.

АІ в тестуванні доступності

АІ вже допомагає у кількох місцях:

• генерує чернетки альтернативного тексту для зображень;
• пояснює помилки, знайдені сканером, і пропонує виправлення коду;
• у PAC 2026 і деяких корпоративних платформах автоматизує частину ручних перевірок.

Асистенти на кшталт ChatGPT, Claude чи GitHub Copilot допоможуть швидко розібратися в критерії WCAG або атрибутах ARIA. Однак АІ не знає, що саме має повідомити зображення у вашому контексті, і не відчуває, як незручно проходити форму з екранним читачем. Остаточне рішення ухвалює людина, а найкраще — люди з інвалідністю.

Для самих користувачів з інвалідністю АІ-інструменти, як-от Be My Eyes, вже змінюють щоденне життя. Їх зібрано в категорії «Доступність», наприклад у підкатегорії Для незрячих і слабозорих.

Про інші види тестування читайте в статтях «Інструменти для мануального тестування», «Тестування API» та «Тестування безпеки». Усі інструменти з цієї статті є в підкатегоріях Тестування і Цифрова доступність для бізнесу.

Часті запитання

Чи достатньо автоматичної перевірки?

Ні. Сканери знаходять технічні помилки: контраст, відсутній alt, порожні кнопки. Але вони не оцінять, чи змістовний alt, чи логічний порядок фокуса, чи зрозуміле повідомлення про помилку. Потрібні й ручні перевірки.

З якого екранного читача почати?

З NVDA на Windows або VoiceOver на Mac чи iPhone. Обидва безкоштовні й поширені серед реальних користувачів.

Який рівень WCAG тестувати?

AA. Його вимагають EAA, EN 301 549 і більшість договорів. Рівень AAA цілком для всього сайту зазвичай недосяжний.

Чи стосується EAA українських компаній?

Так, якщо вони надають підпадаючі під акт послуги чи продукти споживачам в ЄС, наприклад інтернет-магазин із доставкою до ЄС. Для юридичних висновків зверніться до юриста.

Чи можна зробити сайт доступним віджетом?

Ні. Віджет не виправляє код сайту. Тестуйте й виправляйте сам продукт.

Не знаєте, з чого почати?

Запитайте Елю: вона підбере інструменти тестування доступності під ваш проєкт і рівень.

Дата перевірки фактів: 4 листопада 2026 року. Умови сервісів і вимоги законодавства можуть змінюватися, тож перевіряйте їх на офіційних сайтах.