ARIA-роли базово: что нужно знать заказчику

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

01Что такое ARIA и зачем она нужна

ARIA расшифровывается как Accessible Rich Internet Applications — «доступные насыщенные интернет-приложения». Это набор HTML-атрибутов, которые добавляют к элементам страницы дополнительный смысл: какая у элемента роль, в каком он сейчас состоянии, какое у него имя для скринридера.

Зачем это нужно. Когда страница состоит из обычных тегов <button>, <a>, <input>, скринридер сразу понимает, что перед пользователем: кнопка, ссылка, поле ввода. Но в современных сайтах часто рисуют кастомные элементы: модальные окна, аккордеоны, табы, выпадающие меню. Внешне они работают как кнопки или вкладки, а в коде — обычные <div>. Для незрячего пользователя это набор «непонятных коробочек». ARIA помогает объяснить программе доступа: «вот это — кнопка», «вот это — таб, и сейчас он выбран».

02Главное правило: ARIA — это запасной выход, а не вход

У сообщества доступности есть жёсткий принцип, который звучит так: «отсутствие ARIA лучше, чем плохая ARIA». Это значит — если можно решить задачу нативным HTML, его и нужно использовать. Атрибуты добавляются только тогда, когда стандартного тега не хватает.

Пример: разработчик хочет сделать кнопку. Правильный вариант — <button>Отправить</button>: скринридер сразу видит кнопку, по ней работает Enter и пробел, она попадает в порядок Tab. Неправильный — <div role="button">Отправить</div>: придётся вручную добавлять обработку клавиатуры, фокус, состояния. Получается больше кода и больше шансов что-то сломать.

Поэтому когда разработчик присылает вам сайт, где половина элементов — div с ролями вместо обычных кнопок и ссылок, это сигнал: либо переделать на нормальный HTML, либо тщательно проверить, что всё это реально работает с клавиатуры и скринридера.

03Самые частые ARIA-атрибуты простыми словами

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

• role — роль элемента: button, navigation, dialog, tab. Говорит скринридеру: «считай это кнопкой / навигацией / окном».
• aria-label — невидимое имя для элемента, когда подписи нет. Например, кнопка-иконка без текста: <button aria-label="Закрыть">×</button>.
• aria-labelledby — то же, но имя берётся из другого элемента страницы по его id.
• aria-describedby — связывает элемент с поясняющим текстом (например, поле формы с подсказкой о формате).
• aria-expanded — состояние раскрывающихся блоков: аккордеон или меню сейчас открыто или закрыто.
• aria-hidden — скрывает элемент от скринридера, но оставляет визуально. Уместно для декоративных иконок.
• aria-current — отмечает текущий пункт меню или шаг.

Этого набора хватает, чтобы понимать 80% разговоров о доступности интерфейса. Остальное — задача разработчика.

04Где ARIA действительно нужна

Есть несколько ситуаций, где без ARIA не обойтись — нативного HTML просто не хватает:

Модальные окна

Когда вы открываете окно «оставить заявку», скринридеру важно сообщить: пользователь сейчас внутри диалога, остальная страница временно недоступна. Для этого используют role="dialog" и aria-modal="true", плюс правильно ловят фокус внутри окна.

Табы и вкладки

Вкладки «Описание / Характеристики / Отзывы» в карточке товара. Атрибуты role="tab", aria-selected, aria-controls объясняют скринридеру логику: какой таб выбран, какой блок он открывает.

Сложные виджеты

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

Динамические сообщения

Уведомления «заявка отправлена», «товар добавлен в корзину» нужно объявлять скринридеру через aria-live. Иначе незрячий пользователь просто не узнает, что что-то произошло.

05Когда ARIA вредит

Парадокс ARIA: атрибуты задумывались для того, чтобы помогать, но при бездумном применении они делают сайт хуже. Несколько типичных ошибок, которые встречаются на сайтах малого бизнеса:

• role=”button” на ссылках и наоборот. Меняется поведение: пользователь ждёт переход, а получает другое действие, либо клавиатура работает не так, как ожидается.
• aria-label дублирует видимый текст. Если на кнопке уже написано «Отправить», добавлять aria-label="Отправить заявку" не нужно — скринридер прочитает только aria-label и проигнорирует видимый текст.
• aria-hidden на интерактивных элементах. Если скрыть от скринридера кнопку, пользователь увидит её глазами, дойдёт по Tab, но программа доступа не озвучит, что это. Полный разлад.
• Лишние роли на семантических тегах. <nav role="navigation"> — избыточно: тег уже несёт эту роль.

Поэтому когда видите на проекте «доступность по WCAG», стоит уточнить, как именно она реализована. Это часть общей программы — мы пишем про неё подробнее в обзоре WCAG для малого бизнеса простыми словами.

06Что спросить у разработчика

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

• Кнопки и ссылки сделаны нативными тегами <button> и <a>?
• Все поля формы имеют текстовые метки, а не только плейсхолдеры?
• Модальные окна, табы и аккордеоны работают с клавиатуры — Tab, Enter, Esc?
• Если на странице есть кастомные виджеты, какие ARIA-атрибуты на них стоят и зачем?
• Запускали ли проверку через Lighthouse и слушали ли страницу скринридером?

Если ответы внятные — у разработчика есть культура доступности. Если в ответ звучит «ARIA не нужна, мы и так нормально сверстали», стоит проверить сайт самостоятельно или включить аудит в работу. Доступная разработка обычно идёт в связке с общим качеством сайта — мы делаем это в рамках создания сайтов.

Официальная документация по теме — Справка Яндекс.Вебмастера.