Проектирование доступных продуктов

Исчерпывающее визуальное руководство, позволяющее сделать веб-технологии доступными для всех

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

Доступность – возможность достигнуть или получить.

Что такое доступность и почему она важна?

В таком разнородном мире, как наш, мы не можем просто предположить, что все пользователи получают одинаковый доступ к цифровым продуктам. Именно тогда доступность становится решающим элементом дизайн-процесса, который включает в себя и разнообразие мнений. Доступный продукт – в его простейшем смысле это убедиться, что все ваши пользователи смогут потреблять ваш контент. Продукты, над которыми мы работаем, разработаны с учетом предполагаемого большинства наших пользователей – пользователей, которые не испытывают никаких трудностей с использованием веб-приложений или мобильных приложений. Во многих случаях очень мало внимания уделяется проектированию компонентов для большинства продуктов, которые работают практически для любого пользователя - будь у кого-то сломанная рука, или кто-то плохо слышит, или кто-то с нарушениями зрения. Углубимся в статистику доступности. Было установлено, что почти 56,7 млн. американцев, что составляет 18,7% от населения США, имеют инвалидность. Из этого числа было обнаружено, что 38,3 млн. человек страдают серьезными нарушениями. Это составляет 12,6% от всего населения США. Эти цифры относятся к 2012 году и касаются только одной страны. При увеличении всего населения мира эти цифры достигнут тревожной точки, и это уже не будет вопрос “меньшей части пользователей”.

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

Скошенные бордюры. Фото: http://www.virginiadot.org/projects/northernvirginia/ada\_sidewalk\_ramps.asp Пандусы предназначены помочь людям в инвалидной коляске передвигаться по городу. У них также есть множество других применений – родители, гуляющие по улицам с колясками, люди, использующие тротуар, чтобы кататься на коньках и т.д. Push to open двери. Фото: http://accessandmobilityinc.com/our-products/power-door-openers/ Кнопки “Нажать, чтобы открыть” (Push to open) были установлены в большинстве зданий, чтобы помочь людям в инвалидных колясках открывать двери. Эти кнопки также используют люди, чтобы открыть двери, когда они несут много сумок или ребенка, или просто используют их все время, потому что это легче, чем толкать или тянуть за ручку двери. Раздел 508 Закона предписывает, чтобы федеральные агентства имели свои цифровые / электронные приложения, доступные для людей с ограниченными возможностями. Компании имеют минимально необходимый уровень соответствия на основе WCAG, чтобы помочь людям с ограниченными возможностями пользоваться их продуктами намного проще.

Помимо законов и правил, разве это не люди, кто должен следить за тем, чтоб наши продукты широко использовались?

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

Текущее состояние вспомогательных технологий

Прежде чем углубляться в шаблоны, делать и не делать это, необходимо понять, как работают существующие вспомогательные технологии для работы в Интернете. Mac OS поставляется с VoiceOver, а пользователи Windows могут использовать NVDA (NonVisual Desktop Access).

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

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

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

1. Цветовой контраст

Первый шаг к доступному пользовательскому интерфейсу – установить цветовой контраст для вашего продукта. Рекомендуемый контраст для веб-приложений.

Рекомендуемый контраст 3:1 для большого текста и 4.5:1 для маленького текста.

Что это значит? Читабельность, созданная из разницы цвета переднего плана и фона – это контраст. Большой текст – любой шрифт размером больше 18px, когда это жирный шрифт, или больше 24px для обычного шрифта. Маленький текст – это любой шрифт меньше 18px. Инструменты, которые помогут проверить контраст Color Safe – отличный инструмент, если вы начинаете новый проект и хотите заранее выяснить, какие цвета обеспечивают доступность. Тем не менее, продукты, над которыми мы работаем, уже имеют утвержденный цветной справочник или набор цветов бренда на выбор. В таких случаях важно найти контрастность цветов из палитры продукта. WebAim – это самый лучший инструмент для таких проверок. Быстрое определение областей для улучшения контраста Даже процесс проверки в WebAim всех комбинаций для фона и переднего плана может быть непростой задачей. Есть быстрый способ получить представление о возможных проблемах в вашем дизайне. Это отличный инструмент Chrome, который называется Color Contrast Analyzer, разработанный замечательными людьми в NCSU. Из этого быстрого анализа видно, что субтитры в каждой из этих статей имеют плохие показатели контрастности и можно было бы провести работу, чтобы сделать страницу доступной. Это быстро определяет области, требующие работы на экране. Области на экране с хорошим контрастом, подсвечиваются белыми линиями, а области с плохим контрастом имеют тонкие очертания, которые не очень заметны.

2. Фокус

Фокус – одна из наиболее важных функций доступности, которая позволяет пользователям использовать компьютер только с клавиатурой без мыши. Большинство таблиц стилей сброса имеют эту одну строку кода, которая вызывает большой сбой доступности - :focus { outline: 0; } Это анти-паттерн, которого нужно избегать, как чумы. Пользователи только с клавиатурой знают, какие элементы на странице взаимодействуют с помощью стилей фокусировки.

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

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

Контраст фокуса

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

Скрытый контент

