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

Как интегрировать доступность в рабочие процессы вашей команды.

Rob Dodson

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

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

Руководитель проекта

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

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

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

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

Некоторые ресурсы, предоставляемые Google, включают:

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

Основы доступности — письменные руководства и передовой опыт по обеспечению доступности.

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

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

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

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

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

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

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

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

Контрольный список WebAIM WCAG Рекомендации по обеспечению доступности Vox

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

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

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

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

UX-дизайнер

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

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

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

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

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

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

Существует ряд инструментов для измерения цветового контраста, например, Material Color Tool от Google, приложение Contrast Ratio от Lea Verou и aXe от Deque.

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

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

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

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

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

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

Вот несколько простых советов, которым следует следовать при разработке доступных этикеток:

• Будьте лаконичны. Слушать длинные описания может быть утомительно.
• Постарайтесь не указывать тип или состояние элемента управления — если элемент управления закодирован правильно, программа чтения с экрана автоматически объявит об этом.
• Сосредоточьтесь на глаголах действия — используйте «поиск», а не «увеличительное стекло».

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

Множество способов взаимодействия с пользовательским интерфейсом и его понимания

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

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

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

Разработчик

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

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

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

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

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

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

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

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

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

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

Чтобы узнать больше о добавлении поддержки клавиатуры к элементу, ознакомьтесь с разделом о перемещаемом tabindex в документации Google по основам доступности.

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

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

Элементы маркировки

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

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

Автоматизированное тестирование

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

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

Lighthouse — это проект Google с открытым исходным кодом для аудита производительности ваших Progressive Web Apps. Помимо проверки того, поддерживает ли ваш PWA такие вещи, как Service Worker и Web App Manifest , Lighthouse также проведет ряд тестов на соответствие лучшим практикам, включая тесты на проблемы доступности.

Заключение

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

Чтобы узнать больше о доступности, обязательно ознакомьтесь с нашим бесплатным курсом Udacity и просмотрите документацию по доступности, доступную здесь на web.dev.

Как интегрировать доступность в рабочие процессы вашей команды.

Rob Dodson

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

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

Руководитель проекта

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

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

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

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

Некоторые ресурсы, предоставляемые Google, включают:

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

Основы доступности — письменные руководства и передовой опыт по обеспечению доступности.

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

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

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

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

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

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

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

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

Контрольный список WebAIM WCAG Рекомендации по обеспечению доступности Vox

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

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

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

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

UX-дизайнер

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

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

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

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

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

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

Существует ряд инструментов для измерения цветового контраста, например, Material Color Tool от Google, приложение Contrast Ratio от Lea Verou и aXe от Deque.

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

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

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

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

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

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

Вот несколько простых советов, которым следует следовать при разработке доступных этикеток:

• Будьте лаконичны. Слушать длинные описания может быть утомительно.
• Постарайтесь не указывать тип или состояние элемента управления — если элемент управления закодирован правильно, программа чтения с экрана автоматически объявит об этом.
• Сосредоточьтесь на глаголах действия — используйте «поиск», а не «увеличительное стекло».

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

Множество способов взаимодействия с пользовательским интерфейсом и его понимания

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

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

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

Разработчик

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

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

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

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

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

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

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

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

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

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

Чтобы узнать больше о добавлении поддержки клавиатуры к элементу, ознакомьтесь с разделом о перемещаемом tabindex в документации Google по основам доступности.

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

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

Элементы маркировки

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

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

Автоматизированное тестирование

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

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

Lighthouse — это проект Google с открытым исходным кодом для аудита производительности ваших Progressive Web Apps. Помимо проверки того, поддерживает ли ваш PWA такие вещи, как Service Worker и Web App Manifest , Lighthouse также проведет ряд тестов на соответствие лучшим практикам, включая тесты на проблемы доступности.

Заключение

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

Чтобы узнать больше о доступности, обязательно ознакомьтесь с нашим бесплатным курсом Udacity и просмотрите документацию по доступности, доступную здесь на web.dev.