Как разрабатывать формы с учетом интересов каждого пользователя.
Я уверен, что в какой-то момент нашей жизни у всех нас был болезненный опыт заполнения формы в Интернете. Непонятный ввод, нечеткие ожидаемые форматы, загадочные сообщения об ошибках, отсутствие доступа с клавиатуры… Список можно продолжать и продолжать.
А теперь представьте, что помимо этого переживания есть инвалидность или нарушение (слепота, дальтонизм, нарушение моторики, когнитивные нарушения и т. Д.).
Формы нужны для всего, что угодно в Интернете. Вы используете их, чтобы подписаться на услугу, или войти в свою учетную запись, или разместить заказ на сайте электронной коммерции. Формы везде!
Так что давайте, как дизайнеры и разработчики, сделаем их хорошими.
Ниже приведены 10 рекомендаций, которым вы можете следовать, чтобы сделать свои формы более доступными и удобными для пользователей уже сегодня.
1. Все входные данные должны иметь соответствующие ярлыки.
Ярлыки важны для идентификации ваших входов. Они помогают зрячим и слепым пользователям знать, для чего нужен каждый ввод. Ярлыки особенно важны для программ чтения с экрана, так как они могут правильно объявлять каждый ввод. Вы также должны использовать фактический HTML-элемент label, а не просто элемент span или div.
Хороший пример:
Плохой пример:
2. В качестве примеров следует использовать текст-заполнитель.
Текст-заполнитель предназначен для использования в качестве примера ответа. Его не следует использовать в качестве замены ярлыка. Проблема с попыткой использовать текст-заполнитель в качестве метки заключается в том, что текст-заполнитель исчезает после того, как пользователь ввел некоторую информацию, поэтому метка теперь фактически отсутствует.
Хороший пример:
Плохой пример:
Текст-заполнитель также не нужно использовать для повторения того, что написано на этикетке. Если на вашем ярлыке написано «Имя», то текст-заполнитель, в котором также написано «Имя», излишне.
Плохой пример:
3. Должны отображаться ожидания форматирования.
Если вы ожидаете, что пользователь введет некоторую информацию в определенном формате, сообщите им заранее! Например, если вам нужно ввести дату их рождения в формате MM/DD/YYYY, отобразите это где-нибудь рядом с полем ввода.
Невероятно неприятно вводить что-то, что, по вашему мнению, является допустимым вводом, только чтобы получить сообщение об ошибке при отправке формы, что вы указали недопустимый формат для поля.
Хороший пример:
Плохой пример:
Или, что еще лучше, будьте гибкими в выборе данных, которые вы можете принять. Если вы запрашиваете чей-то номер телефона, вы можете разрешить широкий спектр вводимых значений, например:
- 8881234567
- 888 123 4567
- 888–123–4567
- (888) 123–4567
Затем вы можете самостоятельно проанализировать ввод на серверной части и удалить все нецифровые символы и лишние пробелы.
4. Обязательные поля должны быть указаны
Это достаточно просто. Если у вас есть некоторые поля, которые являются обязательными, и некоторые поля, которые являются необязательными, укажите, какие из них какие. Некоторые дизайнеры предпочитают отмечать обязательные поля чем-то вроде звездочки или текста required рядом с меткой, а другие дизайнеры предпочитают отмечать необязательные поля чем-то вроде текста(optional) рядом с меткой.
Мне кажется, не имеет значения, какой из этих подходов вы выберете, если вы последовательны.
Хороший пример:
Плохой пример:
5. Цвет не должен быть единственным индикатором обратной связи.
При отображении сообщений об ошибках часто используется красный цвет. Для сообщений об успехе часто используется зеленый цвет. Однако цвет не должен быть единственным индикатором обратной связи. Если все, что вы делаете, это изменяете границу ввода текста, когда его значение является допустимым или недопустимым, дальтоники могут не заметить эту разницу. (Фактически, красно-зеленая дальтонизм является самой распространенной формой дальтонизма.)
Вместо этого вы должны использовать комбинацию цвета, текста и значков для отображения обратной связи, например сообщений об ошибках. Красный X и зеленая галочка отлично подходят для использования, потому что даже дальтоники могут заметить очевидную разницу между X и галочкой.
Хороший пример:
Плохой пример:
То же самое и с кнопками. Иногда у вас может быть кнопка, меняющая цвет, когда она наведена мышью или сфокусирована клавиатурой. Тем не менее, что-то вроде индикатора контура или подчеркивания гораздо эффективнее указывает на фокус, поскольку даже пользователи, которые не могут различать выбранные вами цвета, по-прежнему смогут видеть ваши контуры и подчеркивания.
Хороший пример:
Плохой пример:
6. Сообщения об ошибках должны быть полезными и близкими к вводу.
При проверке формы сообщения об ошибках должны отображаться как можно скорее, желательно на стороне клиента, а не ждать, пока будет отправлена вся форма.
Например, если у вас есть поле электронной почты, и пользователь вводит что-то, что не является электронной почтой, полезное сообщение об ошибке должно отображаться рядом с полем формы, когда ввод теряет фокус. Что-то вроде «Пожалуйста, укажите действующий адрес электронной почты» должно быть достаточно для сообщения об ошибке.
Хороший пример:
Плохой пример:
Сообщения об ошибках всегда должны сообщать пользователю, как исправить ошибку. Бесполезные сообщения об ошибках, такие как «Недопустимый ввод» или «Ошибка», бесполезны для пользователя. Возможно, пользователь не понимает, почему введенные данные недействительны.
Как указано в Правиле 3, если у вас есть ввод, требующий определенного формата для ответа, убедитесь, что пользователь знает, что это за формат. В дополнение к отображению ожидаемого формата впереди вы также можете предоставить сообщение об ошибке, например «Укажите дату вашего рождения в следующем формате: ММ / ДД / ГГГГ».
7. Все элементы должны быть доступны для клавиатуры.
Клавиатура предназначена не только для опытных пользователей, которые хотят быстро перемещаться между полями формы. Некоторые пользователи с двигательными нарушениями не могут пользоваться мышью, поэтому полагаются исключительно на клавиатуру. Пользователи программ чтения с экрана также используют только клавиатуру.
Входы и кнопки по умолчанию доступны с клавиатуры, поэтому, пока вы используете семантически правильные элементы HTML во всем приложении, вы уже должны получить правильную функциональность прямо из коробки.
Проблема возникает, когда разработчики делают глупые вещи, например, используют div или span вместо button. Пожалуйста ... не будь этим человеком. Использование правильных элементов HTML обеспечивает правильную работу с клавиатурой и помогает программам чтения с экрана знать, что aria-role имеет каждый элемент и как с ним обращаться.
8. Входы и кнопки должны иметь индикаторы фокуса.
Мы кратко коснулись этого вопроса еще в Руководстве 5. Повторяю, вам необходимо четко указать пользователю, на каком элементе он в настоящее время сосредоточен. Вместо того, чтобы использовать только цвет, вам следует использовать что-то вроде контура или подчеркивания.
Вы можете свободно использовать CSS для отключения индикаторов фокуса браузера по умолчанию, если вы хотите, чтобы индикатор фокуса был единообразным в каждом браузере, но не отключайте эти индикаторы фокуса, не добавляя свои собственные!
Хороший пример:
Плохой пример:
9. Порядок табуляции должен иметь смысл.
Когда пользователь выполняет табуляцию по вашей форме, порядок табуляции должен быть логичным. Для большинства западных языков, которые читаются слева направо, порядок табуляции должен идти слева направо, сверху вниз.
Порядок табуляции может нарушиться из-за неправильного использования атрибута tab-index в ваших HTML-элементах. Обычно вы хотите использовать только -1 и 0 в качестве значений для tab-index.
-1 удаляет элемент из естественного порядка табуляции, но по-прежнему позволяет программно сфокусировать элемент. 0 подходит для элементов, которые вставляются динамически, поскольку 0 размещает элемент в логическом порядке табуляции в соответствии с его размещением в DOM.
Любые другие значения, в которых вы пытаетесь специально управлять порядком табуляции в вашем приложении, вероятно, не нужны и могут быть признаком того, что вы делаете что-то не так.
И пока мы занимаемся этим, не следует автоматически переключать фокус с одного ввода на другой после того, как пользователь ввел некоторую информацию. Например, если у вас есть вводимый текст, который запрашивает двухбуквенное сокращение штата («UT» для Юты), не переводите пользователя на следующий ввод после того, как он ввел два символа.
Вы можете думать, что помогаете, но на самом деле вы просто раздражаете. Позвольте пользователю контролировать, на чем он сосредоточен.
10. Для группировки входных данных следует использовать наборы полей и легенды.
Длинные формы часто можно разбить на логические части. Если ваша форма отображается на одной странице, элементы HTML fieldset и legend могут помочь сгруппировать ваши входные данные и сделать вашу форму более читаемой.
Хороший пример:
Плохой пример:
Заключение
Напомним, 10 рекомендаций, которым вы должны следовать для создания доступных форм:
- Все входы должны иметь соответствующие метки.
- В качестве примеров следует использовать текст-заполнитель.
- Должны отображаться ожидания форматирования
- Обязательные поля должны быть указаны
- Цвет не должен быть единственным индикатором обратной связи
- Сообщения об ошибках должны быть полезными и близкими к вводу.
- Каждый элемент должен быть доступен для клавиатуры.
- Входы и кнопки должны иметь индикаторы фокуса
- Порядок табуляции должен иметь смысл
- Для группировки входных данных следует использовать наборы полей и легенды.
Следуя этим рекомендациям, вы улучшите работу пользователей с ограниченными возможностями и без них. Спасибо за прочтение!
