WCAG

Чому автоматичне тестування знаходить тільки 30-57% проблем

Пояснюємо обмеження automated accessibility testing: що Lighthouse і axe не бачать, чому потрібне ручне тестування і як поєднати обидва підходи.

Андрій Вдовин

5 лютого 2026 р.

9 хв читання

«30–57%» — це не маркетинговий слоган, а число, яке змінює розуміння автоматизованого тестування доступності. Саме стільки WCAG-проблем може виявити автоматика в найкращому разі. Це підтверджено незалежними дослідженнями Deque та UK Government Digital Service (GDS). Це означає, що від 43% до 70% реальних проблем залишаться непоміченими, якщо покластися виключно на автоматичні інструменти.

Але це не означає, що автоматику не варто використовувати — навпаки. Розуміння її обмежень допомагає правильно збудувати процес тестування: автоматика як перший рубіж, ручне тестування та тестування з реальними користувачами — як другий і третій.

До 70%

WCAG-проблем не виявляються жодним автоматичним інструментом. Їх можна знайти лише через ручне тестування або тестування з реальними користувачами.

Джерело: Deque Research, UK Government Digital Service (GDS)

Чому автоматика обмежена

Автоматичне тестування доступності — це, по суті, перевірка коду за чіткими правилами: чи є атрибут, чи відповідає числове значення порогу, чи присутній елемент. Такі перевірки добре піддаються автоматизації.

Але значна частина WCAG-критеріїв вимагає смислового розуміння: чи є alt-текст не просто присутнім, а й осмисленим? Чи логічний порядок фокусу для даного сценарію? Чи зрозумілий контент людині з когнітивними порушеннями? Відповіді на ці питання не закодовані у HTML — вони в людській оцінці.

Технічна межа автоматики

Автоматичний інструмент може виявити, що зображення має alt="фото" — технічно атрибут є, помилки немає. Але людина одразу зрозуміє, що «фото» — марний опис, що не несе жодної інформації. Аналогічно: інструмент може перевірити, що кнопка має доступну назву, але не може оцінити, чи ця назва достатньо описова в контексті сторінки.

Інша принципова обмеженість: динамічна поведінка. Автоматичний скан зазвичай аналізує сторінку в момент завантаження. Але якщо modal відкривається після кліку, якщо AJAX підвантажує новий контент, якщо dropdown розгортається при наведенні — автоматика цього не побачить, якщо спеціально не налаштована на такі сценарії.

Що автоматика ВМІЄ виявляти

Попри обмеження, автоматика надзвичайно ефективна для певного класу проблем. Вона виявляє їх швидко, надійно і масштабовано — на всьому сайті за хвилини:

Відсутні або порожні alt-атрибути у зображень (технічна наявність, не якість)
Низький контраст кольорів тексту та фону (математичний розрахунок за формулою WCAG)
Відсутні <label> або aria-label для елементів форм
Відсутній атрибут lang на елементі <html>
Порожні посилання (<a href="#"></a>) або кнопки без доступного імені
Відсутній <title> сторінки або порожній title
Некоректне використання ARIA-ролей (наприклад, role="button" без tabindex)
Відсутні заголовки таблиць (<th>) або неправильний scope
Відсутній <main> landmark або дублювання landmark-елементів
Порушення ієрархії заголовків (пропуск рівнів H1 → H3 без H2)

Що автоматика НЕ БАЧИТЬ

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

