Frontender Magazine

Разработка удобных алгоритмов взаимодействия

Примечание от редакторов A List Apart: Мы с удовольствием представляем вам отрывок Главы №5 из книги Веб для всех: Разработка доступных пользовательских интерфейсов Сары Хортон (Sarah Horton) и Уитни Квесенбери (Whitney Quesenbery). Используйте код AWFEALA чтобы сэкономить 20% при покупке этой книги в магазине Rosenfeld Media.

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

Определение и описание интерактивных элементов

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

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

Используйте HTML-код по назначению

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

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

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

<label for="firstname">Имя:</label>
<input type="text" id="firstname" />
<label for="lastname">Фамилия:</label>
<input type="text" id="lastname" />

Рисунок 5.1: Визуально элементы label связаны с полем ввода текста посредством близости их расположения. В коде они связаны программным путём с помощью элемента <label>, атрибута for и атрибута id поля ввода текста.

Используйте технологию WAI-ARIA для сложных элементов

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

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

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

аккордеон

Рисунок 5.2: На сайте организации OpenAjax Alliance представлены примеры и доступный для скачивания код многих популярных шаблонов для веб-разработки, в том числе доступный виджет-аккордеон.

ARIA будет полезна и при разработке других видов взаимодействий. Например, в форме регистрации на рисунке 5.3 для отображения сообщений об ошибке используется атрибут role=“alert” чтобы полезные поточные сообщения об ошибках могли быть озвучены для пользователей скринридеров.

ошибка

Рисунок 5.3: В этой форме регистрации уведомления обозначаются программно с помощью ARIA-атрибута role.

Используйте возможности технологической платформы

Если вы прописываете элементы не с помощью HTML, а какого-либо другого языка, убедитесь что его возможности максимально использованы для наиболее полного определения и описания интерактивных элементов. В большинстве своём, технологии вроде Flash и Java обладают достаточным набором инструментов для обеспечения доступности. Разработчикам, использующим эти инструменты, нужно только применить их правильным образом и убедиться что дизайн позволяет сделать взаимодействие доступным.

Однако не пренебрегайте тщательной оценкой возможных последствий перед тем как отступить от стандартных технологий. Является ли конкретное взаимодействие критически важным для достижения цели продукта? Если да, то можете ли вы его реализовать используя стандартный код? Убедитесь в полной невозможности использовать стандартные веб-технологии перед тем как положиться на нестандартный, и следовательно менее стабильный и доступный подход.

Обеспечьте доступность инструкций и обратной связи

В главе №4, «Организация чистого и последовательного кода», мы обсудили как некоторые режимы взаимодействий зависят от линейности страницы и насколько важной является правильная последовательность кода, ведь она влияет на порядок, в котором отображаются элементы. Например, скринридер в аудио режиме не может воспроизводить более одной порции информации или опции взаимодействия в конкретный момент времени. Интерактивные элементы, расположенные в неверной последовательности могут оказаться препятствием для любого пользователя, но в особенности для тех, кто зависит от линейной презентации.

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

Расположение в коде значительно влияет на доступность форм и сообщений об ошибке. Когда пользователь заполняет форму, производится проверка кода на валидность данных введённых в каждое поле. Например, происходит проверка на наличие имени пользователя. Если ответ на ввод данных отображается над полем, вспомогательная программа не видит изменение и переходит к следующему полю. Хуже того, в некоторых формах сообщения об ошибке отображаются в «модальных» всплывающих окнах, которые пользователь должен закрыть перед исправлением ошибки. Так как после закрытия окна, сообщения об ошибке больше не видно, пользователь должен попытаться не забыть перечень ошибок пока ищет поля где их можно исправить.

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

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

Последовательность также имеет большое значение в инструкциях. Иногда формы созданы так чтобы инструкции и подсказки располагались после полей ввода и кнопок. Пользователям (и вспомогательным программам) приходится забегать наперёд чтобы определить назначение каждого поля и затем возвращаться чтобы его заполнить. Убедитесь что элементы в форме имеют логическую последовательность: и визуально и в коде определение и описание взаимодействия должно предшествовать самому элементу взаимодействия.

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

Поддержка взаимодействия с помощью клавиатуры

Модель взаимодействия «наведение и клик», популярное при использовании мышки, не является универсально применимым. Незрячие пользователи не могут использовать указатель мышки. Людям с нарушениями координации движений манипуляции мышкой могут показаться затруднительными и проблематичными. Некоторые альтернативные устройства ввода предусматривают активацию команд с клавиатуры вместо мышки. Кроме того, некоторые пользователи считают управление с клавиатуры более простым, удобным и эффективным.

Предоставьте логическую последовательность переключения с помощью клавиши tab