Когда не отображаемый контент скрыт от области просмотра, он существует в форме гамбургер-меню, модальных окон и т.д. Вероятно, когда пользователи перемещаются по точкам фокусировки, они теряют фокус, поскольку он выделяет то, что за пределами рабочей зоны. Это может привести к путанице и заставить пользователей терять контроль над своим текущим положением на экране. Слева: Что видят пользователи, когда они перемещаются по скрытым элементам. Справа: Реальное положение фокуса. Когда меню закрыто, поток фокуса путает пользователя. Рекомендуемое решение: Один из способов решения этой проблемы либо скрыть элементы, когда меню закрыто с помощью CSS с display: none, либо убедиться, что фокус не входит в меню при свертывании, программным образом изменяя поток фокуса с помощью JavaScript.

Модальные окна

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

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

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

Наведение и фокус

Наведение и фокус имеют разные функциональные возможности. У многих продуктов есть действия, скрытые до наведения на них курсора. Хороший пример наведения – это реакции на Facebook. У Facebook есть действия в режимах наведения. Они отлично работают над тем, чтобы выделить их в фокусе, делая его доступным для пользователей, пользующихся только клавиатурой. Плохой пример – это карточки Product Hunt. Они показывают несколько действий, которые становятся видимыми только при наведении курсора, что недоступно для пользователей, использующих только клавиатуру. Product Hunt, с другой стороны, имеет определенные действия (выделены выше), которые появляются при наведении. Эти действия не видны в фокусе и затрудняют выполнение этих действий пользователями только с клавиатурой. Слева: Фокус игнорируется при наведении и переходе к следующему элементу фокуса. Справа: Состояния фокуса, позволяющие пользователям выполнять действия, скрытые в состоянии наведения курсора мыши.

Сценарии “перемещения фокуса”

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

3. Клик по целевым областям

Карточки

Карточки в настоящее время очень активно используются в продуктах. Благодаря материальному дизайну, существует много структур и руководств относительно того, как следует проектировать карточки. Однако, важно создавать доступные карточки. Карточки могут быстро усложняться с несколькими состояниями, в зависимости от типа взаимодействия с ними. Другим плохим примером карточного дизайна являются карточки, используемые на странице Product Hunt (извините, ребята, я очень люблю Product Hunt, но это похоже  подходящий пример). Представьте, что пользователь перемещается по этим карточкам без использования мыши. Можно ли определить, какая карточка фокусируется? Если вы присмотритесь, вы поймете, что это вторая карточка. Это трудно определить даже для людей с совершенным зрением. Google Inbox – отличный пример того, как карточки можно сделать доступными. ☑ Они назначают определенные состояния фокусировки для карточек, когда они служат для навигации. ☑ Действия при наведении курсора совершаются, когда в фокусе. ☑ Только объекты действия сфокусированы, а не каждый элемент в карточке.

Целевые области

Пользователям с нарушением двигательной функции трудно точно выделять элементы на странице. Наша задача, как дизайнеров, убедиться, что целевые области не слишком узкие или труднодоступные. Слева: Очень узкие целевые области для клика. Справа: Значительно лучшие целевые области для клика.

4. Быстрый доступ к контенту

Допустим вы пользователь, проводящий навигацию только с клавиатуры, и вы хотите сразу перейти к контенту. Но есть большая вероятность, что вы столкнетесь с несколькими пунктами меню или другими навигационными элементами прежде, чем вы, действительно, сможете добраться до содержания продукта. Для пользователей может быть затруднительно проверить каждую из этих ссылок, прежде чем они могут получить представление о продукте. Ниже приведен пример плохого опыта с очень известной блоговой платформы. Пользователю приходится переходить по нескольким ссылкам, прежде чем он сможет перейти к содержимому страницы. Одно из возможных решений этой проблемы – предоставить пользователям быстрый переход к контенту по мере перехода к табуляции через продукт. Ниже приведен пример того, как AirBnB достигает этого. Слева: До того, как пользователь сфокусируется. Справа: Функция “Перейти к содержанию”, чтобы пользователи могли перейти непосредственно к контенту, вместо того, чтобы перемещаться по каждому элементу меню.

5. Обобщение информации

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

1. Бронирование билетов на самолет.
2. Поиск после фильтрации с кучей опций.
3. Добавление товаров в корзину и их проверка.

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

Это правило применимо к компонентам пользовательского интерфейса, таким как выбор даты, степперы или мастер установки и т.д. Это особенно сложно, потому что вы не хотите, чтобы избыточная информация была видна пользователям, не требующим специальных возможностей. Рекомендуемое решение: Когда пользователи нажимают на информацию, могут быть элементы, которые я бы назвал “Призрачные элементы”, которые отображаются только тогда, когда пользователь нажимает на сложные компоненты пользовательского интерфейса, такие как выбор даты (date pickers). Эти элементы-призраки содержат краткое описание выбранного значения, которое программа чтения с экрана может считывать для подтверждения. Краткий обзор выбранных значений в сложных полях ввода, таких как выбор даты, предоставляется пользователю, который выполняет табуляцию через интерфейс. Такой подход обычно критикуют, так как опытные пользователи, которые быстрее перемещаются с помощью клавиатуры, должны будут дважды прокручивать вкладку, чтобы перейти к следующему элементу. Вот тогда-то и появляется переключатель доступности.

6. Переключатель доступности

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

Мысли в заключение

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

---

Перевод статьи Adhithya