Якість alt-тексту: «фото» або «зображення» технічно є alt, але описує нічого. Лише людина може оцінити, чи переданий зміст зображення
Логічний порядок фокусу: чи відповідає порядок Tab візуальному порядку контенту і сценарію використання? Автоматика бачить наявність tabindex, але не логіку
UX зі скрінрідером: чи зрозумілий сценарій роботи при озвучуванні? Чи коректно анонсуються зміни стану (aria-live)? Потребує реального тестування з NVDA/VoiceOver
Когнітивна складність: чи зрозумілий контент для людей з когнітивними порушеннями? Чи ясні інструкції? Чи помилки форм достатньо описові?
Сенс посилань у контексті: «Докладніше» — посилання є, назва є, але чи зрозуміло «докладніше про що»? Потребує оцінки контексту
Повідомлення про помилки у формах: технічно aria-describedby пов'язує помилку з полем, але чи описовий сам текст помилки? Чи зрозуміло, як її виправити?
Взаємодія зі складними компонентами: carousel, date picker, combobox — автоматика перевірить наявність ARIA-атрибутів, але не реальну клавіатурну взаємодію
Анімація та мерехтіння: чи не провокує анімація симптоми у людей з вестибулярними порушеннями або фотосенситивною епілепсією? Потребує візуальної оцінки
Мобільний touch UX: чи зручні touch targets на реальному пристрої? Чи не перекриваються елементи при збільшенні тексту на 200%?
Зміст відео/аудіо: автоматика не «дивиться» відео — наявність субтитрів можна перевірити, але їх точність і синхронізацію — ні

Різниця між інструментами

Не всі автоматичні інструменти однакові. Вони відрізняються кількістю правил перевірки, підходом до аналізу та охопленням WCAG-критеріїв:

Інструмент	Покриття WCAG	Тип	Ціна
Google Lighthouse	~20% WCAG-критеріїв	Browser DevTools / CLI	Безкоштовно
WAVE (WebAIM)	~30% WCAG-критеріїв	Browser Extension / Web	Безкоштовно
axe (Deque)	~40% WCAG-критеріїв	Browser Extension / API / CI	Core: безкоштовно; Pro: платно
IBM Equal Access	~40% WCAG-критеріїв	Browser Extension / Node	Безкоштовно (open source)
InclusiveWeb	90+ правил WCAG	SaaS / DNS-проксі / Script	Безкоштовний план + платні

Чому більше правил — це краще

Кількість правил перевірки напряму впливає на покриття. Lighthouse із 20-25 accessibility перевірками виявить очевидні проблеми, але пропустить більшість. InclusiveWeb із 90+ правилами охоплює значно більше сценаріїв — включно з перевірками, специфічними для динамічних компонентів, ARIA-паттернів та мобільного UX.

Правило 30–57%: де воно береться

Цифра 30–57% виникла з кількох незалежних досліджень:

1Deque (2019): Дослідження «Automated Accessibility Testing Study» протестувало ряд популярних інструментів на спеціально підготовлених сторінках із відомими WCAG-помилками. Найкращий результат — 57% виявлених проблем автоматично. Решту знайшло лише ручне тестування.
2UK Government Digital Service, GDS (2017): Тест на «найменш доступній веб-сторінці у світі» (спеціально створеній). Різні інструменти виявили від 13% до 40% проблем. Жоден не перевищив 40%.
3WebAIM (дослідження 2021): Порівняння автоматичних сканерів із ручним аудитом реальних сайтів підтвердило нижню межу — близько 30% для менш потужних інструментів, до 57% для кращих.
4Knowbility (дослідження 2022): Аналіз реальних сайтів некомерційних організацій підтвердив: після автоматичного аудиту ручне тестування стабільно виявляє ще 40–60% нових проблем.

Важливе уточнення: ці дослідження вимірюють кількість помилок. Але автоматика виявляє насамперед «легкі» технічні проблеми. Ручне тестування знаходить складніші, часто більш критичні проблеми для реальних користувачів.

Комбінований підхід: автоматика + ручне тестування

Оптимальна стратегія — не вибрати між автоматикою і ручним тестуванням, а поєднати їх у правильній послідовності:

Крок 1: Автоматизований аудит (InclusiveWeb)

Першим кроком запустіть автоматизований аудит із максимальним покриттям правил. InclusiveWeb із 90+ правилами WCAG виявить усі «низьковисячі плоди» — технічні проблеми, що можна знайти і часто автоматично виправити. Це дає швидкий фундамент і дозволяє ручному тестуванню зосередитися на складніших питаннях.

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

