ARIA

Определение

ARIA (WAI-ARIA, Accessible Rich Internet Applications) – стандарт W3C: атрибуты role и aria-*, передающие вспомогательным технологиям роль, свойства и состояния элементов интерфейса. Актуальная версия – 1.2 (2023).

4 мин 70 21 июля 2026 Обновлено 12 августа

ARIA (полностью WAI-ARIA, Accessible Rich Internet Applications) – спецификация Web Accessibility Initiative, инициативы W3C по веб-доступности. Она появилась как ответ на эпоху динамических интерфейсов: вкладки, аккордеоны, модальные окна и автодополнение собираются из div и span, у которых нет встроенного смысла. ARIA добавляет этот смысл прямо в разметку: атрибут role описывает, чем элемент является, атрибуты aria-* – его свойства и текущее состояние. Скринридер благодаря им объявляет не безликий «текст», а «кнопка, свёрнуто» или «прогресс 75%». По формулировке W3C, спецификация задаёт «онтологию ролей, состояний и свойств» и дополняет нативную семантику HTML, а не заменяет её.

Как это работает

Ключевой принцип: ARIA – это no-op для всего, кроме доступности. Атрибуты не меняют DOM, внешний вид и поведение элемента. Меняется только его представление в accessibility tree – параллельной структуре, которую браузер передаёт вспомогательным технологиям через accessibility API операционной системы. Стили, фокус, обработку клавиатуры и логику на JavaScript разработчик реализует сам: ARIA лишь обещает пользователю определённое поведение, а выполнить обещание – задача кода. Все атрибуты стандарта делятся на три категории:

Три категории ARIA-атрибутов

Категория	Что описывает	Примеры
Роли (roles)	Чем элемент является для пользователя	role="button", role="progressbar", role="navigation"
Свойства (properties)	Относительно постоянные характеристики и связи	aria-label, aria-labelledby, aria-controls
Состояния (states)	Значения, меняющиеся по ходу работы интерфейса	aria-expanded, aria-checked, aria-current

Актуальная версия – WAI-ARIA 1.2, рекомендация W3C с 6 июня 2023 года. WAI-ARIA 1.3 пока остаётся рабочим черновиком (редакция от 4 июня 2026 года): в нём готовятся роли sectionheader и sectionfooter и запрет aria-hidden="true" на корневом элементе документа. Спецификация описывает более 80 ролей, разбитых на шесть категорий: abstract (служебные, авторам использовать запрещено), widget, document structure, landmark, live region и window.

Landmark-роли и их HTML-эквиваленты

Landmark-роли размечают крупные области страницы, между которыми пользователь скринридера перемещается быстрыми командами. Современный семантический HTML создаёт те же ориентиры автоматически:

Landmark-роли и семантические теги HTML

ARIA-роль	HTML-эквивалент
banner	header (верхнего уровня)
navigation	nav
main	main
complementary	aside
contentinfo	footer (верхнего уровня)
search	search
region	section с доступным именем
form	form

Зачем это нужно

ARIA закрывает ситуации, где нативной семантики не хватает: кастомные виджеты (табы, деревья, комбобоксы), динамические уведомления через live regions, связи между элементами, которые не выразить тегами. В практике на Битрикс-проектах типичные кандидаты – мобильные меню, фильтры каталога и слайдеры: штатные шаблоны компонентов часто собирают их на div, и без ролей и состояний такие виджеты для скринридера просто не существуют как интерактивные элементы. При этом главный документ W3C о применении стандарта – «Using ARIA» – начинается с запрета: первое правило ARIA – не используй ARIA, если есть нативный HTML-элемент с нужной семантикой и поведением. Всего правил в документе четыре, а не пять, как часто пишут в блогах:

Есть нативный элемент с нужной семантикой и поведением – используй его, а не div с ролью
Не меняй нативную семантику без необходимости: не заголовок с role="tab", а div с ролью и заголовок внутри него
Все интерактивные ARIA-контролы должны полностью управляться с клавиатуры, включая Enter и Space
Не ставь role="presentation" и aria-hidden="true" на фокусируемые элементы

Причину осторожности сообщество доступности формулирует как «No ARIA is better than bad ARIA»: неверная роль или несинхронизированное состояние дезинформируют пользователя, у которого нет возможности перепроверить интерфейс глазами. По данным исследования WebAIM Million, которые приводит MDN, страницы с ARIA в среднем содержат больше ошибок доступности, чем страницы без него. На SEO атрибуты aria-* напрямую не влияют – поисковики опираются на семантический HTML; связь доступности с GEO и машиночитаемостью для LLM работает через ту же семантику, а не через сами атрибуты.

