Подстраховка web-доступности семантических областей HTML5 через роли WAI-ARIA
Как известно, HTML5 имеет расширенные возможности семантической вёрстки. Он позволяет обернуть отдельные логические блоки страницы в специально предназначенные для них блочные теги, какие как header, main, footer и другие. Ну, а улучшение структурной и семантической вёрстки, как правило, автоматически способствует повышению уровня accessibility web-интерфейса для пользователей программ экранного доступа, потому что они добавляют элементы страницы, по которым возможно осуществлять навигацию и быстро перемещаться между блоками контента.В принципе, дополнительная разметка для обеспечения accessibility реализуется через отдельную технологию WAI-ARIA, однако и стандартные семантические структуры HTML5 современными браузерами и современными программами экранного доступа воспринимаются как соответствующие атрибуты ARIA для вспомогательных технологий. Проще говоря, это означает, что в теории следующие два варианта вёрстки с точки зрения программ чтения экрана аналогичны: Листинг 1:
Листинг 2:
Возьмём две наиболее популярные программы экранного доступа: JAWS (версии 15.0) и NVDA (версии 2014.3), а также два наиболее популярных у их пользователей браузера: Internet Explorer (версии 11) и Firefox (версии 32). После этого протестируем все возможные конфигурации на предмет обработки семантических областей из листинга 1. В итоге, получим следующие результаты:
Поддержка семантических тегов HTML5 Теги JAWSInternet Explorer JAWSFirefox NVDAInternet Explorer NVDAFirefox aside Да Да Нет Да footer Нет Да Нет Да header Нет Да Нет Да main Да Да Нет Да nav Да Да Нет Да Оказывается, что всё работает далеко не так, как предполагается теоретически. Причём с понижением версий ПО поддержка некоторых структур может начать неравномерно отваливаться. А главное в официальных руководствах и технических стандартах об этом вряд ли удастся прочитать, и такие проблемы сможет выявить лишь опытный и дотошный QA-инженер accessibility, который есть далеко не в каждом даже очень крупном проекте, пускай там доступность и прописана в ТЗ, например, в случае разработки социально ориентированных или государственных сайтов, а также в проектах, для которых доступность подразумевается как конкурентное преимущество, например, Интернет-банкинги. Про проекты не фокусированные на accessibility и говорить не приходится.
Разумеется, поскольку финальный вариант WAI-ARIA принят совсем недавно, а руководство по его поддержки со стороны User Agent вообще до сих пор не существует в завершённом виде, то в будущем, когда всё утрясётся, можно надеется, что и такие вещи также унифицируются. Однако проекты разрабатываются и сдаются уже здесь и сейчас, да и graceful degradation тоже никто ещё не отменял. Поэтому имеет смысл верстать так, чтобы с одной стороны использовать семантические новинки HTML5, а с другой — не обижать вспомогательные технологии при любых раскладах.
Достигнуть этого можно путём одновременного использования и семантики HTML5, и разметки WAI-ARIA. То есть к этим тегам надо будет добавлять соответствующие роли WAI-ARIA, как бы подстраховывая семантические области HTML5 через Accessible Rich Internet Applications.
Здесь следует сразу предупредить, что атрибуты разметки WAI-ARIA имеют более высокий приоритет, чем стандартные семантические структуры HTML5, поэтому если, например, для тега main прописать атрибут role со значением contentinfo, то программы экранного доступа будут называть его так, как будто это footer. Так что отсутствие WAI-ARIA лучше, чем наличие её некорректного применения. Иными словами: «Не умеешь, не берись», но эта статья как раз и призвана научить этому не сложному приёму вёрстки.
По большому счёту, всё сводится к необходимости выучить правильное соответствие ролей WAI-ARIA и стандартных семантических структур HTML5. В принципе, из листингов 1 и 2 основные соответствия уже ясны:
Соответствие базовых семантических тегов HTML5 и значений атрибута role из WAI-ARIA Тег HTML5 Роль WAI-ARIA footer contentinfo header banner main main nav navigation Кстати, что касается роли banner, специально оговоримся, что она предназначена для оборачивания именно всей шапки страницы, а не рекламного баннера. То есть она, действительно, прямой аналог тега header. Как показывает практика, некоторых слово «banner» вводит в заблуждение, и они начинают это значение присваивать именно рекламным баннерам, но это неправилльно.
Вышеприведённые соответствия позволят корректно разметить в WAI-ARIA базовые семантические области HTML5. Однако заметно, что там упомянуты далеко не все из них. Дело в том, что во-первых, некоторые семантические структуры HTML5 не имеют прямых аналогов WAI-ARIA, например, это касается тегов article или section, а во-вторых, с некоторыми из них всё не так просто, главным образом, речь, конечно, об aside.
По умолчанию тег aside программами экранного доступа трактуется как аналог роли complementary. В принципе, в большинстве случаев так и должно быть, однако диапазон возможного применения aside достаточно велик, поэтому могут встречаться ситуации, когда роль complementary будет не очень уместна.
Откровенно говоря, здесь мы уже вступаем на достаточно тонкий лёд вкусовщины и субъективного понимания дизайна невизуальных интерфейсов, где дискуссии примерно соответствуют спором о шрифтах или цветовых гаммах в мире визуальных интерфейсов. Тем не менее, всё же приведём один пример, чтобы дать представление об этом аспекте.
Листинг 3:
Использование таких приёмов вёрстки требует уже несколько большего понимания логики невизуальных интерфейсов, поэтому рубить с плеча тут не стоит. Можно только посоветовать всё-таки использовать роль complementary, а более сложные интерфейсные ходы применять только если вы в достаточной степени уверены, что это уместно. Если бы в листинге 3 вместо note была использована complementary, то это было бы лучше, чем наоборот.
К слову, у роли note нет прямого аналога среди семантических тегов HTML5, поэтому полной совместимости нет как в одну, так и в другую сторону. Такие роли и программами экранного доступа обрабатываются несколько иначе, поэтому с ними вообще лучше не связываться, если в проекте нет серьёзных специалистов по accessibility, понимающих все подводные камни.
Кроме того, проблему использования нескольких одинаковых семантических областей HTML5 можно решать и другим способом, а именно добавлением к ним поясняющих меток. Например, если в интерфейсе несколько навигационных панелей, то имеет смысл указать их назначение, чтобы пользователь программы экранного доступа сразу понимал разницу.
Листинг 4:
Соблюдение несложных приёмов вёрстки, описанных в этой статье, позволит вам создавать не просто доступные, но одинаково доступные под всеми основными конфигурациями интерфейсы. И главное, всё это абсолютно никак не поломает визуальную вёрстку, потому что атрибуты role и aria-label оказывают влияние лишь на то, как страница представляется программами экранного доступа через речевой или тактильный вывод информации.
Напоследок две ссылки, по которым можно более подробно ознакомиться с семантическими возможностями HTML5 и WAI-ARIA: