Человек не должен разгадывать интерфейс
Представим форму запроса на разработку сайта. Посетитель описал задачу, оставил контакт и нажал кнопку, но увидел только красную рамку. Что произошло: не хватает номера, пропал интернет или запрос уже отправлен? Такая неопределённость является проблемой дизайна, а не невнимательности человека. В макете полезно показать не только идеально заполненную форму, но и незавершённый ввод, несколько ошибок, ожидание и успешный результат. От этих небольших состояний зависит понятность всего пути.
Объясните требования заранее
Каждому полю нужно понятное название; WAI рекомендует связывать его с элементом ввода. Пример формата не заменяет название поля. В нашем условном брифе телефон можно обозначить как необязательный, если достаточно электронной почты. Не стоит требовать полный адрес компании по привычке, когда для первого разговора он не нужен. До рисования формы составьте список полей и объясните назначение каждого. Если объяснение не находится, поле стоит пересмотреть. W3C WAI: Labeling Controls
Назовите конкретную проблему
Выявленную ошибку нужно описать текстом и указать соответствующее поле; одного цвета недостаточно. Вместо абстрактного сообщения о некорректных данных при пустом контакте можно написать «Добавьте адрес электронной почты». Для нашей формы стоит подготовить отдельные тексты для отсутствующего контакта, неполного описания и временно недоступного сервиса. Не смешивайте их в одну красную плашку: ошибка ввода и сбой отправки требуют разных действий. W3C: Error Identification
Покажите путь к исправлению
Когда способ исправления известен и безопасен, предложите его. Например, для поля с конкретным ограничением длины объясните это ограничение, а не просто просите попробовать снова. В длинной форме общий список проблем с переходами к полям может дополнять подсказки рядом с ними. Сообщения не должны перекрывать введённый текст. Проверьте сценарий клавиатурой: человек должен найти проблемное место, исправить его и продолжить без повторного заполнения всего брифа. W3C: Error Suggestion
Не путайте проверку с доставкой
Проверка в браузере не заменяет серверную проверку. Правильный формат адреса также не означает, что сообщение доставлено. Текст результата должен соответствовать фактическому ответу системы. В нашем примере сохранение запроса и неудачная отправка являются разными состояниями. Не обещайте звонок через пять минут, если такого процесса нет. Отдельно продумайте повторные нажатия, медленное соединение и повторное открытие страницы, а не только идеальный сценарий. MDN: Client-side form validation
Проверьте не только успешный сценарий
WAI рекомендует сообщать и об успехе, и о неудаче отправки. Перед запуском пройдите короткий маршрут: пустая форма, один неправильный контакт, длинный текст, исправление, успешный запрос и сбой сервиса. Проверьте увеличенный текст, телефон и клавиатуру; для доступности также нужна проверка вспомогательными технологиями. Этот список не является сертификацией, но помогает понять, поддерживает ли форма человека вместо того, чтобы оставлять его перед необъяснённой красной рамкой. W3C WAI: User Notifications