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

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

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

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

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

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

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

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

Ошибка

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

   My text goes here  ...

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

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

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

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

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

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

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

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

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

...

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

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

С учетом багов и пробелов было необходимо, к примеру, добавить явную роль role=main к элементу

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

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

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

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

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

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

...

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

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

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

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