Пример

Классическая ошибка – role="button" на div. Роль сообщает скринридеру «кнопка», но не даёт ни фокуса, ни реакции на Enter и Space: пользователь клавиатуры слышит кнопку, которую невозможно нажать.

<!-- Скринридер объявит «кнопка», но Tab, Enter и Space не работают -->
<div role="button" onclick="save()">Сохранить</div>

<!-- Минимально корректный вариант на div -->
<div role="button" tabindex="0" onclick="save()"
     onkeydown="if(event.key==='Enter'||event.key===' ')save()">Сохранить</div>

<!-- Правильно: то же самое даёт одна строка -->
<button onclick="save()">Сохранить</button>

А вот легитимный сценарий, где ARIA действительно нужна, – кастомный аккордеон: состояние «раскрыто/свёрнуто» передаёт атрибут aria-expanded, который JavaScript обязан переключать при каждом клике:

<button aria-expanded="false" aria-controls="panel1">Раскрыть раздел</button>
<div id="panel1" hidden>…</div>
<!-- JS при клике меняет aria-expanded на "true" и снимает hidden -->

Скринридер объявит кнопку как «раскрыто» или «свёрнуто» – но только если скрипт действительно обновляет значение. Забытая синхронизация состояния – вторая по частоте проблема после ролей без клавиатуры: например, aria-current в меню, которое не обновляется при переходе между страницами, вредит навигации не меньше, чем его отсутствие.

Частые вопросы

Как расшифровывается WAI-ARIA?

WAI – Web Accessibility Initiative, инициатива консорциума W3C по веб-доступности. ARIA – Accessible Rich Internet Applications, «доступные насыщенные интернет-приложения». Вместе это стандарт W3C, описывающий атрибуты role и aria-*, которые передают вспомогательным технологиям роль, свойства и состояния элементов интерфейса.

Чем отличаются роли, свойства и состояния ARIA?

Роль (role="button", role="tab") сообщает, чем элемент является для пользователя. Свойства – относительно постоянные характеристики и связи: aria-label, aria-labelledby, aria-controls. Состояния – значения, которые меняются по ходу работы интерфейса: aria-expanded, aria-checked, aria-current. Состояния обязан обновлять JavaScript при каждом изменении интерфейса, иначе скринридер сообщает устаревшую информацию.

В чём первое правило ARIA и сколько всего правил?

Первое правило – не использовать ARIA: если существует нативный HTML-элемент с нужной семантикой и поведением, нужно взять его, а не навешивать роль на div. В документе W3C «Using ARIA» правил четыре, а не пять, как часто пишут в блогах: нативный HTML прежде всего; не менять нативную семантику без необходимости; интерактивные ARIA-контролы обязаны работать с клавиатуры; не ставить role="presentation" и aria-hidden="true" на фокусируемые элементы.

Меняет ли ARIA внешний вид или поведение элемента?

Нет. ARIA-атрибуты не меняют DOM, стили и поведение браузера – меняется только accessibility tree, которое браузер передаёт вспомогательным технологиям через accessibility API. Фокус, реакцию на клавиатуру и всю логику разработчик реализует сам на JavaScript и CSS. Роль без подкрепляющего кода – обещание, которое интерфейс не выполняет.

Почему role="button" на div – плохая практика?

Роль лишь сообщает скринридеру «это кнопка», но div не получает фокус и не реагирует на Enter и Space. Чтобы довести его до корректного состояния, нужны tabindex="0" и JS-обработчики клавиатуры, а нативный button даёт всё это из коробки одной строкой. Это типовой пример нарушения первого правила ARIA.

Какая версия ARIA актуальна?

WAI-ARIA 1.2 – рекомендация W3C с 6 июня 2023 года, на неё стоит ориентироваться в продакшене. WAI-ARIA 1.3 существует в статусе рабочего черновика (редакция от 4 июня 2026 года): в нём готовятся роли sectionheader и sectionfooter и запрет aria-hidden="true" на корневом элементе документа.

Влияет ли ARIA на SEO?

Напрямую нет: подтверждений, что поисковики учитывают aria-* при ранжировании, не существует – они опираются на семантический HTML. Косвенная связь есть: работа над доступностью обычно приводит к чистой семантике, а её одинаково хорошо читают скринридеры, поисковые боты и LLM-парсеры AI-поисковиков. Выигрыш для SEO и GEO даёт семантика, а не сами ARIA-атрибуты.

