Как включить доступность в процесс вашей команды.
Сделать ваш сайт более доступным может оказаться непростой задачей. Если вы впервые занимаетесь вопросами доступности, сама широта темы может заставить вас задуматься, с чего начать. В конце концов, работа над учетом широкого спектра способностей означает, что необходимо учитывать соответственно разнообразный спектр вопросов.
Помните, доступность — это командная работа. У каждого человека есть своя роль. В этой статье излагаются критерии для каждой из основных дисциплин (менеджер проекта, UX-дизайнер и разработчик), чтобы они могли работать над внедрением лучших практик обеспечения специальных возможностей в свой процесс.
Руководитель проекта
Главной целью любого менеджера проекта является попытка включить работу по обеспечению доступности на каждом этапе; убедиться, что это такой же приоритет, как и другие темы, такие как производительность и удобство использования. Ниже приведены несколько пунктов контрольного списка, которые следует учитывать при работе над процессом.
- Сделайте обучение доступности доступным для команды.
- Определите критические пути пользователя на сайте или в приложении.
- Попробуйте включить контрольный список доступности в командный процесс.
- По возможности оценивайте сайт или приложение с помощью исследований пользователей.
Обучение доступности
Существует ряд отличных бесплатных ресурсов, позволяющих узнать о доступности Интернета. Если вы выделите время для вашей команды на изучение темы, вам будет проще включить доступность на ранних этапах процесса.
Некоторые ресурсы, предоставленные Google, включают:
Доступность веб-сайтов от Google — многонедельный интерактивный обучающий курс.
Основы доступности — письменные руководства по доступности и лучшие практики.
Рекомендации по материалам: Доступность — набор лучших практик UX для инклюзивного дизайна.
Определение критических путей пользователя
В каждом приложении есть какое-то основное действие, которое должен выполнить пользователь. Например, если вы создаете приложение для электронной коммерции, каждый пользователь должен иметь возможность добавить товар в свою корзину.
Некоторые действия могут иметь второстепенное значение и, возможно, выполняться лишь изредка. Например, изменение фотографии аватара — хорошая функция, но не всегда критичная.
Определение основных и второстепенных действий в вашем приложении поможет вам расставить приоритеты в предстоящей работе по обеспечению специальных возможностей. Позже вы можете объединить эти действия с контрольным списком доступности, чтобы отслеживать свой прогресс и избегать регрессов.
Включение контрольного списка доступности
Тема доступности довольно широка, поэтому наличие контрольного списка важных областей, которые следует учитывать, может помочь вам убедиться, что вы охватываете все свои базы.
Существует ряд контрольных списков доступности, вот несколько отраслевых примеров:
Контрольный список WebAIM WCAG Рекомендации по обеспечению доступности Vox
Имея на руках контрольный список, вы можете просмотреть свои основные и второстепенные действия, чтобы определить, какую работу еще необходимо выполнить. Вы можете подойти к этому процессу довольно тактично и даже построить матрицу первичных и вторичных действий и определить для каждого шага этих процессов, есть ли недостающие биты доступности.
Оценка с помощью исследований пользователей
Нет ничего лучше, чем посидеть с реальными пользователями и наблюдать за тем, как они пытаются использовать ваше приложение. Если вы адаптируете специальные возможности к существующему интерфейсу, этот процесс может помочь вам быстро определить области, требующие улучшения. А если вы начинаете новый проект, раннее изучение пользователей может помочь вам не тратить слишком много времени на разработку функции, которую сложно использовать.
Стремитесь учитывать отзывы как можно более разнообразных пользователей. Рассмотрим пользователей, которые в основном перемещаются с помощью клавиатуры или полагаются на вспомогательные технологии, такие как программы чтения с экрана или экранные лупы.
UX-дизайнер
Поскольку люди склонны проектировать, используя свои собственные предубеждения, если у вас нет инвалидности и нет коллег с ограниченными возможностями, вы можете непреднамеренно разрабатывать дизайн только для некоторых из ваших пользователей. Во время работы задайте себе вопрос: «Какие типы пользователей могут положиться на этот дизайн?» Вот несколько методов, которые вы можете попробовать, чтобы сделать ваш процесс более инклюзивным.
- Контент имеет достаточный цветовой контраст.
- Порядок табуляции определен.
- Элементы управления имеют доступные метки.
- Существует несколько способов взаимодействия с пользовательским интерфейсом.
Контент имеет хороший цветовой контраст
Основная цель большинства сайтов — передать пользователю некоторую информацию посредством письменного текста или изображений. Однако если этот контент имеет низкую контрастность, некоторым пользователям (особенно людям с нарушениями зрения) может быть трудно его прочитать. Это может негативно повлиять на их пользовательский опыт. Чтобы решить эту проблему, постарайтесь, чтобы весь текст и изображения имели достаточный цветовой контраст.
Контрастность измеряется путем сравнения яркости цвета переднего плана и фона. Для меньшего текста (все, что меньше 18 пунктов или 14 пунктов жирным шрифтом) рекомендуется минимальное соотношение 4,5:1. Для более крупного текста это соотношение можно изменить до 3:1.
На изображении ниже текст слева соответствует этим минимумам контрастности, тогда как текст справа имеет низкую контрастность.
Существует ряд инструментов для измерения цветового контраста, таких как Material Color Tool от Google, приложение Contrast Ratio от Lea Verou и топор Deque.
Порядок табуляции определен
Порядок табуляции — это порядок, в котором элементы получают фокус, когда пользователь нажимает клавишу табуляции. Для пользователей, которые перемещаются в основном с помощью клавиатуры, клавиша табуляции является основным средством доступа ко всему на экране. Думайте об этом как о курсоре мыши.
В идеале порядок табуляции должен соответствовать порядку чтения и идти от верхней части страницы к нижней, при этом более важные элементы располагаются выше в порядке. Это делает более эффективным быстрый доступ к этим элементам для тех, кто использует клавиатуру.
Макет интерфейса выше пронумерован, чтобы показать порядок табуляции. Создание подобного макета может помочь определить предполагаемый порядок табуляции. Затем этим можно поделиться с разработчиками и тестировщиками QA, чтобы убедиться, что оно правильно реализовано и протестировано.
Элементы управления имеют доступные метки
Для пользователей вспомогательных технологий, таких как программы чтения с экрана, метки предоставляют информацию, которая в противном случае была бы только визуальной. Например, кнопка поиска, представляющая собой просто значок лупы, может иметь доступную метку «Поиск», чтобы помочь заполнить недостающие визуальные возможности.
Вот несколько простых советов, которым следует следовать при разработке доступных этикеток:
- Будьте кратки. Слушать длинные описания может быть утомительно.
- Старайтесь не указывать тип или состояние элемента управления. Если элемент управления закодирован правильно, программа чтения с экрана сообщит об этом автоматически.
- Сосредоточьтесь на глаголах действия. Используйте «поиск», а не «лупу».
Вы можете рассмотреть возможность создания макета с маркировкой всех ваших элементов управления. Этим файлом можно поделиться с вашей командой разработчиков и командой контроля качества для реализации и тестирования.
Несколько способов взаимодействия и понимания пользовательского интерфейса.
Несложно предположить, что все пользователи взаимодействуют со страницей преимущественно с помощью мыши. При проектировании подумайте, как кто-то будет взаимодействовать с элементом управления с помощью клавиатуры.
Планируйте свои состояния фокуса! Это означает определение того, как будет выглядеть элемент управления, когда пользователь фокусирует его с помощью табуляции или нажимает клавиши со стрелками. Полезно заранее спланировать эти состояния, а не пытаться втиснуть их в проект позже.
Наконец, в любой точке взаимодействия вы должны убедиться, что у пользователя есть несколько способов понимания контента. Старайтесь не использовать только цвет для передачи информации, так как эти тонкие сигналы могут быть пропущены пользователем с нарушением цветового зрения. Классический пример — недопустимое текстовое поле. Вместо красного подчеркивания, обозначающего проблему, рассмотрите возможность добавления вспомогательного текста. Таким образом вы охватите больше баз и увеличите вероятность того, что пользователь заметит проблему.
Разработчик
Роль разработчика заключается в том, чтобы объединить управление фокусом и семантику для формирования надежного пользовательского опыта. Ниже приведены несколько моментов, которые разработчики могут учитывать при работе над своим сайтом или приложением:
- Порядок табуляции логичен.
- Фокус правильно управляется и виден.
- Интерактивные элементы имеют поддержку клавиатуры.
- Роли и атрибуты ARIA применяются по мере необходимости.
- Элементы промаркированы правильно.
- Тестирование автоматизировано.
Логический порядок табуляции
Нативные элементы, такие как input , button и select , бесплатно включаются в порядок табуляции и автоматически фокусируются с помощью клавиатуры. Но не все элементы ведут себя одинаково! В частности, общие элементы, такие как div и span , не включаются в порядок табуляции. Это означает, что если вы используете div для создания интерактивного элемента управления, вам придется проделать дополнительную работу, чтобы сделать его доступным с клавиатуры.
Два варианта:
- Присвойте элементу управления
tabindex="0". Это, по крайней мере, сделает его фокусируемым, хотя вам, вероятно, придется проделать дополнительную работу, чтобы добавить поддержку нажатий клавиш. - Там, где это возможно, рассмотрите возможность использования
buttonвместо элементаdivилиspanдля любого элемента управления, подобного кнопке. Собственный элементbuttonочень легко стилизовать и бесплатно поддерживает клавиатуру.
Управление фокусом
Когда вы меняете содержимое страницы, важно направить внимание пользователя, перемещая фокус. Классический пример полезности этого метода — открытие модального диалога. Если пользователь, полагающийся на клавиатуру, нажимает кнопку, чтобы открыть диалоговое окно, и его фокус не перемещается на элемент диалогового окна, тогда его единственное действие — перемещаться по всему сайту, пока он в конечном итоге не найдет новый элемент управления. Перемещая внимание на новый контент сразу после его появления, вы можете повысить эффективность работы этих пользователей.
Поддержка клавиатуры для интерактивных элементов
Если вы создаете собственный элемент управления, например карусель или раскрывающийся список, вам потребуется проделать дополнительную работу, чтобы добавить поддержку клавиатуры. ARIA Authoring Practices Guide — это полезный ресурс, в котором указаны различные шаблоны пользовательского интерфейса и типы действий с клавиатуры, которые они должны поддерживать.
Чтобы узнать больше о добавлении поддержки клавиатуры к элементу, ознакомьтесь с разделом перемещающегося табиндекса в документации Google по основам специальных возможностей.
Роли и атрибуты ARIA применяются по мере необходимости.
Пользовательские элементы управления нуждаются не только в правильной поддержке клавиатуры, но и в правильной семантике. В конце концов, семантически div — это всего лишь общий контейнер группировки. Если вы используете элемент div в качестве основы для раскрывающегося меню, вам придется полагаться на ARIA для добавления дополнительной семантики, чтобы тип элемента управления можно было передать вспомогательным технологиям. И здесь руководство ARIA Authoring Practices Guide может помочь, определив, какие роли, состояния и свойства вам следует использовать. В качестве дополнительного бонуса многие пояснения в руководстве ARIA также сопровождаются примерами кода!
Элементы маркировки
Для маркировки собственных входных данных вы можете использовать встроенный элемент <label> , как описано в MDN. Это не только поможет вам создать визуальную возможность на экране, но также придаст вводу доступное имя в дереве доступности. Затем это имя распознается вспомогательными технологиями (например, программой чтения с экрана) и объявляется пользователю.
К сожалению, <label> не поддерживает присвоение доступного имени пользовательским элементам управления (например, созданным с использованием пользовательских элементов или из простых элементов управления и диапазонов). Для такого рода элементов управления вам понадобятся атрибуты aria-label и aria-labelledby .
Автоматизированное тестирование
Лениться может быть полезно, особенно когда дело касается тестирования. По возможности постарайтесь автоматизировать тесты доступности, чтобы вам не приходилось делать все вручную. Сегодня существует ряд отличных инструментов отраслевого тестирования, позволяющих легко и быстро выявлять распространенные проблемы доступности:
aXe, созданный Deque Systems, доступен в виде расширения Chrome и модуля Node (подходит для сред непрерывной интеграции). В этом коротком сообщении A11ycast объясняется несколько различных способов включения Axe в процесс разработки.
Lighthouse — это проект Google с открытым исходным кодом для аудита производительности ваших прогрессивных веб-приложений. Помимо проверки наличия у вашего PWA поддержки таких вещей, как Service Worker и манифест веб-приложения , Lighthouse также выполнит серию тестов передового опыта, включая тесты на проблемы доступности.
Заключение
Доступность — это командная работа. У каждого есть своя роль. В этом руководстве изложено несколько ключевых моментов, которые каждый член команды может использовать, чтобы быстро освоить предмет и, надеюсь, улучшить общее впечатление от своего приложения.
Чтобы узнать больше о специальных возможностях, обязательно посетите наш бесплатный курс Udacity и просмотрите документацию по специальным возможностям, доступную здесь, на сайте web.dev.