В главе №4, «Организация чистого и последовательного кода», мы говорили о том, как последовательность кода влияет на линейный доступ к веб-страницам. Последовательность кода значительно влияет на навигацию с помощью клавиатуры, особенно когда для перехода между элементами интерактивного управления (вроде кнопок и ссылок) на странице используется клавиша tab. Переключение между элементами с помощью tab — распространённый способ навигации у пользователей клавиатуры, так же как среди людей, предпочитающих мышку, вождение указателем по экрану и клики по ссылкам и элементам управления. Пользователи клавиатуры несколько раз жмут клавишу tab пока не доберутся до желанного элемента и затем нажимают Enter чтобы его активировать.

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

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

Не требуйте взаимодействия «наведите курсор и кликните»

Поддержка управления с помощью клавиатуры не означает что нужно исключить сложные взаимодействия вроде перетаскивания («drag-and-drop»). Только убедитесь, что для всех взаимодействий предусмотрена альтернатива без использования мыши.

Вот некоторые моменты которые следует учитывать при разработке взаимодействий:

Перетаскивание

Рисунок 5.5: Этот инструмент для сбора закладок требует использовать мышь для перетаскивания объектов в список. Простая кнопка «добавить» сделала бы его более доступным.

Выделите элемент, на котором сосредоточен фокус клавиатуры

Пользователям клавиатуры также пригодится чёткое обозначение элемента на который в данный момент нацелен фокус. В браузерах такое обозначение предложено по умолчанию — обычно это пунктирная рамочка вокруг элемента. Тем не менее, навигация с помощью клавиатуры будет более удобной если с помощью CSS добавить более явные визуальные подсказки, которые помогали бы пользователям делать осознанный выбор элементов для взаимодействия. На рисунке 5.6 показан пример такого кода CSS. Лучше всего если это будет такая же подсказка, какая выводится при наведении на элемент указателя мышки.

a:hover, a:active, a:focus { outline: 2px solid blue }

Рисунок 5.6: Использование CSS для отображения хорошо заметной рамки вокруг объектов, виделенных с помощью клавиатуры. В этом примере одинаковая синяя рамка шириной 2 пикселя обозначает элементы на которые наведён указатель мыши, активные элементы и элементы с фокусом клавиатуры.

Не допускайте ловушки для фокуса клавиатуры

«Ловушка для фокуса клавиатуры» — явление характерное для встроенных объектов, таких как видео, апплеты, Flash. Когда фокус оказывается в ловушке, пользователь не может перейти к другому элементу без помощи устройства с указателем, например, мыши. Способ избежания таких ловушек зависит по большей мере от технологии, на которой построен встроенный объект. В идеале для встроенного объекта должен использоваться тот же способ навигации что и для всей страницы, т.е. клавиша tab и клавиши со стрелками. Для технологий, не поддерживающих такую стандартную навигацию, следует предоставить альтернативный вариант с использованием клавиатуры и задокументировать его чтобы пользователи могли избежать попадания в ловушку.

Сделайте элементы управления достаточно большими чтобы ими было легко пользоваться

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

Следующие рекомендации помогут сделать элементы управления более простыми в использовании:

Дайте пользователям возможность контролировать происходящее на экране

Постарайтесь избежать изменений, которые выполняются без прямого разрешения пользователя. Например, «карусель» самых важных новостей на главной странице обычно прокручивается автоматически, с рассчётом приблизительного времени, которое требуется на просмотр контента. Неконтролируемое движение в интерфейсе отвлекает и негативно влияет на восприятие. Некоторым пользователям нужно больше времени для восприятия информации, так что как минимум предложите способ остановить прокручивание. (Больше информации о мультимедиа см. в главе №9, «Доступные средства информации»)

Лучше всего будет загрузить первое изображение и предложить понятные элементы управления для перелистывания новостей. Это касается всех движущихся элементов, в том числе видео и аудио. Не проигрывайте их автоматически. Вместо этого подождите пока пользователь сам решит запустить их проигрывание. Автопроигрывание не только сбивает с толку, но также создаёт проблемы для людей в тихой обстановке или использующих медленное подключение к интернету (например на мобильном со слабым сигналом).

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

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

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

Разработка с учётом нештатных ситуаций

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

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

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

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

Пользователь: Я хотел бы сделать заказ. Вот моя информация.

Ваш сайт: Спасибо. Заказ принят. Мы отправим его вам в течении трёх дней.

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

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

Дайте пользователям достаточно времени

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

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

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

Если вы заметили ошибку, вы всегда можете отредактировать статью, создать issue или просто написать об этом редакторам Антону Немцеву в skype ravencry, Константину Гупалову в skype cosmik_soul или в skype matmuchrapna доброму Владимиру Старкову.

Sarah Horton
Whitney Quesenbery
Наталья Луканюк
Переводчик:
Наталья Луканюк
Сaйт:
http://flamecoder.net/
вКонтакте:
natatik_l
Twitter:
@very_busy_girl
GitHub:
NatalieF