АРИЯ и HTML

Большинство разработчиков знакомы со стандартным языком разметки современного веба — языком разметки гипертекста (HTML) . Однако вам, возможно, менее знаком язык ARIA (ранее известный как WAI-ARIA): что это такое, как он используется и когда — и когда не — его следует использовать.

HTML и ARIA играют важную роль в обеспечении доступности цифровых продуктов, особенно когда речь идет о вспомогательных технологиях (АТ), таких как программы чтения с экрана. Оба языка используются для преобразования контента в альтернативный формат, например, шрифт Брайля или преобразование текста в речь (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 и смежных технологий».

Группа WAI

Дерево доступности

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

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

Дополненное дерево доступности ARIA.

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

Три основные особенности ARIA — это роли, свойства и состояния/значения.

Роли определяют, чем является элемент или что он делает на странице или в приложении.

<div role="button">Self-destruct</div>

Свойства выражают характеристики или взаимосвязи с объектом.

<div role="button" aria-describedby="more-info">Self-destruct</div>

<div id="more-info">This page will self-destruct in 10 seconds.</div>

Состояния и значения определяют текущие условия или значения данных, связанные с элементом.

<div role="button" aria-describedby="more-info" aria-pressed="false">
  Self-destruct
</div>

<div id="more-info">
  This page will self-destruct in 10 seconds.
</div>

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

Недавно в 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 о доступности было установлено, что на главных страницах с атрибутом ARIA в среднем обнаруживается на 70% больше ошибок, чем на страницах без ARIA, главным образом из-за неправильной реализации атрибутов ARIA.

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

Не следует : назначать роль.

<a role="button">Submit</a>

Рекомендация : Используйте семантический элемент.

<button>Submit</button>

В случае сомнений используйте семантические HTML-элементы .

Правило 2: Не добавляйте (ненужную) ARIA в HTML.

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

Не следует : назначать вводящую в заблуждение роль.

<h2 role="tab">Heading tab</h2>

Выполните следующие действия : Правильно назначьте роли.

<div role="tab"><h2>Heading tab</h2></div>

Используйте HTML-элементы по назначению, чтобы сократить объем работы и повысить производительность кода.

Правило 3: Всегда поддерживайте навигацию с помощью клавиатуры.

Все интерактивные (не отключенные) элементы управления ARIA должны быть доступны с клавиатуры. Вы можете добавить tabindex = "0" к любому элементу, которому требуется фокус, но который обычно не получает фокус с клавиатуры. По возможности избегайте использования индексов табуляции с положительными целыми числами, чтобы предотвратить потенциальные проблемы с порядком фокусировки клавиатуры.

Не следует : добавлять атрибут tabindex.

<span role="button" tabindex="1">Submit</span>

Выполните следующие действия : Установите значение tabindex равным `0`.

<span role="button" tabindex="0">Submit</span>

Конечно, если есть возможность, в этом случае используйте настоящий элемент <button> .

Правило 4: Не скрывайте элементы, на которые можно сделать фокус.

Не добавляйте role= "presentation" или aria-hidden= "true" к элементам, которые должны находиться в фокусе, включая элементы с tabindex= "0" . Добавление этих атрибутов и состояний к элементам отправляет вспомогательным технологиям сообщение о том, что эти элементы не важны и их следует пропустить. Это может привести к путанице или помешать пользователям взаимодействовать с элементом.

Не следует : Скрывать элементы, на которые можно сделать фокус.

<div aria-hidden="true">
  <button>Submit</button>
</div>

Что нужно делать : выставлять фокусируемые элементы.

<div>
  <button>Submit</button>
</div>

Правило 5: Используйте доступные имена для интерактивных элементов.

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

Доступными именами могут быть содержимое, заключенное в элемент (в случае <a> ), альтернативный текст или метка.

Для каждого из следующих примеров кода доступное имя — «Красные кожаные ботинки».

<!-- A plain link with text between the link tags. -->
<a href="shoes.html">Red leather boots</a>

<!-- A linked image, where the image has alt text. -->
<a href="shoes.html"><img src="shoes.png" alt="Red leather boots"></a>

<!-- A checkbox input with a label. -->
<input type="checkbox" id="shoes">
<label for="shoes">Red leather boots</label>

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

ARIA в HTML

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

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

Взгляните на несколько примеров.

Не следует : назначать не ту роль.

<a role="heading">Read more</a>

Рекомендация : Используйте правильную роль и дополнительное описание ссылки.

<a aria-label="Read more about some awesome article title">Read More</a>

Не следует : добавлять избыточную роль.

<ul role="list">...</ul>

Рекомендация : Сократить избыточность.

<ul>...</ul>

Не следует : упускать из виду потенциальные побочные эффекты.

<details>
  <summary role="button">more information</summary>
  ...
</details>

Что нужно сделать : Устранить побочные эффекты.

<details>
  <summary>more information</summary>
  ...
</details>

Сложности ARIA

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

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

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