Прочитайте жалобы, стоящие за исками о доступности сайтов, и шаблон проявится быстро. Истец почти никогда не говорит «ваша главная выглядела неправильно». Он говорит, что не смог что-то сделать - оформить заказ, войти, отправить запрос, - потому что форма не работала с его экранным чтецом. Формы - место, где просмотр превращается в сделку, и именно там доступность либо держится, либо тихо проваливается. Поэтому это самое выгодное для исправления место, будь ваша забота срок соответствия в Онтарио или претензия из-за границы.
Ключевые факты
- В анализе 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 работает удалённо и занимается инженерной доступностью сайтов для бизнеса Онтарио. Общая информация, а не юридическая консультация.