Связанные термины

a11y (веб-доступность) a11y – нумероним слова accessibility: между «a» и «y» стоит 11 букв. Обозначает веб-доступность – проектирование сайтов, пригодных для людей с ограничениями зрения, слуха, моторики и когнитивных функций. Главный стандарт – WCAG. aria-current aria-current – атрибут WAI-ARIA, помечающий текущий элемент в наборе: активный пункт меню, хлебную крошку, шаг чекаута, дату в календаре. Скринридер озвучивает его как «текущая страница» или «текущий шаг». aria-expanded aria-expanded – атрибут WAI-ARIA со значениями true/false: сообщает скринридеру, раскрыт ли блок, которым управляет элемент. Ставится на кнопку-триггер аккордеона или меню, а не на скрываемую панель. aria-label aria-label – атрибут WAI-ARIA, задающий элементу доступное имя (accessible name) для скринридеров. Обязателен для кнопок-иконок без текста; перекрывает видимый текст и не работает на div и span без роли. FAQPage Schema FAQPage Schema – тип разметки Schema.org для страниц с часто задаваемыми вопросами и ответами. С 8 августа 2023 года Google показывает FAQ rich results только для авторитетных правительственных и медицинских сайтов, но для AI-поиска разметка остаётся одним из самых сильных сигналов цитируемости. GEO GEO (Generative Engine Optimization) – оптимизация контента под цитируемость в AI-поисковиках: ChatGPT, Perplexity, Google AI Overviews, Яндекс Алиса AI. Термин ввели исследователи Принстона, Georgia Tech, Allen Institute и IIT Delhi в работе на arXiv от 16 ноября 2023 года.

Материалы по теме

Что почитать дальше по этой теме

Статья Что боты находят на сайте, а вы – нет Боты ходят по изнанке сайта, куда живой человек не забредёт, и фиксируют в логах то, чего не видно ни в Метрике, ни на витрине: падающие с ошибкой 500 страницы каталога, битый файл с 747 обращениями, поток сканеров секретов. Разбираю на реальных логах, что искать и как чинить. 7 мин 216 22 июля 2026 Инструкция Как выгрузить и читать access-логи, если хостинг хранит их три дня Access-лог – единственное место, где виден весь трафик сайта, включая ИИ-ботов, которых не замечают счётчики. Разбираю на практике: где взять логи, как не потерять их из-за ротации, какие команды показывают ботов, ошибки и подозрительную активность. 7 мин 170 21 июля 2026 Флагманский гайд AI-анализ email-обращений: методика на стыке Яндекс.Метрики и Claude Code Классический email-трекинг отвечает на вопрос «откуда пришло обращение». AI-слой отвечает на вопросы, которые раньше требовали ручного аналитика: значим ли email на фоне звонков, форм и мессенджеров, почему один источник даёт качественные обращения, а другой – пустые, какие сегменты визитов предшествуют письму, что написать в ответ с учётом пути пользователя. Здесь – как я собираю это на уже имеющемся стеке: Logs API Метрики, PostgreSQL и Claude Code, без новых платных сервисов. 11 мин 297 26 мая 2026 Флагманский гайд Майкор: ИИ-аудит проекта по 4 точкам контакта Майкор – это перекрёстный ИИ-аудит проекта в 4 точках контакта: сайт, контекстная реклама, AI-поиск и Яндекс.Карты. Я анализирую каждую систему и смотрю связки между ними – где маркетинг рассказывает одно, реклама ведёт на другое, а AI-системы цитируют третий номер телефона. В одном из моих аудитов медицинской клиники в Москве у организации в индексе AI-сервисов оказалось 6 разных номеров и всего 7 упоминаний на 64 проверочных запроса – при том, что в обычной выдаче Яндекса клиника была в топ-1. Майкор закрывает такие разрывы за один аудит вместо четырёх раздельных. 16 мин 501 13 мая 2026 Гайд FAQPage Schema: как разметить блок частых вопросов и попасть в AI-ответы FAQPage schema – один из самых эффективных типов разметки для попадания в AI-ответы. Страницы с FAQPage schema цитируются AI-поисковиками в 2,7 раза чаще. В этом гайде – формат разметки, правила написания ответов для AI, реализация на 1С-Битрикс и типичные ошибки, которые обнуляют эффект. 8 мин 331 25 апреля 2026