Нужен ли сайту вспомогательный текст в полях ввода

Конспект материала дизайнера Эрика Бэйли о том, почему плейсхолдеры ухудшают пользовательский опыт.

Изначально плейсхолдеры появились как атрибут HTML5. Они представляют собой слово или фразу внутри поля ввода, которая подсказывает, какие данные нужно ввести.

Эрик Бэйли отмечает, что использование плейсхолдеров таит в себе массу проблем, и призывает веб-дизайнеров отказаться от них.

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

Тем не менее соответствие программному обеспечению — не значит удобство: машина имеет ограниченный чек-лист и может не учесть важные детали. Дизайнеры делают интерфейс для людей, а не для программ, считает Бэйли, поэтому не стоит оценивать его только по набору критериев.

Эрик Бэйли говорит об инклюзивном дизайне, универсальной доступности сайтов и приложений. Дизайнеры должны создавать вещи такими, чтобы каждый человек мог легко ими пользоваться. Для достижения этой цели плейсхолдеры — неподходящий инструмент.

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

Автор статьи обращает внимание на то, что плейсхолдеры тоже остаются на языке оригинала. Часто разработчики не добавляют заголовки над полем ввода, оставляя подсказки только в форме плейсхолдера; в результате, если человек не знает чужой язык, он может не понять, какие данные нужно вводить.

По мнению Эрика, это веская причина отказаться от атрибута.

Не стоит забывать о том, что по местоположению пользователя не всегда можно понять, на какой язык для него переводить текст. IP-адрес выдаёт страну, в которой тот находится, но многие используют свои устройства не на государственном языке, и дизайнеры должны понимать это. «Следите за тем, чтобы ваш контент был семантически описан — соседи будут вам благодарны», — напутствует Эрик Бэйли.

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

Чтобы программа могла взаимодействовать с введёнными данными, ей нужно объяснить пользователю, какие символы она сможет корректно обработать. Сделать данные совместимыми можно с помощью заголовка — этот элемент даёт семантическое описание того, что нужно ввести и в какой форме. На уровне программирования заголовок и поле ввода можно связать с помощью атрибута for со значением, соответствующим идентификатору ввода (id).

В статье говорится, что без связки for и id вспомогательные технологии не смогли бы донести до пользователя, какие данные нужно ввести. Она стала API-хуком, который могут использовать программы вроде скринридеров или распознавания голоса. Без for и id люди, которые полагаются на вспомогательные технологии, не смогли бы прочесть данные из поля ввода и взаимодействовать с ними.

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

Плавающий эффект заголовка — близкий родственник этого явления.

В статье приведены данные бюро переписи населения США за 2016 год — около пятнадцати миллионов человек имеют когнитивные нарушения.

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

Под фразой «когнитивные нарушения» могут скрываться разные состояния, в том числе кратковременная потеря памяти, черепно-мозговая травма, синдром дефицита внимания и гиперактивности. Часто они влияют на запоминание информации.

Это напрямую касается использования плейсхолдеров. Как только пользователь начинает вводить текст, плейсхолдер исчезает, оставляя его один на один с пустой графой без всяких инструкций.

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

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

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

Специально для читателей из США Эрик уточняет: «Новое — не всегда значит иностранное. Всё больше представителей старшего поколения осваивают онлайн. Они становятся более технически грамотными, но чем больше пожилых пользователей, тем больше проблем с доступностью приходится решать».

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

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

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

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

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

По мнению автора, такое решение неуместно как раз из-за проблем с цветовым контрастом.

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

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

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

Автор пишет, что для наиболее распространённого размера шрифта для полей ввода коэффициент контрастности должен быть 4.5:1. Эрик отмечает, что это не его личные предпочтения, а часть разработанных правил, придерживаясь которых вы обеспечите максимально большому кругу людей возможность взаимодействовать с продуктом. Сознательно игнорируя эти правила, можно потерять часть аудитории.

Чтобы плейсхолдер был инклюзивным, нужно отойти от правил и сделать цвет текста темнее. В таком цвете даже опытный пользователь не всегда отличит его от заполненной графы и может пропустить поле ввода.

В операционной системе Windows есть функция «режим высокой контрастности». Если его активировать, система заменит исходные цвета на другие, взятые из ограниченной палитры контрастных цветов. Вот как это может выглядеть:

В режиме высокой контрастности плейсхолдер окрасился в цвет, который сделал его похожим на введённые данные. Интерфейс выглядит так, будто размер пожертвования (donation amount) уже определён, и его нельзя изменить.

Эрик пишет, что у многих возникает вопрос, можно ли изменить цвета в режиме высокой контрастности, чтобы было понятно, что плейсхолдер — не итоговый текст. Это возможно, но дизайнер не советует так поступать и приводит цитату своего коллеги.

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

Эрик выделил шесть проблем, связанных с использованием плейсхолдера. Этот атрибут:

Автор предлагает поместить текст плейсхолдера между заголовком и полем ввода.

Такое решение:

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

Вот как решение автора будет выглядеть в виде кода.

Это не слишком отличается от традиционной связки атрибутов for и id: элемент label программно связан с input с помощью id со значением employee-id. Элемент p, расположенный между label и input, заменяет атрибут placeholder.

Используя атрибут aria-describedby для связывания элементов input и p, можно задать порядок прочтения для скринридера. С ним можно быть уверенным в том, что контент p будет озвучен последним, а заголовок и тип информации, которые надо ввести, — первыми.

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

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

Если включить подсказку в заголовок, это сделает его слишком громоздким. Такой объём текста может быть трудно запомнить, а переслушивать его будет долго и нудно. В доказательство своей позиции автор ссылается на «Руководство по обеспечению доступности веб-контента»: критерии 2.4.6 и 3.3.2 говорят то же самое.

Эрик показывает, как его решение использовано в коде.

И прилагает видео, где можно увидеть, как популярные скринридеры работают с такой страницей.

В конце автор предлагает задуматься над вопросом: а нужна ли вообще информация из плейсхолдера?

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

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

Чтобы обеспечить хороший опыт пользователя, нужно создать интеллектуальный поток, который удовлетворит все его желания, считает автор. Информация должна быть полезной и отсекать ненужные вопросы.

Статья говорит о том, что только мнение реальных пользователей поможет взглянуть на продукт критически и улучшить его. Задача дизайнеров — не делать допущения вроде «они это уже знают» или «вряд ли у него плохо с памятью»; только так можно избежать неловких ошибок.