Использование стандартов ARIA в HTML

6 июля 2021 года спецификация ARIA в HTML, в редактировании которой автор этой статьи принимает участие вместе со Стивом Фолкнером и Патриком Х. Лауке, стала кандидатом в рекомендации W3C (консорциума всемирной паутины).

В приглашении W3C к внедрению стандартов ARIA в HTML отмечено следующее:

«Главная цель спецификации – определение требований к инструментам проверки соответствия, которые используют авторы (веб-разработчики). Эти требования помогут авторам разрабатывать веб-контент, включая элементы интерфейса и виджеты, таким образом, чтобы стандарты ARIA дополняли или расширяли функциональность языка HTML».

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

Даже после того, как спецификацию ARIA выделили в отдельный рабочий черновик, многие аспекты стандарта (роли, свойства для элементов <span>) по-прежнему были включены в общую HTML-спецификацию консорциума. Живой стандарт HTML, благодаря усилиям Кэролин Маклауд, вместо повторения фрагментов спецификации ссылается на сведения о доступности каждого конкретного элемента.

Понимание роли стандартов ARIA в HTML

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

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

Ошибка

Например, ошибку вызовет следующая разметка:

<button role=heading aria-level=2>
  My text goes here
</button>
...

Элемент <button> не должен иметь роль heading, поскольку неявная роль кнопки и явная роль heading, заданная разработчиком, вступают в конфликт. К примеру, <button> представляет собой интерактивный элемент, на который можно перейти с помощью клавиатурных клавиш. Этот элемент дает пользователю возможность совершить на странице какое-то действие – отправить заполненную форму, запустить выполнение скрипта. В то же время heading предназначен для представления главной темы или одного из разделов страницы. Он не может быть интерактивным и на него не нужно переходить нажатием клавиши на клавиатуре.

В такой ситуации идея разработчика по переопределению неявной семантики элемента <button> может стать источником неопределенности для пользователей. Что именно имел в виду разработчик – хотел ли он создать подзаголовок, или не знал, что этот элемент не может играть двойную роль? Почему программа для чтения с экрана сочла элемент «кликабельным»? Почему на нем не срабатывает клавиша «Пробел», и почему нажатие не вызывает прокрутки страницы? Или, что еще хуже, после нажатия клавиши «Пробел» происходит какое-то непредусмотренное действие?

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

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

<h2>
  My text goes here
</h2>
...

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

<h2>
  <button ...>My text goes here</button>
</h2>
...

Предупреждение

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

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

Наиболее распространенным предупреждением, с которым могут столкнуться разработчики, будет указание на избыточные роли. Например:

<a href=... role=link>...</a>

Здесь в правильном неявном теге <a href= </a> используется явная (и ненужная) ARIA-роль role=link. Элементы вроде <button>, <article>, <input type=checkbox> и даже элементы, впервые представленные в HTML5, уже имеют свои неявные ARIA-роли, определенные в спецификации HTML AAM, и без каких-либо проблем распознаются всеми наиболее популярными браузерами

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

С учетом багов и пробелов было необходимо, к примеру, добавить явную роль role=main к элементу <main>, чтобы обеспечить совместимость с устаревшими браузерами, такими как IE11. Но время не стоит на месте, и необходимость в таких мерах отпадает, поскольку программы-помощники компенсируют пробелы в специальных возможностях браузера Internet Explorer 11.

Более свежие примеры того, где может понадобиться явное определение ролей – это указание для WebKit (браузер Safari) на раскрытие семантики списка при удалении маркеров по умолчанию, или необходимость убедиться в том, что тег <img> с источником изображения в формате .svg доступен для программы озвучивания экрана.

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

Примечание: что касается бага в WebKit с распознаванием svg в теге <img>, недочет может быть исправлен в новых версиях браузера Safari. Этот пример может служить хорошим напоминанием о том, что системы валидации кода должны демонстрировать предупреждения, вместо того, чтобы игнорировать избыточное определение ролей. Когда ошибка в браузере будет исправлена, необходимость в явном определении ролей отпадет.

Не только роли

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

Рассмотрим фрагмент:

<button disabled aria-disabled=false>...</button>

Хотя деактивированный ARIA-атрибут должен указывать на то, что элемент <button> находится во включенном состоянии, на самом деле у этого атрибута есть неявная функциональность, которая удаляет кнопку из порядка фокусировки веб-страницы. Таким образом, кнопка становится недоступной для указывающих устройств (мыши, тачпада), а браузер игнорирует ее по умолчанию.

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

Будущее спецификации

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

Пожалуйста, оставляйте свои комментарии по текущей теме материала. За комментарии, отклики, дизлайки, лайки, подписки низкий вам поклон!

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

Наталья Кайдаавтор-переводчик статьи «ARIA in HTML»