Формы и ввод данных¶

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

Порядок полей следует логике задачи¶

Поля располагают в том порядке, в котором пользователь думает о предмете, а не в порядке колонок таблицы. В таблице обращений сначала идут «Продукт», «Категория» и «Приоритет», но пользователь начинает с того, что случилось. Поэтому форма открывается полем описания проблемы, а категорию и продукт можно предложить по тексту и дать исправить. Связанные поля группируют под общим заголовком: группа воспринимается как единый блок и снимает нагрузку с рабочей памяти, а для вспомогательных технологий её размечают элементом fieldset с legend.

Форма обращения: сначала списки «Продукт», «Категория», «Приоритет», описание проблемы в конце — Неудачно: форма повторяет колонки таблицы, и до описания проблемы нужно разобраться в классификации.

Форма обращения: сначала поле «Что случилось?», ниже продукт и категория, определённые по тексту, со ссылками «Изменить» — Лучше: форма начинается с того, что случилось, а продукт и категория предложены по описанию.

Одноколоночная раскладка надёжнее многоколоночной, поскольку задаёт единственный путь взгляда сверху вниз и не заставляет гадать, в каком порядке заполнять поля, стоящие рядом. Исключение составляют короткие поля, которые пользователь воспринимает как одно значение: дата из трёх частей, город и индекс.

Подпись над полем, а не вместо него¶

Подпись размещают над полем, а не внутри него: плейсхолдер, исчезающий при вводе первого символа, заставляет держать назначение поля в памяти, и при проверке заполненной формы пользователь уже не видит, что именно вводил в каждую строку. Плейсхолдер к тому же обычно выводится светлым текстом, контраст которого не дотягивает до 4,5:1, требуемых критерием 1.4.3 Contrast (Minimum) уровня AA. Подпись сверху сохраняет вертикальную ось чтения и не ломается при переводе на языки с длинными словами. Плавающие подписи (floating labels), уезжающие вверх при фокусе, сохраняют назначение поля видимым, но уменьшают его до мелкого кегля и усложняют реализацию; они уместны в плотных интерфейсах, где важна экономия высоты.

Заполненная форма без подписей: значения «Анна», «Смирнова», «15.04.2025», «3» — Неудачно: после ввода подсказки в полях исчезли, и непонятно, что означают «15.04.2025» и «3».

Та же форма с подписями над полями: «Имя», «Фамилия», «Дата начала работы», «Этаж» — Лучше: подписи над полями остаются видны и после ввода.

Подпись программно связывают с полем (<label for> или aria-labelledby), что одновременно выполняет критерий 3.3.2 Labels or Instructions (A) и увеличивает область клика: нажатие на подпись ставит фокус в поле или переключает флажок.

Обязательные и необязательные поля¶

Если большинство полей обязательны, помечают необязательные словом «необязательно» рядом с подписью; если наоборот - помечают обязательные. Звёздочка без расшифровки опирается на соглашение, которое знают не все, и не озвучивается внятно экранными дикторами, если не дополнена атрибутом required или aria-required="true". Это решение основано на практике и рекомендациях вроде GOV.UK Design System, где отмечают именно необязательные поля, поскольку форма в принципе должна содержать только необходимое.

Форма, где обязательные поля отмечены звёздочкой без пояснения — Неудачно: звёздочки без расшифровки, и отметки стоят почти на всех полях.

Та же форма, где у поля «Отчество» есть пометка «необязательно», а остальные поля без отметок — Лучше: отмечено единственное необязательное поле, и отметка - словом.

Форма ввода ичправляет ошибки пользователя¶

Интерфейс принимает данные в любом разумном формате и сам приводит их к единому виду. Номер телефона с пробелами, скобками и дефисами, номер карты, разбитый на группы, дата через точку или дробь - всё это система может разобрать самостоятельно, а отказ принять такой ввод перекладывает на человека работу программы. Если формат действительно строгий, его показывают до ввода в виде подсказки под полем, а не после ошибки.

Маски ввода помогают при фиксированных форматах, но мешают при вставке из буфера и при значениях, которые в маску не укладываются (иностранные номера телефонов), поэтому их стоит применять осторожно.

Поле «Телефон» со значением «8 (912) 345 67 89» и подсказкой о допустимом формате; под полем «ИНН» подсказка «10 цифр для организации, 12 - для ИП» — Телефон принимается в любом виде, а строгий формат ИНН объяснён под полем до ввода.

Тип поля выбирают по смыслу: type="email", inputmode="numeric" и атрибут autocomplete вызывают подходящую клавиатуру на мобильных устройствах и автозаполнение, а autocomplete для персональных данных прямо требуется критерием 1.3.5 Identify Input Purpose (AA). Критерий 3.3.7 Redundant Entry (A), появившийся в WCAG 2.2, требует не заставлять повторно вводить в рамках одного процесса уже введённые данные - например, предлагать «Совпадает с адресом доставки» для платёжного адреса.

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

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

Оптимальное решение - проверять поле при потере фокуса. После того как ошибка показана, её следует сразу же убирать, как только значение становится корректным. Это позволяет пользователю не получать замечания до завершения ввода, но мгновенно видеть, что исправление прошло успешно.

При отправке формы с ошибками фокус переводят на первое ошибочное поле или на сводку ошибок вверху формы со ссылками на поля. Сообщение об ошибке стоит рядом с полем, связано с ним через aria-describedby и объясняет, как исправить проблему, что требуется критериями 3.3.1 Error Identification (A) и 3.3.3 Error Suggestion (AA). Как формулировать сами сообщения - в разделе Сообщения об ошибках.

Форма регистрации со сводкой «Исправьте 2 ошибки» вверху и сообщениями об ошибках под полями «Электронная почта» и «Дата начала» — Сводка ошибок вверху формы ссылается на поля, а под каждым ошибочным полем сказано, как исправить значение.

Значения по умолчанию¶

Установка оптимального значения по умолчанию - самый простой способ ускорить работу формы. Она избавляет большинство пользователей от необходимости принимать решение. Это значение должно быть наиболее вероятным выбором, а не самым выгодным для бизнеса. Например, предустановленный флажок «Подписаться на рассылку» экономит один клик, но может подорвать доверие и противоречить требованиям о согласии в некоторых юрисдикциях.

Система также предлагает повторно использовать значения, которые пользователь уже вводил ранее.

Длинные формы и многошаговые мастера¶

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

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

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

Последний шаг мастера оформления заказа: индикатор «Шаг 4 из 4», сводка разделов «Получатель», «Доставка», «Оплата» со ссылками «Изменить» и кнопка «Оформить заказ» — Последний шаг мастера: видно положение в процессе, все введённые данные и переход к любому шагу для исправления.