От автора: данная статья является выдержкой из книги HTML5 и CSS3 для реального мира, 2-е издание за авторством Алексиса Гольдштейна, Луи Лазариса и Эстель Вейль. Книгу можно найти в магазинах по всему миру, а также купить цифровую версию.
В главах 2 и 3 мы рассказываем основы того, как сделать страницы более семантическими и потенциально более доступными с помощью новых семантических элементов HTML5. Однако улучшенной семантики зачастую бывает недостаточно, чтобы сделать сложное веб-приложение полностью доступным.
Чтобы сделать контент и функционал наших страниц максимально доступными для пользователей, нам необходимо воспользоваться возможностями WAI-ARIA, наложив их поверх уже существующих функций в HTML5. В этой статье мы не будем глубоко разбирать, что такое WAI-ARIA, об этом можно написать несколько статей. Но все же мы подумали, что важно немного рассказать про эту технологию, чтобы у вас было представление.
WAI-ARIA расшифровывается как Web Accessibility Initiative-Accessible Rich Internet Applications. На сайте W3C о WAI-ARIA пишут следующее: «… способ, как сделать веб-контент и веб-приложения более доступными для людей с ограниченными возможностями. Особенно хорошо работает с динамическим контентом и продвинутыми элементами интерфейса с сильной привязкой к JS, разработанных с помощью Ajax, HTML, JS и сопутствующих технологий.»
Люди, которые вынуждены просматривать интернет со скрин ридерами или те, кто не может использовать мышь, зачастую лишаются какого-то функционала на сайте или в веб-приложении. Например, слайдеры, прогрессбары и вкладки. WAI-ARIA позволяет исправить эти недостатки ваших страниц, даже если контент и функционал находятся в плену сложной архитектуры приложения. Таким образом, пользователи с ограниченными возможностями могут использовать те части сайта, которые обычно им недоступны.
Как WAI-ARIA дополняет семантику
WAI-ARIA присваивает элементам роли, а ролям дает свойства и состояния. Простой пример:
1 |
<li role="menuitemcheckbox" aria-checked="true">Sort by Date</li> |
Приложение может связать элемент списка с каким-либо контентом. Однако без роли и атрибута aria-checked скрин ридер не сможет понять, для чего нужен этот элемент. Просто семантика (в нашем случае элемент списка) не говорит ничего. С помощью этих атрибутов вспомогательное устройство сможет лучше понять, для чего нужен этот элемент.
В большинстве случаев для семантических элементов, например, header, h1 и nav атрибуты WAI-ARIA необязательны. Эти теги уже и так передают свое назначение. Данные атрибуты нужно использовать на тех элементах, чей функционал и назначение нельзя определить сразу (или на элементах с небольшой доступностью или вообще без нее в одном или более основных браузеров).
Текущее состояние WAI-ARIA
Спецификация WAI-ARIA все еще улучшается, как и HTML5, поэтому эти технологии еще дадут нам все необходимые преимущества. Мы уже рассказали, как с помощью WAI-ARIA расширить семантику элементов на странице, однако роли WAI-ARIA необходимо также присваивать тем элементам, которые уже своим названием выражают назначение, так как вспомогательные технологии не поддерживают все семантические теги HTML5. Другими словами, WAI-ARIA можно использовать в качестве временного решения для улучшения доступности HTML5 страниц, пока подтягиваются скрин ридеры.
Разберем, например, меню сайта:
1 2 |
<nav role="navigation"> <ul>...</ul> </nav> |
Казалось бы, мы дублируем семантику: тег nav уже говорит, что набор ссылок внутри него выступает в роли меню, однако мы добавили WAI-ARIA роль navigation. Во множестве случаев такой тип дублирования будет обязательным. В случае с тегом nav на данный момент только браузер IE неправильно выставляет роль navigation, поэтому атрибут в данном случае необходим.
Значит ли это, что WAI-ARIA станет ненужным, когда семантика HTML5 и доступность будут полностью поддерживаться? Нет. В WAI-ARIA есть роли, не имеющие аналогов среди HTM5 тегов. Например, роль timer. Для имитации таймера в HTML5 можно использовать тег time и обновлять время через JS, однако это никак не говорит скрин ридеру, что это таймер. Он думает, что это просто статическое время.
Для передачи WAI-ARIA ролей в скрин ридер браузер должен передать их через API доступности. Это позволяет скрин ридеру взаимодействовать с тегами, как с нативными элементами управления компьютера.
Поддержка ARIA в браузерах растет, и на данный момент достигла хороших значений. Все новые версии браузеров, хотя бы частично, поддерживают WAI-ARIA. На сайте Paciello Group можно найти новейшее руководство по поддержке функций доступности наподобие WAI-ARIA в браузерах на определенных ОС.
Стоит также сказать, что не все пользователи, которые могли бы использовать WAI-ARIA, используют данную технологию. В январе 2014 WebAIM (Web Accessibility In Mind) провели свой пятый опрос по скрин ридерам, где выяснили, что 28% опрошенных редко или вообще не пользуются средствами ARIA для навигации по страницам. Среди хороших новостей можно отметить, что число пользователей, использующих WAI-ARIA, выросло. В 2010 году по результатам похожего опроса более 50% либо не использовать ARIA роли, либо не знали о них.
Если коротко, у WAI-ARIA довольно хорошая поддержка, и вы точно не испортите свой HTML5, если пропишите эти атрибуты. Атрибуты проходят HTML5 валидацию, а всех преимуществ не сосчитать, спецификация до сих пор улучшается.
Дополнительные источники
Как я писал выше, объяснение всех ролей WAI-ARIA выходит за рамки данной книги, но если вам интересно, в первую очередь можем порекомендовать официальную спецификацию. На W3C есть сокращенный справочник и практическое руководство.
Можете ознакомиться со статьей Стефана Макса знакомство с WAI-ARIA на SitePoint. Также можете зайти на сайт HTML5 Accessibility, которым занимается эксперт по доступности Стив Фолкнер. Он построил таблицы с описанием поддержки семантических HTML5 тегов в браузерах с точки зрения доступности.
Редакция: Louis Lazaris
Источник: //www.sitepoint.com/
Редакция: Команда webformyself.