Пройдіть усі ключові сценарії використання сайту лише за допомогою клавіатури (Tab, Shift+Tab, Enter, Space, стрілки). Перевірте: чи доступні всі функції, чи видимий фокус-індикатор, чи логічний порядок фокусу, чи можна закрити будь-який modal через Escape.

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

Запустіть NVDA (Windows, безкоштовно) або VoiceOver (macOS/iOS, вбудований) і пройдіть ключові сценарії. Зверніть увагу: чи всі елементи анонсуються коректно? Чи зрозумілі повідомлення про помилки? Чи правильно працюють custom components?

Крок 4: Тестування з реальними користувачами

Залучення людей з різними типами інвалідності до usability testing виявить проблеми, які неможливо знайти іншими методами — особливо пов'язані з когнітивною доступністю та загальним UX. Навіть одна сесія з незрячим користувачем може виявити критичні проблеми, що пройшли повз усі автоматичні та ручні перевірки.

Скільки це коштує: аналіз витрат

Вибір підходу до тестування має фінансовий вимір. Ось порівняльний аналіз:

Підхід	Типова вартість	Покриття проблем	Регулярність
Тільки Lighthouse	$0	~20%	Вручну, нерегулярно
InclusiveWeb автоматичний аудит	Від $0/міс	До ~50–57%	Безперервний моніторинг
Ручний аудит (accessibility consultant)	$2,000–$15,000 разово	70–90%	1–2 рази на рік
Комплексний VPAT (WCAG conformance report)	$5,000–$30,000+	90%+	Раз на рік або рідше
ADA lawsuit settlement	$25,000–$100,000+	—	Можна уникнути

Оптимальна стратегія для більшості компаній: автоматизований моніторинг (InclusiveWeb) + щорічний ручний аудит ключових сценаріїв. Це дає максимальне покриття при розумних витратах і забезпечує постійний рівень відповідності, а не «snapshot» раз на рік.

Почніть з автоматичного аудиту вже сьогодні

90+ правил WCAG, безперервний моніторинг, autofix для виявлених проблем — і це лише перший рубіж вашого комплексного підходу до доступності.

Запустити аудит безкоштовно

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

Якщо автоматика виявляє лише 30–57%, чи варто нею користуватися взагалі?

Безумовно так. Автоматика виявляє саме ті проблеми, які зустрічаються найчастіше і охоплюють велику кількість сторінок — відсутні alt-тексти, низький контраст, missing labels. Один автоматичний скан може виявити сотні проблем за хвилини, що займало б тижні ручного тестування. Правильне розуміння: автоматика — обов'язковий перший крок, а не достатній.

Який скрінрідер використовувати для ручного тестування?

Для початку — NVDA (Windows, безкоштовний) у поєднанні з Chrome або Firefox. Це найпопулярніша комбінація серед реальних користувачів скрінрідерів. Для macOS/iOS — VoiceOver (вбудований, безкоштовний). Для Android — TalkBack. Якщо є можливість — тестуйте хоча б у двох комбінаціях (NVDA+Chrome та VoiceOver+Safari), оскільки поведінка може відрізнятись.

Чи може CI/CD автоматичне тестування замінити окремий аудит?

Автоматичні тести в CI/CD (наприклад, axe-core у Jest або Cypress) є чудовою практикою для запобігання регресіям — вони не дозволять задеплоїти зміну, що ламає доступність. Але вони мають ті самі обмеження: 30–57% покриття. Тому CI/CD тести + InclusiveWeb моніторинг на продакшні + регулярний ручний аудит — це повноцінна стратегія. Кожен рівень доповнює інший.

Як часто потрібно проводити accessibility аудит?

Автоматичний моніторинг має бути безперервним — щоразу після деплою нового контенту або коду. Ручний аудит ключових сценаріїв — мінімум раз на рік або після значних змін дизайну/функціональності. Тестування з реальними користувачами — хоча б раз на рік. Якщо ваш сайт регулярно оновлюється (новини, блог, e-commerce) — InclusiveWeb забезпечує постійний автоматичний моніторинг без додаткових зусиль з вашого боку.

Джерела та посилання

Останнє оновлення: 06.04.2026