Прочитайте скарги, що стоять за позовами щодо доступності сайтів, і шаблон проявиться швидко. Позивач майже ніколи не каже «ваша головна мала неправильний вигляд». Він каже, що не зміг щось зробити - оформити замовлення, увійти, надіслати запит, - бо форма не працювала з його екранним читачем. Форми - місце, де перегляд перетворюється на угоду, і саме там доступність або тримається, або тихо провалюється. Тому це найвигідніше для виправлення місце, чи то ваш клопіт - строк відповідності в Онтаріо, чи претензія з-за кордону.
Ключові факти
- В аналізі WebAIM Million 2025, що охопив мільйон найвідвідуваніших головних сторінок, 34,2% полів форм не були правильно підписані - тобто екранний читач не може надійно сказати користувачеві, для чого поле.
- Відсутні підписи полів форм були третім за частотою порушенням WCAG і траплялися на 48,2% головних сторінок; загалом на 94,8% головних сторінок знайшлися порушення WCAG 2, у середньому 51 помилка і 6,3 поля форми на сторінку (WebAIM).
- WCAG 2.2 (рекомендація W3C з жовтня 2023 року) додала дев'ять критеріїв успіху; три з них напряму стосуються форм: 2.5.8 Розмір цілі (мінімальний) - інтерактивні цілі не менші за 24×24 CSS-пікселі (рівень AA), 3.3.7 Повторне введення (рівень A) і 3.3.8 Доступна автентифікація (рівень AA).
- IASR Онтаріо (Регламент про інтегровані стандарти доступності) вимагає, щоб публічні сайти організацій із 50+ працівниками відповідали WCAG (Web Content Accessibility Guidelines) 2.0 рівня AA, зі строком 31 грудня 2026 року - і ця база вже містить основні критерії для форм, перелічені нижче.
- В AODA (Accessibility for Ontarians with Disabilities Act) немає права приватного позову, тож провінційні шляхи - процес звіту про відповідність і скарга до HRTO (Трибунал із прав людини Онтаріо), - але ризик за ADA (Americans with Disabilities Act) реальний для будь-якого бізнесу Онтаріо, що продає клієнтам у США.
Яким правилам WCAG насправді має відповідати форма?
Більша частина роботи неефектна й уже входить до бази WCAG 2.0 AA, на яку посилається IASR. Кожне поле має мати програмно пов'язаний підпис, а не лише текст-підказку, що зникає, коли починаєш друкувати (1.3.1 Інформація та зв'язки, 3.3.2 Підписи чи інструкції). Коли нестандартний елемент - стилізований випадний список, вибір дати, «select», зібраний з <div>, - відкритий допоміжним технологіям, він має оголошувати своє ім'я, роль і поточне значення (4.1.2 Ім'я, роль, значення). І допоміжний текст чи інструкції, на які спирається зрячий користувач, мають бути доступні й користувачеві екранного читача.
Друга половина - помилки. Якщо поле відхилено, форма має текстом сказати, яке і чому, а не просто пофарбувати рамку в червоний (3.3.1 Ідентифікація помилок), і за змоги запропонувати виправлення (3.3.3 Підказка під час помилки). Для всього юридичного, фінансового чи того, що змінює дані користувача, надсилання треба робити скасовним, перевірюваним чи підтверджуваним (3.3.4 Запобігання помилкам). WCAG 2.2 додає сучасні деталі: не змушувати користувачів знову вводити те, що вони вже повідомили в тому самому процесі (3.3.7 Повторне введення), не закривати вхід когнітивною головоломкою без доступної альтернативи (3.3.8 Доступна автентифікація) і робити області натискання досить великими, щоб у них влучити (2.5.8 Розмір цілі). Ще одне - 1.3.5 Визначення призначення поля, правило, що стоїть за правильним autocomplete у полях імені, пошти й адреси, - рівня AA, але з'явилося у WCAG 2.1, тож розташоване трохи вище мінімуму IASR у 2.0 і належить радше до найкращої практики, а не до суворого провінційного мінімуму.
Чому третина форм досі провалюється?
Бо порушення невидимі для того, хто зробив сторінку. Розробник із мишею й добрим зором легко проходить оформлення замовлення, яким зовсім неможливо користуватися з клавіатури чи з екранним читачем: підказка має вигляд підпису, червона рамка має вигляд повідомлення про помилку, нестандартний випадний список має нормальний вигляд. Цифра WebAIM - не екзотичний крайній випадок; це третина всіх полів на найвідвідуваніших сайтах світу. Тому ж прикручений віджет-оверлей цього не розв'язує: оверлей не може надійно знати, що конкретне <input> збирає поштовий індекс, яка умова помилки чи як оголосити саморобний вибір дати, - а на сайти з оверлеями й далі подають позови саме через ці шляхи. Виправлення живе в розмітці самої форми, тому витримує перевірку виправлення вихідного коду, а не скрипт.
Як знайти проблеми форм раніше, ніж це зробить претензія?
Автоматичний сканер добрий як перший прохід очевидною половиною: він надійно позначить поля без підписів і порожні кнопки. Але порушення, які реально ламають оформлення замовлення, - це порушення взаємодії: порядок табуляції, що пропускає кнопку надсилання, зведення помилок, яке так і не отримує фокуса, поле оплати, у якому застрягає клавіатура. Вони проявляються, лише коли людина проходить форму з клавіатурою й екранним читачем, і в цьому вся різниця між скануванням і справжнім аудитом. Спершу в пріоритет шляхи, де гроші й зобов'язання, - оформлення замовлення, створення акаунта, вхід, форми заявок і контактів, - бо саме там зосереджено позови. Потім виправляйте біля джерела й зберігайте датовані докази в Accessibility Conformance Report (ACR). Та сама робота закриває вашу прогалину за IASR до строку 31 грудня 2026 року, тож бюджет працює двічі.
Дізнайтеся, що автоматичне сканування знаходить у ваших формах, приблизно за 30 секунд - безкоштовний звіт Vayle: vayle.art. Він виявляє оверлеї, каже, що юридично застосовується в Онтаріо, і показує, де реальні прогалини, - без залякування, лише факти.
Vayle працює віддалено й займається інженерною доступністю сайтів для бізнесу Онтаріо. Загальна інформація, а не юридична консультація.