Доступность контента¶
Что такое доступность контента?¶
Доступность контента — это специальные технические и архитектурные решения, которые помогают людям с ограниченными возможностями использовать сайты. Применение таких решений необходимо для интерпретации страниц техническими средствами реабилитации, встроенными в операционные системы и браузеры. Термин «доступность контента» также может обозначаться аббревиатурой a11y.
React поддерживает создание сайтов c доступным контентом в том числе с помощью стандартных возможностей HTML.
Стандарты и руководства¶
Руководство по обеспечению доступности контента (WCAG)¶
Руководство по обеспечению доступности контента (WCAG), разработанное консорциумом W3C, описывает рекомендации по созданию сайтов с доступным контентом.
Также есть ресурсы с чек-листами требований WCAG, например:
Доступность контента в веб-приложениях (WAI-ARIA)¶
Свод правил по доступности контента в веб-приложениях (WAI-ARIA) — это документ, который посвящён реализации требований доступности контента при разработке JavaScript-программ и компонентов.
Нужно отметить, что все HTML-атрибуты aria-*
полностью поддерживаются в JSX. Несмотря на то, что большинство DOM-свойств и атрибутов в React пишутся в стиле camelCase, атрибуты aria-*
должны быть написаны с разделением дефисами. Такой стиль ещё известен как шашлычная нотация (kebab-case) или в стиле языка Лисп (lisp-case). Вот как выглядит такое оформление в JSX:
1 2 3 4 5 6 7 8 |
|
Семантическая вёрстка¶
Семантическая вёрстка — это основа доступности контента в веб-приложениях. Используя различные HTML-элементы можно улучшить восприимчивость и понятность ваших сайтов. Это позволяет сделать контент доступным без особых усилий.
Бывают случаи, когда семантическая вёрстка нарушается. Например, при добавлении элемента <div>
в JSX для обеспечения работоспособности кода на React. Особенно часто это случается при работе со списками (<ol>
, <ul>
, <dl>
) или таблицами (<table>
). В такой ситуации рекомендуется использовать фрагменты, чтобы сгруппировать элементы, как это показано в примере:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
Коллекцию элементов можно преобразовать в массив фрагментов или любых других элементов:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
Если нет необходимости использовать пропсы, то можно применять сокращённую запись фрагментов:
1 2 3 4 5 6 7 8 |
|
Обратите внимание, что не все инструменты поддерживают сокращённую запись. Подробности в документации фрагментов.
Доступность контента в формах¶
Подписи¶
Каждый элемент управления, например, <input>
или <textarea>
, должен иметь подпись, обеспечивающую доступность контента. Подписи нужно выполнять так, чтобы их могли использовать экранные считывающие устройства и другие технические средства реабилитации.
Вот рекомендации о том, как это делать:
- демонстрация подписи элементов от консорциума W3C
- демонстрация подписи элементов от WebAIM
- разъяснения от Paciello Group по доступности наименований
Эти стандартные для HTML способы могут использоваться в React напрямую, однако не забывайте, что атрибут for
в JSX записывается как htmlFor
:
1 2 |
|
Сообщения об ошибках¶
Необходимо, чтобы ошибки и их причины были понятны всем пользователям. Далее приведены ресурсы, которые демонстрируют, как правильно воспроизводить текст сообщений об ошибках с помощью экранных считывающих устройств:
Управление фокусом¶
Приложение с доступным контентом должно функционировать при использовании только клавиатуры. Убедитесь соответствует ли ваше приложение этому требованию:
Фокус клавиатуры и контур элемента¶
Фокус клавиатуры указывает на тот элемент в структуре DOM, который в данный момент готов принимать ввод с клавиатуры. Обычно такой элемент выделяется контуром, как это показано на рисунке:
Если вы заменяете стандартную реализацию фокуса своей, удалить контуры элементов можно с помощью CSS, установив outline: 0
.
Механизмы быстрого перехода к нужному контенту¶
Также на сайте нужно реализовать механизмы, которые помогают пользователям быстро переходить к нужному контенту с помощью клавиатуры.
Ссылки для быстрого перехода — это скрытые навигационные ссылки, которые становятся видимыми, когда пользователи взаимодействуют со страницей с помощью клавиатуры. Такие ссылки очень легко сделать, используя внутренние якоря страницы и CSS:
Элементы семантической вёрстки, например, <main>
или <aside>
, нужно использовать в качестве секционной разметки, предназначенной для быстрого перехода между логическими частями сайта.
Узнать больше о применении секционной разметки для улучшения доступности контента можно здесь:
Программное управление фокусом¶
React-приложения во время своей работы постоянно изменяют структуру DOM. Иногда из-за этого фокус клавиатуры может быть потерян или может перейти на неправильный элемент. Чтобы исправить такую ситуацию, нужно запрограммировать перевод фокуса клавиатуры на нужный элемент. Например, после закрытия модального окна перевести фокус клавиатуры на кнопку, которая его открыла.
В статье MDN (рус.) рассматриваются способы навигации с клавиатуры в JavaScript.
Чтобы управлять фокусом в React, можно использовать рефы на DOM-элементы.
При таком подходе мы сначала создаём в классе компонента реф на элемент в JSX:
1 2 3 4 5 6 7 8 9 10 11 12 |
|
Теперь при необходимости можно установить фокус на этот элемент из любого места компонента:
1 2 3 4 5 |
|
Иногда родительскому компоненту нужно установить фокус на элемент дочернего компонента. Мы можем сделать это с помощью рефа на родительский компонент, который присваивается специальному свойству дочернего компонента и используется для ссылки из родительского компонента на DOM-элемент дочернего.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
Если для расширения функциональности компонент оборачивается компонентом высшего порядка, то рекомендуется перенаправлять рефы обёрнутого компонента с помощью React-функции forwardRef
. В случае, когда сторонний HOC не поддерживает перенаправление рефов, описанный выше подход всё равно можно использовать в качестве запасного варианта.
Отличный пример управления фокусом показан в проекте react-aria-modal. Этот достаточно редкий случай реализации модального окна с полностью доступным контентом. В нём, кроме установки фокуса на кнопку отмены и перемещения фокуса внутри модальной формы, сделан возврат на элемент, инициировавший вызов модального окна. Нужно отметить, что первоначальная установка фокуса на кнопку отмены в модальном окне предотвращает случайное нажатие на клавиатуре кнопки подтверждения запрашиваемого действия.
Примечание:
Правильное управление фокусом — это важный момент в обеспечении доступности контента, однако стоит применять его с умом. Используйте управление фокусом для восстановления нарушенной последовательности действий при работе с клавиатурой. Не стоит предугадывать желания пользователя и подталкивать его к каким-либо действиям в приложении.
Работа с событиями мыши¶
Позаботьтесь, чтобы вся функциональность, связанная с событиями мыши, была доступна при работе только с клавиатурой. Если приложение сильно зависит от действий мыши, многие пользователи, которые используют только клавиатуру, не смогут работать с ним.
Чтобы продемонстрировать это, рассмотрим подробный пример, когда доступность контента нарушается из-за ориентации только на щелчок мыши. В примере показан паттерн закрытия всплывающего списка при щелчке мышью за пределами этого элемента.
Обычно такая функциональность реализуется событием click
объекта window
, обработчик которого закрывает выпадающий список:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 |
|
Такой подход хорош для тех, кто использует мыши, тачпады или другие координатные устройства, однако для пользователей, работающих только с клавиатурой, он может стать причиной нарушения работы программы при попытке перехода к следующему элементу с помощью клавиши Tab
. Причиной этого является то, что в данной ситуации объект window
никогда не получит событие click
. В итоге мы имеем заблокированную функциональность и невозможность продолжения работы с приложением.
Подобное поведение можно получить используя обработчики сопутствующих событий, например, onBlur
или onFocus
:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 |
|
С этой программой можно работать и с помощью клавиатуры, и с помощью координатного устройства. Также в неё добавлены атрибуты aria-*
для людей, использующих экранные считывающие устройства. Для упрощения примера, в нём не реализовано перемещение по списку с помощью стрелок на клавиатуре.
Это один из множества случаев, когда поведение программы зависит только от положения курсора и событий мыши, а для пользователей, работающих с клавиатурой, её функциональность недоступна. Тестирование пользовательского интерфейса с помощью клавиатуры позволяет быстро найти проблемные места, работу которых можно улучшить, используя обработчики событий клавиатуры.
Сложные компоненты¶
Усложнение пользовательского интерфейса не должно ухудшать доступность контента. Несмотря на то, что лучший результат достигается при максимальном использовании синтаксиса HTML, даже очень сложный компонент можно сделать доступным для всех.
В руководстве по доступности контента в веб-приложениях собраны все необходимые сведения о ролях ARIA, а также о состояниях и свойствах ARIA. Описанные в руководствах HTML-атрибуты полностью поддерживаются в JSX. Используя их можно создавать функционально нагруженные и при этом полностью доступные React-компоненты.
Каждый тип компонентов имеет специфическую архитектуру и предполагает определённую функциональность, как для пользователей, так и для браузеров:
- практические рекомендации WAI-ARIA по архитектуре и компонентам
- примеры из блога Хейдона Пикеринга (Heydon Pickering)
- инклюзивные компоненты
На что ещё нужно обратить внимание¶
Определение языка¶
Обязательно указывайте язык текста на странице. Это необходимо для корректной установки опций экранных считывающих устройств:
Заголовок страницы¶
Всегда устанавливайте заголовок <title>
для правильного описания контента текущей страницы. Это позволит пользователю постоянно быть в курсе контекста страницы:
Реализовать эти требования в React можно с помощью компонента DocumentTitle
.
Цветовая контрастность¶
Убедитесь, что все тексты на вашем сайте имеют правильную цветовую контрастность, чтобы обеспечить максимальное удобство чтения для пользователей с плохим зрением:
- разъяснение требований WCAG к цветовой контрастности
- всё о цветовой контрастности и о том, почему вы должны переосмыслить подход к ней
- статья о цветовой контрастности на сайте A11y Project
Ручной расчёт правильных цветовых комбинаций для всех вариантов сайта может быть очень утомительным. Вместо этого вы можете рассчитать все необходимые палитры с помощью Colorable.
Оба инструмента, aXe и WAVE, о которых будет рассказано ниже, включают тесты контрастности. Они помогут выявить ошибки в подборе цветов.
Если вы хотите провести более полное тестирование контрастности, то можете воспользоваться этими программами:
Инструменты для разработки и тестирования¶
Далее перечислены инструменты, которые могут быть полезны при разработке веб-приложений с доступным контентом.
Тестирование клавиатуры¶
Самый простой и одновременно наиболее важный вид проверки — это тестирование клавиатуры. Такая проверка позволяет определить доступность контента на вашем сайте при работе только с клавиатурой. Чтобы протестировать клавиатуру, выполните следующие действия:
- Отключите мышь.
- Используйте
Tab
иShift+Tab
для перемещения по странице. - Используйте
Enter
для активации элементов. - Там, где необходимо, используйте клавиши со стрелками, например, для работы с меню или выпадающими списками.
Инструменты разработчика¶
Выполнение некоторых требований по доступности контента можно контролировать непосредственно в JSX. Обычно среда разработки обладает средствами автоматической подстановки, которые могут использоваться при написании JSX для выбора ролей, состояний и свойств ARIA. Кроме этого можно воспользоваться следующими инструментами:
eslint-plugin-jsx-a11y¶
Плагин eslint-plugin-jsx-a11y для ESLint выполняет проверку абстрактного синтаксического дерева JSX на предмет поиска проблем, связанных с доступностью контента. Многие среды разработки могут интегрироваться с этим инструментом и выводить сообщения линтера в окно анализа кода или прямо в окно исходного кода.
В Create React App этот плагин используется с заранее установленным набором правил. Если необходимо задействовать дополнительные правила, вам нужно создать в корне проекта файл .eslintrc
со следующим кодом:
1 2 3 4 |
|
Тестирование доступности контента в браузере¶
Существуют инструменты для аудита доступности контента веб-страниц в браузере. Используйте их совместно с теми инструментами для проверки HTML, которые были описаны выше.
aXe, aXe-core и react-axe¶
Компания Deque Systems предлагает модуль aXe-core для автоматизированного и сквозного тестирования веб-приложений. Этот модуль имеет интеграцию с Selenium.
На основе aXe-core
разработан продукт компании Deque Systems под названием The Accessibility Engine или aXe. Это расширение для браузеров, предназначенное для комплексного тестирования доступности контента сайтов.
Также вы можете использовать модуль react-axe для вывода сообщений от aXe в консоль в процессе программирования или отладки.
WebAIM WAVE¶
Web Accessibility Evaluation Tool ещё одно расширение для браузера, которое используется для улучшения доступности контента веб-сайтов.
Инспекторы доступности контента и дерево доступности¶
Дерево доступности — это подмножество DOM-дерева. В нём содержатся объекты, которые нужны для работы технологий поддержки доступности контента, например, для экранных считывающих устройств.
В некоторых браузерах можно легко получить информацию обо всех элементах в дереве доступности:
- использование инспектора доступности в Firefox
- активация инспектора доступности в Chrome
- использование инспектора доступности в OS X Safari
Экранные считывающие устройства¶
Проверка работы экранных считывающих устройств должна быть частью комплексного тестирования доступности контента.
Учтите, что сочетание браузера и экранного считывающего устройства имеет большое значение. Рекомендуется протестировать ваше приложение в том браузере, который лучше всего подходит для избранного вами экранного считывателя.
Общедоступные экранные считыватели¶
NVDA в Firefox¶
NonVisual Desktop Access или NVDA — это широко распространённый экранный считыватель с открытым исходным кодом для Windows.
Вот несколько руководств по работе с NVDA:
VoiceOver в Safari¶
VoiceOver — это экранный считыватель, встроенный в продукты Apple.
Здесь приведены руководства по активации и использованию VoiceOver:
- WebAIM — использование VoiceOver для улучшения доступности контента
- Deque — сочетания клавиш для VoiceOver в OS X
- Deque — комбинации жестов для VoiceOver в iOS
JAWS в Internet Explorer¶
Job Access With Speech or JAWS — это экранный считыватель, который чаще всего используется в Windows.
Руководства по JAWS:
Прочие экранные считыватели¶
ChromeVox в Google Chrome¶
ChromeVox — это встроенный экранный считыватель для ноутбуков Chromebook. Он доступен для Google Chrome в виде расширения.
Ссылки на руководства по ChromeVox:
- Google Chromebook — как использовать встроенную программу чтения с экрана
- Сочетания клавиш для ChromeVox