web.dev LIVE is now over! Head to web.dev/live to watch all the sessions, see top Q&A, and more.

Доступность для команд

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

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

Менеджер проекта

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

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

Обучение доступности

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

Вот несколько ресурсов, предоставляемыех Google:

Веб-доступность от Google — многонедельный интерактивный учебный курс.

Основы Доступности — письменные руководства по доступности и лучшие практики.

Руководства по Material: Доступность — набор лучших UX решений для инклюзивного дизайна.

Определение критических действий для пользователей

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

Primary user journey: A user can add an item to their shopping
cart.

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

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

Включение контрольного списка доступности

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

Есть ряд контрольных списков доступности, включая несколько примеров от индустрии:

Контрольный список WebAIM WCAG

Руководство по доступности Vox

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

A table with primary use cases as rows and checklist items as
columns.

Оценка с помощью пользовательских исследований

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

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

Дизайнер UX

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

  • Контент имеет достаточный цветовой контраст.
  • Порядок табуляции определён.
  • Элементы управления имеют доступные метки.
  • Существует множество способов взаимодействовать и понимать UI.

Контент имеет хороший цветовой контраст

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

Контраст измеряется путем сравнения яркости цвета переднего плана и фона. Для мелкого текста (что-либо ниже 18pt или 14pt полужирным шрифтом) рекомендуется минимальное соотношение 4.5:1. Для крупного текста это соотношение может быть отрегулировано до 3:1.

На картинке ниже текст слева соответствует этим минимальным контрастам, тогда как текст на правой стороне имеет низкий контраст.

Side-by-side text samples. One is sufficient contrast, one is low
contrast.

Существует ряд инструментов для измерения контраста, такие как Material Color Tool от Google, Приложение «Контрастность» от Lea Verou, и aXe от Deque.

Порядок табуляции определен

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

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

A design comp with interactive controls numbered.

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

Элементы управления имеют доступные метки

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

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

  • Будьте кратки - утомительно слушать длинные описания.
  • Старайтесь не включать тип или состояние элемента - Если элемент управления закодирован правильно, то программа чтения с экрана объявит об этом автоматически.
  • Фокусируйтесь на глаголах действия - Используйте "поиск", а не "лупа".

A design comp with controls marked with their accessible
labels.

Вы можете создать макет с помеченными элементами управления. Он может быть распространён среди ваших команд разработчиков и QA тестировщиков для реализации и тестирования.

Существует множество способов взаимодействовать и понимать UI

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

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

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

Разработчик

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

  • Порядок табуляции логичен.
  • Фокус правильно управляется и виден.
  • Интерактивные элементы поддерживают клавиатуру.
  • Применены ARIA роли и атрибуты, при необходимости.
  • Элементы помечены правильно.
  • Тестирование автоматизировано.

Логический порядок табуляции

Такие нативные элементы как input, button и select выбираются в порядке табуляции по умолчанию и автоматически получают фокус с клавиатуры. Но не все элементы ведут себя таким образом! В частности, общие элементы, такие как div и span не выбираются в порядке табуляции. Это значит, что если вы используете div для создания интерактивного элемента управления, вам нужно будет проделать дополнительную работу, чтобы сделать компонент доступным с клавиатуры.

Два варианта:

  • Установите для элемента атрибут tabindex="0". Это сделает элемент хотя бы фокусируемым, но вам все еще нужно делать дополнительную работу, чтобы ваш элемент поддерживал нажатие клавиш.
  • Подумайте об использовании button вместо div или span везде где, возможно, для любых элементов, похожих на кнопку. Нативный элемент button очень просто стилизовать и, вдобавок, вы совершенно бесплатно получаете поддержку клавиатуры.

Управление фокусом

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

Поддержка клавиатуры для интерактивных элементов

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

An excerpt from the ARIA Authoring Practices guide explaining how to build a
radio group.

Чтобы узнать больше о добавлении поддержки клавиатуры к элементу, взгляните на раздел передвигая tabindex в документах Основы Доступности от Google.

Роли и атрибуты ARIA применяются по мере необходимости

Мало того, что пользовательским элементам управления требуется надлежащая поддержка клавиатуры, так им еще нужна правильная семантика. В конце концов, div, семантически, это просто универсальный контейнер группировки. Если вы используете div как основу для вашего выпадающего меню, вам нужно будет положиться на дополнительный слой семантики ARIA, чтобы передавать тип элемента ассистивной технологии. Здесь вам сновам может помочь руководство Практика создания ARIA, чтобы определить какие роли, состояния и свойства вы должны использовать. В качестве дополнительного бонуса, множество объяснений в этом руководстве содержат примеры кода!

Маркировка элементов

Для маркировки нативных элементов вы можете использовать встроенный элемент <label>, как описано в MDN. Это не только поможет вам создать визуальное соответствие на экране, но и даст элементу доступное имя в дереве специальных возможностей. Это имя затем будет использовано ассистивными технологиями (как программа чтения с экрана) и объявлено пользователю.

К сожалению, <label> * не* поддерживает предоставление доступного имени для пользовательских элементов управления (как тех, что созданы с помощью Custom Elements, так и просто из divs и spans). Для такого рода элементов вам нужно использовать aria-label и aria-labelledby атрибуты.

Автоматическое тестирование

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

aXe, созданный Deque systems, доступен как Расширение для Chrome и Node модуль (хорошо подходит для систем непрерывной интеграции). Этот короткий эпизод A11ycast разъясняет как несколькими различными путями интегрировать aXe в ваш процесс разработки.

Lighthouse - это open source проект от Google для аудита ваших Прогрессивных Web-приложений. В дополнение к проверке, если ваше PWA поддерживает такие вещи как Сервис-воркер и Манифест веб-приложения, Lighthouse также запустит серию тестов лучших решений, включая тесты на проблемы доступности.

Вывод

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

Чтобы узнать больше о доступности не забудьте пройти наши бесплатные курсы на Udacity и исследуйте документы по доступности доступные здесь в Основах Веба.

Translated by