У серці вебдоступності є неочевидний факт, об який щороку спотикаються власники бізнесу з найкращими намірами: найчастіший інструмент, до якого тягнуться, щоб «зробити сайт доступним», - це й один із найчастіших способів зробити його менш доступним. Цей інструмент - ARIA (Accessible Rich Internet Applications), набір атрибутів HTML, які кажуть екранним читачам, що це за елемент і що він робить. За правильного й помірного використання ARIA закриває прогалини, яких не може закрити звичайний HTML. За недбалого - коли її розбризкує розробник, який розуміє її наполовину, чи повністю вставляє віджет-оверлей - вона активно бреше допоміжним технологіям: оголошує кнопки, яких немає, неправильні підписи й ролі, які не збігаються. Екранний читач вірить кодові, а не екранові. І клієнтові гірше, ніж якби ніхто нічого не чіпав.
Ключові факти
- WebAIM Million 2026 - щорічний аналіз WebAIM за мільйоном головних сторінок - показав, що на головних сторінках з ARIA в середньому була 59,1 виявлена помилка, проти 42 на сторінках без ARIA; що більше атрибутів ARIA використовувала сторінка, то більше виявлених помилок доступності на ній зазвичай було (WebAIM, 2026 WebAIM Million).
- Той самий звіт знайшов виявлювані порушення WCAG 2 на 95,9% головних сторінок у 2026 році проти 94,8% у 2025 році, що перекреслило кілька років повільного покращення (WebAIM, 2026 WebAIM Million).
- Власні рекомендації W3C формулюють жорстке правило: без ARIA краще, ніж із поганою ARIA. Перше правило ARIA: якщо нативний елемент HTML справляється із завданням, використовуйте його, а не відтворюйте його через ARIA (W3C, WAI-ARIA Authoring Practices).
- WCAG 4.1.2 Ім'я, роль, значення - рівень A (Web Content Accessibility Guidelines): кожен інтерактивний елемент має повідомляти допоміжним технологіям правильні ім'я, роль і значення, а неправильна ARIA - один із найшвидших способів цей критерій провалити (W3C).
- Розділ 14 IASR Онтаріо (Регламент про інтегровані стандарти доступності, O. Reg. 191/11) вимагає від організацій із 50 і більше працівниками забезпечити відповідність публічних сайтів WCAG 2.0 рівня AA, а наступний ACR (звіт про відповідність вимогам доступності) для організацій із 20 і більше працівниками треба подати до 31 грудня 2026 року (ontario.ca, O. Reg. 191/11).
Що таке ARIA і що насправді вимагає від неї WCAG?
ARIA - словник атрибутів, як-от role="button", aria-label, aria-expanded, aria-hidden, які додають в HTML, щоб передати зміст екранному читачеві. Її завдання вузьке: описувати нестандартні віджети й динамічний контент, для яких у звичайному HTML немає вбудованого елемента. Справді нестандартний випадний список, панель вкладок, сума кошика, що оновлюється на льоту, - їм може справді знадобитися ARIA, щоб екранний читач оголошував, що відбувається.
WCAG вимагає не «використовувати ARIA». За 4.1.2 Ім'я, роль, значення (рівень A) вона вимагає, щоб кожен інтерактивний елемент повідомляв правильні ім'я, роль і стан - будь-яким способом. Стандартна <button>Add to cart</button> уже робить це безкоштовно. Щойно ви замінюєте її стилізованим <div> і прикручуєте role="button", ви берете на себе завдання наново реалізувати все, що давала нативна кнопка: фокус клавіатури, клавіші Enter і пробіл, оголошувану роль. Пропустіть будь-яку частину, і ви збудували те, що в коді має доступний вигляд, а на практиці не працює. Тому перше правило ARIA від W3C - надавати перевагу нативному HTML, і тому її рекомендації прямо кажуть, що без ARIA краще, ніж із поганою.
Чому додавання ARIA так часто робить сайт менш доступним?
Бо ARIA змінює те, що оголошує екранний читач, не змінюючи того, що сторінка насправді робить, і помилка невидима для зрячої людини, яка її припустилася. Повторюється кілька шаблонів:
aria-hidden="true"не на тому елементі. Задуманий, щоб сховати декоративне сміття, він потрапляє на справжній елемент керування чи шматок контенту, який потім повністю зникає для користувачів екранних читачів, лишаючись повністю видимим для всіх інших.aria-label, що перекриває видимий текст. На екрані кнопка «Submit», а оголошується «кнопка» чи, гірше, підпис, що лишився від минулого релізу, і користувач голосового керування, який каже «натиснути Submit», ні в що не влучає.- Роль, що суперечить елементові. Посилання з
role="button"чи заголовок ізrole="presentation"кажуть екранному читачеві одне, а сторінка поводиться як інше. Це та сама структурна поломка, що описана в статті екранні читачі й структура сайту: карта для допоміжних технологій більше не збігається з реальністю. - Стан, який ніколи не оновлюється.
aria-expanded="false"у меню, яке вже відкрите, чи помилка, позначена ARIA, про яку екранному читачеві так і не повідомили, - розрив, що стоїть за більшою частиною проблем доступних форм і обробки помилок.
Саме тому сканування - не аудит. Автоматичний сканер може підтвердити, що aria-label існує; зазвичай він не може сказати, чи правильний підпис, чи збігається роль із поведінкою або чи мав схований контент бути схованим. Це людські судження, і саме тому дані WebAIM показують, що більше ARIA пов'язано з більшою, а не меншою кількістю виявлених помилок.
Чому оверлеї доступності роблять проблему ARIA гіршою?
Оверлей - один скрипт, який ви вставляєте на сайт і який обіцяє автоматично виправити доступність, і значна частина того, що він вставляє, - це ARIA. Гіршого джерела не вигадати. Оверлей не може знати, який із ваших <div> насправді кнопка, що мають казати ваші елементи з однієї іконки і чи треба ховати область, тож він гадає в масштабі, накладаючи загальну ARIA поверх структури, якої не розуміє. Результат - більше атрибутів, більше суперечностей і більше саме тих помилок, які й далі вимірює WebAIM Million. Це розрив у центрі теми віджети-оверлеї чи справжнє виправлення, і тому заходи FTC на 1 млн доларів США проти постачальника оверлеїв (accessiBe) оберталися довкола розриву між маркетинговою обіцянкою й тим, що інструмент насправді давав. Погана ARIA - не безневинне доповнення, а вимірювана шкода, і прикручується вона автоматично.
Як перевірити, допомагає ваша ARIA чи шкодить, і який ризик в Онтаріо?
Корисну першу перевірку можна зробити самому. Увімкніть екранний читач - VoiceOver є в кожному Mac (Cmd-F5), Екранний диктор у Windows (Ctrl-Win-Enter), широко використовують безкоштовний NVDA - і пройдіть реальне завдання: знайти товар, додати в кошик, заповнити форму, дійти до оформлення замовлення. Слухайте ознаки. Чи оголошує кожен елемент ім'я, що збігається з видимим текстом? Чи повідомляють меню й акордеони правильний стан «відкрито/закрито»? Чи не замовкає щось, що ви бачите, і чи не оголошує читач те, чого немає на екрані? Будь-що з цього - імовірно, дефект ARIA, і чесне виправлення майже ніколи не більше ARIA. Це видалення зламаних атрибутів і, де можливо, використання нативного елемента HTML, якому ARIA взагалі не була потрібна. Робота за WCAG 2.2, чинним стандартом, тримає цю основу чистою.
З юридичного боку: в Онтаріо в AODA (Accessibility for Ontarians with Disabilities Act) немає права приватного позову - людина не може подати за ним до суду. Шлях для приватної особи - HRTO (Трибунал із прав людини Онтаріо), який розглядає скарги про дискримінацію за Кодексом прав людини Онтаріо; у клієнта, який не може завершити покупку, яку може завершити зрячий, є правдоподібна претензія про нерівний доступ до товарів і послуг. Якщо ви продаєте ще й у США, зламані елементи керування - одні з найзгадуваніших проблем у позовах за ADA, частина з понад 5 000 позовів щодо цифрової доступності, поданих до судів США у 2025 році (UsableNet). Як завжди, довговічна позиція - задокументоване виправлення: знайдені дефекти, видалена зламана ARIA, викочені нативні виправлення й дати, - і це ж має відображати чесний ACR до 31 грудня 2026 року.
Дізнайтеся, чи не знаходить перевірка на вашому сайті зламаної ARIA, коду оверлею чи інших проблем доступності, - безкоштовний звіт Vayle, приблизно 30 секунд: vayle.art. Він виявляє оверлеї, показує реальні порушення WCAG і точно каже, що юридично стосується вашої організації в Онтаріо. Без зобов'язань.
Vayle працює віддалено й займається інженерною доступністю сайтів для бізнесу Онтаріо. Загальна інформація, а не юридична консультація.