ARIA и HTML¶
Большинство разработчиков знакомы со стандартным языком разметки современного веба, HyperText Markup Language (HTML). Однако вы можете быть менее знакомы с Accessible Rich Internet Applications (ARIA) (официальное название WAI-ARIA): что это такое, как он используется, и когда — и когда не — использовать его.
HTML и ARIA играют важную роль в обеспечении доступности цифровых продуктов, особенно когда речь идет о вспомогательных технологиях (AT), таких как устройства чтения с экрана. Оба они используются для преобразования контента в альтернативный формат, например в шрифт Брайля или преобразование текста в речь (TTS).
Давайте рассмотрим краткую историю ARIA, почему она важна, а также когда и как ее лучше использовать.
Введение в ARIA¶
ARIA была впервые разработана в 2008 году группой Web Accessibility Initiative (WAI) —подгруппой всеобъемлющего консорциума World Wide Web Consortium (W3C), который управляет и регулирует интернет.
ARIA - это не настоящий язык программирования, а набор атрибутов, которые можно добавлять к элементам HTML для повышения их доступности. Эти атрибуты передают информацию о роли, состоянии и свойствах вспомогательным технологиям через API доступности, которые есть в современных браузерах. Это взаимодействие происходит через дерево доступности.
"WAI-ARIA, Accessible Rich Internet Applications Suite, определяет способ сделать веб-контент и веб-приложения более доступными для людей с ограниченными возможностями. Это особенно помогает при работе с динамическим контентом и расширенными элементами управления пользовательским интерфейсом, разработанными с помощью HTML, JavaScript и связанных с ними технологий."
Дерево доступности¶
ARIA изменяет неправильный или неполный код, чтобы создать лучшие условия для тех, кто использует AT, изменяя, раскрывая и дополняя части дерева доступности.
Дерево доступности создается браузером и основано на стандартном дереве объектной модели документа (DOM). Как и дерево DOM, дерево доступности содержит объекты, представляющие все элементы разметки, атрибуты и текстовые узлы. Дерево доступности также используется API-интерфейсами доступности для конкретных платформ, чтобы обеспечить представление, понятное вспомогательным технологиям.
Сам по себе ARIA не меняет функциональность или внешний вид элемента. Это означает, что только пользователи AT заметят разницу между цифровым продуктом с ARIA и без него. Это также означает, что только разработчики несут ответственность за внесение соответствующих изменений в код и стилистику, чтобы сделать элемент максимально доступным.
Три основные характеристики ARIA - это роли, свойства и состояния/значения.
Роли определяют, чем является или что делает элемент на странице или в приложении.
1 |
|
Свойства выражают характеристики или отношения к объекту.
1 2 3 4 5 6 7 |
|
Состояния/значения определяют текущие условия или значения данных, связанные с элементом.
1 2 3 4 5 6 7 8 9 10 11 |
|
Хотя все три элемента ARIA можно использовать в одной строке кода, это не обязательно. Вместо этого накладывайте друг на друга роли, свойства и состояния/значения ARIA, пока не достигнете конечной цели по обеспечению доступности. Правильное внедрение ARIA в кодовую базу гарантирует, что пользователи AT получат всю необходимую информацию для успешного и равноправного использования вашего сайта, приложения или другого цифрового продукта.
Недавно в Chrome DevTools появился способ увидеть полное дерево доступности, облегчающий разработчикам понимание того, как их код влияет на доступность.
Когда использовать ARIA¶
В 2014 году W3C официально опубликовала рекомендации по HTML5. В ней произошли значительные изменения, в том числе добавление знаковых элементов, таких как <main>
, <header>
, <footer>
, <aside>
, <nav>
, и атрибутов, таких как hidden
и required
. Благодаря этим новым элементам и атрибутам HTML5, а также расширенной поддержке браузерами, некоторые части ARIA стали менее критичными.
Когда браузер поддерживает HTML-тег с неявной ролью с эквивалентом ARIA, обычно нет необходимости добавлять ARIA к элементу. Однако ARIA по-прежнему включает в себя множество ролей, состояний и свойств, которые недоступны ни в одной версии HTML. Эти атрибуты пока остаются полезными.
Это подводит нас к главному вопросу: Когда следует использовать ARIA? К счастью, группа WAI разработала пять правил ARIA, чтобы помочь вам решить, как сделать элементы доступными.
Правило 1: Не использовать ARIA¶
Да, вы все правильно поняли. Добавление ARIA к элементу не делает его более доступным по своей сути. В ежегодном отчете WebAIM Million annual accessibility report было обнаружено, что на домашних страницах с ARIA в среднем на 70 % больше обнаруженных ошибок, чем на страницах без ARIA, в основном из-за неправильной реализации атрибутов ARIA.
Из этого правила есть исключения. ARIA требуется, когда элемент HTML не поддерживает доступность. Это может быть связано с тем, что дизайн не позволяет использовать конкретный HTML-элемент или желаемая функция/поведение недоступна в HTML. Однако таких ситуаций должно быть мало.
Плохо | |
---|---|
1 |
|
Хорошо | |
---|---|
1 |
|
Если сомневаетесь, используйте семантические элементы HTML.
Правило 2: Не добавляйте (ненужные) ARIA в HTML¶
В большинстве случаев элементы HTML хорошо работают из коробки и не нуждаются в дополнительном добавлении ARIA. На самом деле, разработчикам, использующим ARIA, часто приходится добавлять дополнительный код, чтобы сделать элементы функциональными в случае интерактивных элементов.
Плохо | |
---|---|
1 |
|
Хорошо | |
---|---|
1 |
|
Когда вы используете HTML-элементы по назначению, вам приходится делать меньше работы и код получается более эффективным.
Правило 3: Всегда поддерживайте навигацию с клавиатуры¶
Все интерактивные (не отключенные) элементы управления ARIA должны быть доступны для клавиатуры. Вы можете добавить tabindex="0" к любому элементу, которому нужен фокус и который обычно не получает фокус клавиатуры. По возможности избегайте использования индексов табуляции с положительными целыми числами, чтобы предотвратить потенциальные проблемы с порядком фокуса клавиатуры.
Плохо | |
---|---|
1 |
|
Хорошо | |
---|---|
1 |
|
Помните, что люди с нарушениями зрения и без них пользуются навигацией с помощью клавиатуры. Не добавляйте лишних знаков табуляции в заголовки и абзацы, так как это может создать дополнительные трудности для некоторых пользователей, пользующихся только клавиатурой.
Правило 4: Не скрывайте элементы с фокусом¶
Не добавляйте role="presentation"
или aria-hidden="true"
к элементам, которые должны иметь фокус — включая элементы с tabindex="0"
. Когда вы добавляете эти роли/состояния к элементам, это посылает AT сообщение о том, что эти элементы не важны и их следует пропустить. Это может привести к путанице или нарушить работу пользователей, пытающихся взаимодействовать с элементом.
Плохо | |
---|---|
1 |
|
Хорошо | |
---|---|
1 |
|
Правило 5: Используйте доступные названия для интерактивных элементов¶
Цель интерактивного элемента должна быть донесена до пользователя, прежде чем он поймет, как с ним взаимодействовать. Убедитесь, что все элементы имеют доступное имя для людей, использующих AT-устройства.
Доступные имена могут быть содержимым, окружающим элемент (в случае <a>
), альтернативным текстом или меткой.
Для каждого из следующих примеров кода доступным именем является "Красные кожаные сапоги".
1 2 3 4 5 6 7 8 9 10 11 |
|
Существует множество способов проверить доступность имени элемента, в том числе осмотр дерева доступности с помощью Chrome DevTools или проверка с помощью программы чтения с экрана.
ARIA в HTML¶
Хотя использование элементов HTML само по себе является лучшей практикой, элементы ARIA могут быть добавлены в определенных ситуациях. Например, вы можете использовать ARIA в паре с HTML в шаблонах, где требуется более высокий уровень поддержки AT из-за ограничений среды, или в качестве запасного варианта для элементов HTML, которые не полностью поддерживаются всеми браузерами.
Конечно, существуют рекомендации по реализации ARIA в HTML. Наиболее важные из них: не переопределяйте стандартные роли HTML, сократите избыточность и будьте внимательны к непредвиденным побочным эффектам.
Давайте рассмотрим несколько примеров.
Плохо | |
---|---|
1 |
|
Хорошо | |
---|---|
1 2 3 |
|
Плохо | |
---|---|
1 2 3 |
|
Хорошо | |
---|---|
1 2 3 |
|
Плохо | |
---|---|
1 2 3 4 |
|
Хорошо | |
---|---|
1 2 3 4 |
|
Одно из мест, где ARIA может быть полезен, - это формы. Ознакомьтесь с модулем Learn Forms accessibility module.
Сложности ARIA¶
ARIA сложна, и при ее использовании всегда следует соблюдать осторожность. Хотя примеры кода в этом уроке довольно просты, создание доступных пользовательских шаблонов может быстро усложниться.
Необходимо учитывать множество факторов, включая, но не ограничиваясь ими: взаимодействие с клавиатурой, сенсорные интерфейсы, поддержка AT/браузеров, необходимость перевода, ограничения окружающей среды, устаревший код и предпочтения пользователей. Небольшие знания в области кодирования могут оказаться вредными — или просто раздражающими — при неправильном использовании. Не забывайте о простоте кода.
Эти предостережения в сторону, цифровая доступность - это не ситуация "все или ничего— это спектр, который допускает некоторые серые области, как эта. В зависимости от ситуации "правильными" могут считаться разные решения по кодированию. Важно, чтобы вы продолжали учиться, тестировать и стараться сделать наш цифровой мир более открытым для всех.
Источник — ARIA and HTML