История из жизни: когда технические ограничения меняют восприятие продукта

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

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

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

Оказалось, что из-за более низкого разрешения моего монитора я просто не могла видеть этот элемент дизайна. Я как будто работала с несколько другой версией сайта, даже не подозревая об этом.

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

#design

Недавно Елена с канала «Включатель» задала мне вопрос о меню, которое раскрывается при наведении мыши. Попробую выступить в качестве адвоката дьявола и защитить такое решение.

Какие плюсы я вижу в раскрытии меню при наведении:

1. Не нужно кликать. Ну круто же! С пользователя снимается микронапряжение на клик мышки. Навёл на верхнеуровневый элемент — и сразу видно, что внутри.

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

Вот, пожалуй, и всё. На самом деле я категорически против таких решений.

Если мы реализуем раскрытие меню при наведении курсора, то входим в серую зону, потому что увеличиваем риск нарушения WCAG 1.4.13 Содержимое при наведении или фокусе (уровень AA) . Цель этого пункта — гарантировать, что вы реализуете взаимодействие при наведении таким образом, чтобы пользователь мог воспринимать дополнительный контент и отклонять его, не нарушая при этом работу со страницей.

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

Если верхнеуровневый пункт меню ещё и сам является ссылкой, то мы создаём элемент двойного назначения, тот самый «летающий танк», о котором говорила Лена.

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

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

Обещала рассказать, что там с клавиатурой у скринридеров – выполняю.

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

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

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

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

При переключении режимов в большинстве скринридеров слышен щелчок.


#разработка
#скринридер