Недавно мы рассказали про скринридеры — специальные программы для чтения с экрана, которые помогают незрячим пользоваться компьютером. Вот основные мысли:
- скринридер получает данные от программ и операционной системы и зачитывает пользователю всё, что ему нужно знать о происходящем на экране;
- чтобы это работало, программа должна уметь отдавать скринридеру информацию о происходящем в ней;
- браузеры умеют анализировать HTML-код, чтобы скринридеры могли озвучивать содержимое сайтов.
Проблема в том, что стандартной вёрстки сайтов недостаточно для скринридеров. Чтобы помочь слабовидящим лучше работать с сайтом, используют ARIA-атрибуты и придерживаются специальных правил разметки.
Что такое ARIA
ARIA — это стандарт разработки, который помогает делать сайты и приложения более доступными для людей с ограниченными возможностями. В вебе ARIA-атрибуты нужны для того, чтобы помочь скринридерам разобраться с контентом на сайте и озвучить его тем, кто плохо видит или не видит совсем.
Чтобы не добавлять новые теги, по этому стандарту используют ARIA-атрибуты тегов. Их поддерживают все современные браузеры. Идея в том, чтобы добавлять эти атрибуты к стандартным тегам — на внешний вид эти атрибуты не влияют, зато скринридерам сразу понятно, как работать с этим элементом.
Атрибут тега — это то, что пишется после названия и до закрывающей угловой скобки. Например, атрибут id отвечает за внутреннее название элемента:
<p id = "mainText"> </p>
Атрибутов у тега может быть много — один отвечает за имя, второй — за стили и так далее. Вот пример тега абзаца, у которого сразу три атрибута:
<p id = "mainText" style="color: red;" class="loader"> </p>
Большинство ARIA-атрибутов начинаются со слова «aria-», но есть и исключения.
Примеры ARIA-атрибутов
В официальном стандарте ARIA описаны десятки атрибутов, с помощью которых можно решить практически любые задачи. Вот некоторые из них.
aria-label. Если на нашем сайте меню сделано с помощью иконок, а не текста, скринридер может их не прочитать.
Атрибут aria-label позволяет добавить невидимую подпись любому элементу — она не появится на экране, зато скринридер легко прочитает, что там написано.
<img src="send.jpg" aria-label="Отправить письмо">
aria-keyshortcuts. Некоторые элементы интерфейса могут быть привязаны к горячим клавишам. Чтобы скринридер мог сообщить пользователю, что у текущего элемента есть своя горячая клавиша для быстрого перехода или активации, используют атрибут aria-keyshortcuts. В нём указывают сочетания клавиш без дополнительных пояснений, чтобы скринридер мог их правильно озвучить:
<button aria-keyshortcuts="Control+Alt+.">Кнопка</button>
aria-disabled. Когда пользователь на странице нажимает клавишу Tab, он по очереди переключается между интерактивными элементами — кнопками, ссылками, пунктами меню, полями ввода и так далее. Но если кнопка сейчас недоступна для нажатия, скринридер её пропустит. Такое бывает, когда мы, например, не заполнили форму ввода — кнопка станет активной только после заполнения всех полей.
Если мы добавим свойство aria-disabled такой кнопке, то скринридер её увидит и тоже сможет озвучить, добавив, что нажать на неё пока нельзя. Это нужно для того, чтобы пользователь понял — кнопка на странице есть, но пользоваться ей пока не получится.
<button aria-disabled="true">Подписаться</button>
aria-required. Когда мы создаём, например, форму подписки, у нас есть обязательные поля — имя и адрес электронной почты. Мы привыкли, что обязательные поля помечаются звёздочкой, но при чтении иногда это бывает неочевидно.
Если мы хотим сообщить скринридеру, что перед ним — обязательное поле, то к нему добавляется атрибут aria-required:
<input type="password" name="pass" aria-required="true">
Роли
Кроме прямых атрибутов, в ARIA-стандарте есть роли — они сообщают скринридеру, что делает этот элемент и для чего он нужен. Например, если мы добавим элементу роль и укажем, что это чекбокс, то скринридер сможет сообщить пользователю, отмечен он или нет.
Всего есть шесть ролей:
- роли виджетов — показывает, что перед нами интерактивный элемент, с которым можно что-то делать: меню, список, вкладки, сетки, кнопки, поля ввода и так далее;
- роли структуры документа — описывают структуру страницы и из чего он состоит;
- роли ориентиров — нужны для навигации по странице;
- роли «живых» областей — тех, где есть динамический контент: логи, таймеры, алерты;
- роли окон — для обозначения диалоговых и всплывающих окон;
- абстрактные роли — те, что не подходят под предыдущие категории.
Каждая роль задаётся с помощью атрибута role="", а в кавычках пишется значение роли. Примеры ролей:
- menu — говорит, что перед нами меню, в котором что-то есть.
- button — кнопка. Дело в том, что с помощью современной вёрстки на дивах можно сделать кнопку, не используя тег <button>, и скринридер не сможет её правильно обработать. Роль решает эту проблему и сообщает скринридеру, что этот элемент — кнопка.
- listitem — элемент списка.
- search — поле для поиска.
- alert — область с важной информацией.
- sectionhead — название раздела.
Правила разметки
Чтобы сделать сайт доступнее, кроме атрибутов ARIA нужно правильно применять базовые правила разметки страницы:
- делать вложенную иерархию заголовков;
- подписывать картинки и значимые элементы интерфейса;
- пользоваться полным набором тегов для создания списков и таблиц — например, некоторые скринридеры плохо работают с таблицами, у которых нет тега <thead>;
- использовать семантические теги разметки.
В итоге, если соблюдать все эти правила, у нас получится сайт, которым будет удобно пользоваться всем — и со скринридером, и без него.
Что дальше
В следующий раз займёмся практикой — адаптируем сайт для чтения с экрана и сравним его поведение в скринридере с тем, что было раньше.
