Have a voice in guiding the future of Google's developer brands. Share your thoughts in our survey.

Как Сделать Обзор Доступности

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

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

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

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

Ключевые моменты

  • Начните переход по вашему сайту с помощью табуляции. Порядок, в котором элементы попадают в фокус должен стремиться следовать порядку элементов DOM. Если вы не уверены какой элемент должен получить фокус, смотрите Основы фокуса чтобы освежить знания. Общее правило такое, что любой элемент, с которым пользователь может взаимодействовать или такой, что позволяет вводить данные должен быть фокусируемым и отображать индикатор фокуса (например, кольцо фокуса). Существует практика выключения стилей фокуса без предоставления альтернативы, с помощью outline: none в CSS, но это антипаттерн. Если пользователи клавиатуры не видит что сейчас в фокусе, они не смогут взаимодействовать со страницей. Если вам нужно разделить стили для фокусировки мышью и клавиатурой, то вам следует рассмотреть добавление библиотеки типа what-input.

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

  • Избегайте элементов управления с tabindex > 0. Эти элементы будут прыгать вперед всего остального в порядке табуляции, независимо от их положения в DOM. Это может быть сбивающим с толку для пользователей программ чтения с экрана, поскольку они, как правило, ориентируются по DOM линейным образом.

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

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

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

Просто потому, что что-то фокусируемо, это не значит, что оно полезно

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

Не забывайте о том, что за пределами экрана

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

Попробуйте это с программой чтения с экрана

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

Ключевые моменты

  • Проверьте правильность текста alt на всех элементах. Исключением служат изображения предназначенные для презентационных целей и не являются важной частью контента. Чтобы показать, что изображение должно быть пропущено программой чтения с экрана установите значением атрибута 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. Если же вы пользователь ПК посмотрите это видео использования NVDA, поддерживаемая на пожертвования, open source программа чтения с экрана для Windows.

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

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

Интерактивные элементы как ссылки и кнопки должны отображать их цель и состояние

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

Ключевые моменты

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

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

Пользуйтесь заголовками и ориентирами

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

Ключевые моменты

  • Правильно испольуйте h1-h6 иерархию. Думайте о заголовках как об инструментах создания структуры страницы. Не опирайтесь на встроенные стили заголовков; вместо этого рассматривайте все заголовки как если бы они были одного размера и используйте семантически соответствующий уровень первичного, вторичного и третичного контента. Затем используйте CSS чтобы задать заголовками стили вашего дизайна.

  • Используйте ориентиры и роли так, чтобы пользователи могли повторно обойти весь контент. Множество ассистивных технологий предоставляют горячие клавиши для прыжков к определённым частям страницы, таким как элементы <main> или <nav>. Эти элементы имеют неявные роли ориентиров. ВЫ можете также использовать ARIA атрибут role, чтобы явно определить области на странице, например <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 и a11ysuite для Polymer и веб-компонентов. По возможности используйте имеющиеся инструменты, чтобы не изобретать свой велосипед.

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

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

Завершение

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

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

- Основные доступности

A11ycasts

Feedback

Was this page helpful?
Yes
What was the best thing about this page?
It helped me complete my goal(s)
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It had the information I needed
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It had accurate information
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It was easy to read
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
Something else
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
No
What was the worst thing about this page?
It didn't help me complete my goal(s)
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It was missing information I needed
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It had inaccurate information
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It was hard to read
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
Something else
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.