Как реализовать доступные подсказки к полям формы без потери удобства

Подсказки к полям формы остаются доступными, когда постоянное пояснение и сообщение об ошибке различимы, связаны с полем программно и доступны при работе с клавиатурой и экранным диктором. Показывайте ошибки в подходящий момент, не полагайтесь только на цвет и не объявляйте одно изменение несколько раз. Проверяйте поведение на реальной форме, а не только исходный код.

Опорные решения для доступных подсказок

• Разделяйте постоянное пояснение и текст ошибки: у них разные задачи и условия показа.
• Связывайте текст подсказки с полем с помощью семантической разметки.
• Размещайте пояснение рядом с полем и сопровождайте цвет дополнительным текстовым или графическим признаком.
• Объявляйте динамические сообщения только тогда, когда это помогает понять результат действия.
• Проверяйте форму с клавиатуры и экранным диктором до публикации.

Разделите постоянные подсказки и сообщения об ошибках

Такой подход подходит для полей с требованиями к формату, длине или содержанию, а также для форм с проверкой введённых данных. Постоянное пояснение помогает заполнить поле, сообщение об ошибке объясняет, что нужно исправить.

Не превращайте каждый совет в постоянно озвучиваемое динамическое сообщение: это может создавать лишние объявления и мешать работе с формой. Если правило очевидно из подписи поля, дополнительная подсказка не нужна.

Свяжите пояснение с полем через семантическую разметку

Перед изменением формы определите, какой текст сопровождает каждое поле и в каком состоянии он появляется. Для реализации понадобятся доступ к HTML и логике валидации, возможность проверить клавиатурную навигацию и экранный диктор, а также тестовая среда, где можно безопасно отправить форму.

Для постоянного пояснения используйте aria-describedby. У поля с ошибкой можно установить aria-invalid="true" и добавить идентификатор сообщения об ошибке в список значений aria-describedby. Саму ошибку выводите видимым текстом. Не назначайте один и тот же элемент одновременно постоянной подсказкой и динамическим объявлением без проверки поведения: сообщение может дублироваться.

Электронная почта
<p id="email-hint">Укажите адрес в формате name@example.com.</p>

<p id="email-error" hidden>Проверьте формат адреса.</p>

При показе ошибки удалите атрибут hidden, задайте полю aria-invalid="true" и включите email-error в aria-describedby. При исправлении значения сбросьте состояние ошибки и уберите её идентификатор из связи. В проекте разработки доступных сайтов важно проверять не только эту разметку, но и изменения состояния, которые вносит сценарий валидации.

Покажите подсказку рядом с полем, не полагаясь только на цвет

До реализации учтите риски и ограничения:

• Подсказка не заменяет видимую подпись поля.
• Изменение цвета само по себе не объясняет, что пошло не так.
• Повторные объявления при каждом вводе могут перегружать пользователей экранных дикторов.
• Скрытый текст может оставаться связанным с полем и после того, как он перестал быть актуальным.

1. Оставьте подпись видимой. Используйте элемент , связанный с полем через одинаковые значения for и id. Не используйте текст-плейсхолдер как единственную подпись.
2. Разместите постоянное пояснение рядом с полем. Напишите короткую инструкцию и присвойте ей уникальный идентификатор. Свяжите пояснение с полем через aria-describedby, добавив этот идентификатор к уже имеющимся связям, если они есть.
3. Покажите ошибку текстом. Расположите сообщение рядом с соответствующим полем и явно назовите проблему: например, "Введите адрес электронной почты в правильном формате". Дополните текст значком или цветом, но не заменяйте ими само сообщение.
4. Синхронизируйте состояние поля и ошибки. При обнаружении ошибки обозначьте поле как невалидное и свяжите его с сообщением. После исправления снимите состояние ошибки и обновите связь, чтобы устаревший текст не озвучивался.
5. Проверьте путь пользователя. Заполните поле клавиатурой, вызовите ошибку, прочитайте сообщение и исправьте значение. Убедитесь, что подпись, подсказка и ошибка не исчезают при переходе фокуса.

Такое создание доступных форм на сайте полезно оценивать вместе с остальной логикой взаимодействия: последовательностью фокуса, поведением после отправки и доступностью сообщений о результате.

Обновляйте динамические сообщения без лишних объявлений скринридера

Проверьте результат по списку. Во время проверки отслеживайте не только текст сообщения, но и момент, когда он появляется и озвучивается.

