Зрячий відвідувач охоплює сторінку одним поглядом: бачить заголовок, меню, кнопку «У кошик» і підвал одразу, і око стрибає до головного. Незрячий клієнт з екранним читачем не отримує такої карти з першого погляду. Він рухається сторінкою лінійно, згори донизу, або стрибає структурою: від заголовка до заголовка, від орієнтира до орієнтира, від посилання до посилання. Якщо цієї структури насправді немає - якщо заголовки просто великий жирний текст, якщо в кнопок немає імені, якщо кожне посилання каже «натисніть тут», - екранному читачеві нема куди стрибати, і клієнт мусить повзти сторінкою слово за словом. Найчастіше він іде. А оскільки йдеться про зміст, а не про зламану сторінку, автоматичний сканер бачить лише частину проблеми.
Ключові факти
- WCAG 1.3.1 Інформація та зв'язки - рівень A (Web Content Accessibility Guidelines): структура, передана візуально, - заголовки, списки, підписи, таблиці, - має бути доступна допоміжним технологіям і в коді, а не імітуватися оформленням (W3C).
- WCAG 4.1.2 Ім'я, роль, значення - рівень A: кожен інтерактивний елемент (кнопка, посилання, поле форми) має повідомляти ім'я й роль, які екранний читач може оголосити, - кнопка з однієї іконки без підпису мовчить (W3C).
- WCAG 2.4.6 Заголовки й підписи - рівень AA, 2.4.4 Призначення посилання (у контексті) - рівень A: заголовки й текст посилань мають описувати, на що вони вказують, тож сторінка, повна посилань «натисніть тут», не проходить (W3C).
- WCAG 2.4.2 Заголовок сторінки і 3.1.1 Мова сторінки - обидва рівня A: кожній сторінці потрібен описовий
<title>, а мову сторінки має бути задано в коді, щоб екранний читач використовував правильний голос і вимову (W3C). - Розділ 14 IASR Онтаріо (Регламент про інтегровані стандарти доступності, O. Reg. 191/11) вимагає від організацій із 50 і більше працівниками забезпечити відповідність публічних сайтів WCAG 2.0 рівня AA - кожен критерій вище входить до цього мінімуму (ontario.ca, O. Reg. 191/11).
- Наступний строк ACR (звіту про відповідність вимогам доступності) для організацій Онтаріо з 20 і більше працівниками - 31 грудня 2026 року (ontario.ca). Аналіз WebAIM 2024 року за мільйоном головних сторінок знайшов виявлювані порушення WCAG на 95,9% із них, і найчастіші були структурними - відсутні підписи форм, порожні посилання й кнопки, відсутня мова документа (WebAIM, 2024 WebAIM Million).
Що AODA Онтаріо вимагає для доступності для екранних читачів?
AODA (Accessibility for Ontarians with Disabilities Act) Онтаріо задає політику; IASR задає технічну планку. Розділ 14 вимагає від організацій із 50 і більше працівниками забезпечити відповідність публічного вебконтенту WCAG 2.0 рівня AA. Окремого «правила для екранних читачів» у законі немає: доступ для екранних читачів - результат виконання групи критеріїв WCAG про структуру: інформація та зв'язки, ім'я/роль/значення, заголовки й підписи, призначення посилання, заголовок сторінки й мова сторінки. Виконайте їх, і екранний читач зможе пересуватися сайтом. Пропустіть - і не зможе, хоч який вигляд сторінка має для зрячого користувача.
Тому ж доступ для екранних читачів - ясніша перевірка реальної відповідності, ніж майже будь-що. Можна мати привабливий сучасний сайт, крізь який екранний читач однаково не пройде, бо візуальний лиск живе в CSS, а структури в HTML немає. Це різні речі, і законові важлива структура.
Як екранний читач насправді пересувається сторінкою?
Користувачі екранних читачів рідко читають сторінку підряд - це повільно. Вони пересуваються структурою, і більшу частину роботи роблять три структури:
- Заголовки. Користувачі відкривають список усіх заголовків, щоб пробігти сторінку як зміст і стрибнути до розділу. Це працює, лише якщо заголовки - справжні елементи
<h1>-<h6>у логічному порядку, а не просто великий жирний текст. Стрибок із<h1>одразу на<h4>чи абзац, загорнутий у тег заголовка заради оформлення, ламає карту. - Орієнтири. Області на кшталт шапки, навігації, основного вмісту й підвалу дають користувачеві змогу стрибнути просто до основного контенту чи назад до меню. Без них немає шляху «перейти до вмісту», і кожен візит починається з продирання крізь ту саму навігацію.
- Посилання й елементи керування. Користувачі також відкривають список самих лише посилань, прочитаних поза контекстом. «Детальніше», «натисніть тут» і «дізнатися більше» в такому списку марні: десять однакових пунктів, що ведуть невідомо куди. Текст посилання має бути зрозумілим сам по собі (2.4.4), а в кожної кнопки й поля форми має бути справжнє оголошуване ім'я (4.1.2). Це той самий розрив, що стоїть за доступними формами й оформленням замовлення: поле без програмного підпису для екранного читача - просто «поле редагування».
Саме це не може виправити віджет-оверлей. Скрипт поверх сторінки не може вигадати ієрархії заголовків, орієнтирів і підписів, яких у вашому HTML ніколи не було: ця структура має існувати у вихідному коді. З тієї самої причини сканування - не аудит: робот може позначити зображення без alt-тексту чи кнопку без імені, але не може сказати, чи має сенс порядок заголовків і чи зрозумілий людині текст посилання. Для такого судження потрібна людина з екранним читачем.
Як перевірити, чи може екранний читач користуватися вашим сайтом, і чим ризикуєте, якщо цього не зробити?
Корисну першу перевірку можна зробити самому за кілька хвилин. У кожному Mac є VoiceOver (Cmd-F5), у кожному ПК з Windows - Екранний диктор (Ctrl-Win-Enter); безкоштовний екранний читач NVDA широко використовують у Windows. Увімкніть один із них і:
- Відкрийте список заголовків і прочитайте його як план. Чи описує він сторінку за порядком, з одним
<h1>, без пропущених рівнів і без декоративного тексту, що вдає заголовок? - Пройдіть табуляцією кожен елемент керування і слухайте. Чи оголошує кожна кнопка, посилання й поле ім'я і те, що воно робить (4.1.2)? Мовчазні чи «непідписані» елементи - порушення, особливо кнопки з однієї іконки.
- Відкрийте список посилань. Чи зрозуміле кожне посилання поза контекстом, чи це стіна з «натисніть тут» (2.4.4)?
- Пройдіть реальне завдання - знайти товар, додати в кошик, заповнити форму, дійти до оформлення замовлення - лише з клавіатури й екранного читача. Це перетинається з клавіатурною доступністю: якщо до елемента не можна дістатися табуляцією, користувач екранного читача до нього теж не дістанеться.
В Онтаріо в AODA немає права приватного позову - за ним приватні особи не можуть подати до суду. Шлях для людини - HRTO (Трибунал із прав людини Онтаріо), який розглядає скарги про дискримінацію за Кодексом прав людини Онтаріо. У незрячого клієнта, який не може пересуватися вашим сайтом, щоб купити те, що може купити зрячий, є правдоподібна претензія про нерівний доступ до товарів і послуг. А якщо ви продаєте в США, структурні порушення, які відрізають екранні читачі, - одні з найзгадуваніших у позовах за ADA, частина з 5 114 позовів щодо цифрової доступності, поданих до судів США у 2025 році (UsableNet). Як і за будь-якої прогалини, довговічна позиція - задокументоване виправлення: знайдені структурні проблеми, викочені виправлення й дати, - і це ж має відображати чесний ACR до 31 грудня 2026 року. Робота за WCAG 2.2, чинним стандартом, лише зміцнює цю позицію.
Дізнайтеся, чи не знаходить перевірка на вашому сайті проблем зі структурою, підписами чи іншою доступністю, - безкоштовний звіт Vayle, приблизно 30 секунд: vayle.art. Він виявляє оверлеї, показує реальні порушення WCAG і точно каже, що юридично стосується вашої організації в Онтаріо. Без зобов'язань.
Vayle працює віддалено й займається інженерною доступністю сайтів для бізнесу Онтаріо. Загальна інформація, а не юридична консультація.