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