Как проверить доступность,Как проверить доступность

Роб Додсон

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

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

Начните с клавиатуры

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

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

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

  • Пользовательские интерактивные элементы управления должны быть фокусируемыми. Если вы используете JavaScript, чтобы превратить <div> в необычный раскрывающийся список, он не будет автоматически вставлен в порядок табуляции. Чтобы сделать пользовательский элемент управления фокусируемым, присвойте ему tabindex="0" . Значения tabindex больше 0 изменяют порядок табуляции и могут сбить с толку пользователей программ чтения с экрана.

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

  • Если вы добавляете на страницу новый контент, сначала направьте внимание пользователя на этот контент, чтобы он мог выполнить с ним действие. Примеры см. в разделе «Управление фокусом на уровне страницы» .

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

Сделайте управление фокусом удобным

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

Управление закадровым контентом

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

Советы по работе с этими элементами см . в разделе «Обработка закадрового контента» .

Тестирование с помощью программы чтения с экрана

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

Если вы не знакомы с тем, как семантическая разметка интерпретируется вспомогательными технологиями, прочтите «Структура контента» .

  • Проверьте все изображения на наличие правильного alt текста. Исключением из этой практики являются случаи, когда изображения предназначены в первую очередь для презентационных целей и не являются важной частью контента. Чтобы указать, что программы чтения с экрана должны пропускать изображение, установите в качестве значения пустую строку: alt="" .
  • Проверьте все элементы управления на наличие метки. Для пользовательских элементов управления может потребоваться использование aria-label или aria-labelledby . Примеры см. в разделе «Метки и отношения ARIA» .
  • Проверьте все настраиваемые элементы управления на предмет соответствующей role и всех необходимых атрибутов ARIA, которые передают их состояние. Например, для пользовательского флажка требуется role="checkbox" и aria-checked="true|false" чтобы правильно передать его состояние. См. раздел «Введение в ARIA» , где представлен общий обзор того, как ARIA может предоставить недостающую семантику для пользовательских элементов управления.
  • Сделайте поток информации на вашей странице осмысленным. Поскольку программы чтения с экрана перемещаются по странице в порядке DOM, они будут объявлять любые элементы, которые вы визуально изменили с помощью CSS, в бессмысленном порядке. Если вам нужно, чтобы что-то появилось на странице раньше, физически переместите это раньше в DOM.
  • Стремитесь поддерживать навигацию программы чтения с экрана для всего содержимого на странице. Убедитесь, что никакие разделы сайта не скрыты навсегда и не заблокированы для доступа к программам чтения с экрана.
    • Если содержимое должно быть скрыто от программы чтения с экрана, например, если оно закадровое или просто презентационное, установите для этого содержимого значение aria-hidden="true" . Более подробное объяснение см. в разделе Скрытие контента .

Познакомьтесь с программами чтения с экрана

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

Если вы используете Mac, посмотрите это видео о VoiceOver — программе чтения с экрана, поставляемой с Mac OS. Если вы используете ПК, посмотрите это видео о NVDA , программе чтения с экрана с открытым исходным кодом для Windows, поддерживаемой пожертвованиями.

aria-hidden не предотвращает фокусировку клавиатуры

Важно понимать, что ARIA может влиять только на семантику элемента; это не влияет на поведение элемента. Вы можете сделать элемент скрытым для программ чтения с экрана с помощью aria-hidden="true" , ​​но это не изменит поведение фокуса для этого элемента. Для закадрового интерактивного содержимого. Для закадрового интерактивного содержимого используйте атрибут inert , чтобы убедиться, что оно действительно удалено из потока ввода с клавиатуры. Для старых браузеров объедините aria-hidden="true" с tabindex="-1" .

Интерактивные элементы должны указывать свое назначение и состояние.

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

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

Используйте заголовки и ориентиры

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

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

  • Используйте иерархию h1-h6 . Думайте о заголовках как об инструментах для создания структуры вашей страницы. Не полагайтесь на встроенные стили заголовков. Вместо этого обращайтесь с ними так, как если бы они были одинакового размера, и используйте семантически подходящий уровень для первичного, вторичного и третичного контента. Затем используйте CSS, чтобы заголовки соответствовали вашему дизайну.
  • Используйте ориентирные элементы и роли, чтобы пользователи могли обходить повторяющийся контент. Многие вспомогательные технологии предоставляют ярлыки для перехода к определенным частям страницы, например тем, которые определены элементами <main> или <nav> . Эти элементы имеют неявную роль ориентира. Вы также можете использовать атрибут role ARIA для явного определения регионов на странице, как в <div role="search"> . Дополнительные примеры см . в разделе «Семантика и навигация по контенту» .
  • Избегайте role="application" , если у вас нет опыта работы с ним. Роль ориентира application сообщает вспомогательным технологиям отключить ярлыки и передавать все нажатия клавиш на страницу. Это означает, что клавиши, которые пользователи программ чтения с экрана обычно используют для перемещения по странице, больше не работают, и вам придется самостоятельно реализовать всю работу с клавиатурой.

Просмотр заголовков и ориентиров с помощью программы чтения с экрана

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

Чтобы узнать больше, обратитесь к этим обучающим видеороликам по основам работы с VoiceOver и NVDA .

Автоматизируйте процесс

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

  • Проходит ли страница все тесты браузерных расширений Axe или WAVE ? Доступны и другие варианты, но эти расширения могут быть полезным дополнением к любому процессу ручного тестирования, поскольку они могут выявить такие тонкие проблемы, как неудовлетворительный коэффициент контрастности и отсутствие атрибутов ARIA.
    • Если вы предпочитаете работать в командной строке, axe-cli предоставляет те же функции, что и расширение браузера axe, но его можно запускать с вашего терминала.
  • Чтобы избежать регрессий, особенно в среде непрерывной интеграции, включите в свой набор автоматизированных тестов такую ​​библиотеку, как axe-core . axe-core — это тот же движок, который поддерживает расширение axe Chrome, но в утилите командной строки.
  • Если вы используете фреймворк или библиотеку, предоставляет ли она свои собственные инструменты обеспечения специальных возможностей? Например, плагин protractor-accessibility-plugin для Angular. По возможности используйте доступные инструменты.

Используйте Lighthouse для тестирования PWA

Lighthouse — это инструмент, который измеряет производительность вашего прогрессивного веб-приложения (PWA). И он использует библиотеку axe-core для проведения тестов доступности.

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

Дополнительные ресурсы