Подсказки о доступности подсказок

Возможно, совсем недавно вы читали статью Адриана Розелли “Отскребая соженный тост” или “Обсуждение подсказок” Криса Койлера. Или, возможно, изучали гит-репозитории “Стандартного UI-элемента – тост” и ветку его обсуждения в WICG.

В конце концов, вы можете быть знакомы с концепцией подсказок из документации Андроид и Material Design.

Но, независимо от того, насколько близко вы знакомы с понятием “тост” или “подсказка”, стоит знать, что его реализация варьируется от компоненты к компоненте. И только от разработчика зависит уровень доступности и инклюзивности UX компоненты.

Я писал о проблемах подсказок в GitHub и задумался об общих проблемах функциональности компоненты. Так получилась эта быстрая зарисовка.

Определение подсказки

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

Оповещения “Growl” ОС Apple тоже, в какой-то степени, тосты, хотя они могут располагаться в верхнем или нижнем углу.

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

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

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

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

Универсальный дизайн подсказок

Компонент “тост” должен рассматриваться, как сообщение о статусе некоторого события и, следовательно, ему необходимо присваивать role=”status”. Это гарантирует, что при отображении содержимое подсказки будет передано вспомогательным технологиям, например, диктору экрана.

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

Вот список возможных проблем:

  • Блоки, которые подгружаются, а не рендерятся с самого начала, не семантичны. Предположим, у нас есть сообщение с текстом “Ваше сообщение отправлено” и ссылка (кнопка) “Отменить”. Пользователь увидит сообщение “Ваше сообщение отправлено. Отменить”, но кнопка не привязана к контексту, ее семантика не объявлена. Что приводит нас к следующей проблеме…
  • Пользователи с диктором экрана закономерно решат, что “Отмена” – элемент управления. Но они останутся без информации, что именно нужно искать (ссылку? или все же кнопку?). И на отгадку у них не так много времени (из-за WCAS 2.2.1), а потом сообщение исчезнет.
  • Даже если пользователь доберется до кнопки “Отменить”, подсказка все равно может исчезнуть. Конечно, средствами JavaScript запрещается исчезновение подсказки, пока она “в фокусе или курсор находится над тостом”. Но это не сработает с читалками с виртуальным курсором.
  • Для пользователей клавиатуры и мыши, но с ограниченной мобильностью, время, необходимое на путь до подсказки, тоже принципиально важно.
  • Если пользователю удастся пробраться через все вышеописанные препятствия, не нужно забывать об управлении фокусом элемента. После нажатия на кнопку “Отмена” фокус должен вернуться (на кнопку отправки сообщения?). А если у подсказки есть кнопка “Закрыть”, фокус может быть вообще потерян, и тогда пользователю придется шагать с самого начала документа до того места, где он остановился в последний раз.
  • А еще стоит учитывать, что всплывающее сообщение любого типа может создавать проблемы пользователям с увеличенным масштабом в браузере или с маленьким экраном (Стоит ли использовать медиа-запросы, чтобы отображать всплывающие окна иначе?)
  • Если используется программное обеспечение для масштабирования экрана без диктора, всплывающее сообщение может не попасть в увеличенную область и остаться незамеченным (и важный элемент управления в нем).
  • И, наконец, у пользователя может существовать настройка браузера и ОС, управляющая синхронизацией сообщений. В такой ситуации только юзер управляет временем, как долго тост будет отображаться на экране.

Смягчим острые углы UX для важных интерактивных элементов

Если какое-то действие очень важно, его не нужно включать в подсказку.

Но если кому-то необходимо обойти вышеописанные проблемы и, предположим, добавить в тост кнопку “Отменить”, необходимо:

  • Убедиться, что действие доступно и за пределами подсказки. Например, если мы удалили элемент списка, его нужно заменить кнопкой “Отменить”, вместо полного удаления. Таким образом, кнопка в подсказке не единственный элемент управления действием.
  • Или сохранить сообщение подсказки на странице истории уведомлений (см. роль лога ARIA). Подумайте, может ли ваш тост стать частью снэкбара?
  • Использовать модальные окна и придерживаться доступного UX в них. Можно даже оформить это окно похожим на подсказку и расположить так же, как и тост. Кто-то может возразить: “Это плохая идея, делать один элемент похожим на другой!”. Но ведь мы поступаем так с ссылками и кнопками, правда?

Завершение

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


Оригинал статьи

Рубрики: CSSHTML