• Постоянное пояснение доступно до начала ввода и связано со своим полем.
• Ошибка появляется в понятный момент, а не при каждом изменении символа без необходимости.
• Текст ошибки видим и сообщает, как исправить значение.
• Состояние поля отражает наличие ошибки и сбрасывается после исправления.
• Динамическое сообщение не объявляется повторно при каждом рендере или перемещении фокуса.
• Объявление через область статуса используется только для сообщений, которые нужно услышать без перемещения фокуса.
• После отправки формы пользователь может определить, какие поля требуют исправления.
• Исправленное поле не продолжает ссылаться на скрытое или устаревшее сообщение.

Для краткого подтверждения действия может подойти отдельная область с role="status". Не добавляйте её к каждому полю автоматически: сначала проверьте, не озвучивается ли тот же текст уже благодаря фокусу и связи через aria-describedby.

Выберите безопасный момент для показа ошибок валидации

Типовые ошибки при реализации:

• Показывать ошибку до того, как пользователь начал заполнять поле или попытался отправить форму.
• Сообщать только "Неверно" или "Ошибка", не объясняя, что именно нужно исправить.
• Снимать ошибку визуально, но оставлять aria-invalid="true" или связь с текстом ошибки.
• Скрывать пояснение после ввода, хотя оно по-прежнему нужно для выполнения требования.
• Объявлять каждый символ через область статуса, из-за чего экранный диктор перебивает ввод.
• Перемещать фокус неожиданно при появлении обычного сообщения об ошибке.
• Показывать ошибку только красной рамкой или значком без текстового объяснения.
• Не проверять, сохраняются ли сообщения и их связи после отправки формы с ошибками.

Для проверки целостности взаимодействия включите сценарии с пустым полем, неверным форматом, исправлением значения и повторной отправкой. Такой сценарий подходит и для аудита доступности сайта, если проверяется уже существующая форма.

Проверьте подсказки клавиатурой и с экранным диктором

• Ручная проверка клавиатурой. Уместна на каждом этапе: пройдите форму клавишей Tab, проверьте видимость фокуса, вызовите ошибку и убедитесь, что сообщение можно связать с нужным полем по контексту.
• Проверка с экранным диктором. Подходит для проверки порядка озвучивания подписи, постоянного пояснения и ошибки. Убедитесь, что динамическое изменение не звучит многократно.
• Проверка разных сценариев валидации. Используйте пустое значение, некорректный ввод, исправление и повторную отправку. Это помогает обнаружить ошибки в обновлении атрибутов и скрытии сообщений.
• Экспертная проверка реализации. Уместна перед выпуском формы или при аудите доступности: специалист может оценить и разметку, и реальное поведение интерфейса. Если вы рассматриваете услуги веб-разработки, заранее уточните, входит ли в работу такая проверка.

Ориентиром для комплексной оценки может служить доступность сайта по WCAG, но соответствие отдельной разметки требованиям не заменяет проверку формы в работе.

Практические уточнения о доступности подсказок в формах

Можно ли ограничиться плейсхолдером вместо подписи?

Нет. Используйте видимую подпись, связанную с полем, а плейсхолдер оставляйте только для примера или краткого формата ввода.

Нужно ли озвучивать постоянную подсказку через область статуса?

Обычно достаточно связать её с полем через aria-describedby. Область статуса нужна для значимых динамических изменений, которые пользователь должен узнать, не переводя фокус.

Когда показывать ошибку валидации?

Выберите момент, подходящий сценарию: например, после отправки формы или после завершения ввода в поле. Избегайте сообщений, которые появляются преждевременно или обновляются на каждый символ без необходимости.

Нужно ли менять цвет поля при ошибке?

Можно использовать цвет как дополнительный сигнал, но сообщение должно объяснять ошибку словами. Одного изменения цвета недостаточно.

Можно ли связать с полем несколько текстовых подсказок?

Да, перечислите идентификаторы нужных элементов в aria-describedby. Проверьте порядок их чтения и убирайте из связи сообщения, которые стали неактуальными.

Что проверить, если экранный диктор произносит ошибку дважды?

Проверьте, не объявляется ли текст одновременно через связь с полем и отдельную область статуса. Оставьте механизм, который своевременно сообщает об ошибке без повторов, и проверьте результат при переходе к полю.

Достаточно ли автоматической проверки формы?

Нет. Автоматические средства могут выявить часть проблем разметки, но поведение подсказок и объявлений нужно проверять вручную с клавиатурой и экранным диктором.

Автор: Виктор Егоров.