ARIA следует применять там, где семантики HTML недостаточно для передачи роли, состояния или назначения элемента вспомогательным технологиям. Главный принцип прост: сначала выбирают подходящий нативный тег, а затем добавляют только недостающую информацию. Избыточные атрибуты не делают страницу доступнее и иногда скрывают исходный смысл элемента.
Когда ARIA действительно нужна?
ARIA полезна для сложных компонентов: раскрывающихся панелей, вкладок, модальных окон, динамических уведомлений и собственных элементов управления. Обычной кнопке, ссылке или полю ввода дополнительные роли чаще всего не требуются.
Нативный HTML уже сообщает браузеру многое. Элемент <button> доступен с клавиатуры, получает фокус и распознаётся скринридером как кнопка. Если вместо него взять <div role="button">, поведение придётся создавать вручную: добавить фокус, обработать Enter и пробел, предусмотреть отключённое состояние.
ARIA меняет представление элемента в дереве доступности, но не добавляет ему функций. Атрибут role="checkbox" не научит блок переключаться, а aria-disabled="true" сам по себе не остановит обработчик клика. Здесь проходит важная граница между описанием интерфейса и его реальным поведением.
Как подписывать элементы для скринридера?
У интерактивного элемента должно быть понятное доступное имя. Лучше всего использовать видимую подпись: она одновременно помогает людям, читающим экран, пользователям голосового управления и тем, кто работает со скринридером.
| Способ | Когда подходит | Что проверить |
|---|---|---|
| Текст внутри элемента | Для кнопок и ссылок с видимой подписью | Название ясно без соседнего контекста |
aria-labelledby |
Когда подпись уже есть в другом элементе | Указанный id существует и уникален |
aria-label |
Для элемента без видимого текста, например кнопки с иконкой | Имя точно описывает действие |
aria-describedby |
Для подсказки, ограничения или сообщения об ошибке | Описание дополняет, а не заменяет название |
У кнопки с крестиком подпись «Закрыть окно» полезнее, чем «Крестик». Название должно передавать действие, а не внешний вид. При этом aria-label может заменить исходное доступное имя, поэтому его не следует добавлять «на всякий случай» к элементам с ясным текстом.
Как передавать состояние динамического компонента?
Состояние нужно обновлять одновременно с визуальным изменением компонента. Если меню открылось, значение aria-expanded должно стать true; после закрытия — вернуться к false.
Для кнопки раскрытия часто используют aria-controls, указывающий на идентификатор связанной области. Он описывает отношение между элементами, но не заменяет управление фокусом и видимостью. Скрытая панель не должна оставлять внутри себя доступные по Tab ссылки и кнопки.
Динамические сообщения, которые появляются без перевода фокуса, иногда помещают в область aria-live. Так можно сообщить о результате поиска, сохранении формы или ошибке. Однако каждое обновление озвучивать не нужно: частые объявления перебивают текущую речь скринридера и превращают работу со страницей в поток сигналов.
Как проверить доступность на практике?
Автоматическая проверка находит часть ошибок, но не оценивает понятность названий и последовательность действий. Компонент нужно пройти с клавиатуры, проверить в дереве доступности браузера и хотя бы выборочно прослушать скринридером.
- Перемещайтесь клавишей Tab и убедитесь, что фокус виден на каждом интерактивном элементе.
- Проверьте работу кнопок клавишами Enter и пробел, а раскрывающихся списков — предусмотренными для них клавишами.
- Сравните видимую подпись с именем, которое показывает дерево доступности.
- Откройте и закройте динамический компонент, наблюдая за изменением состояний ARIA.
- Убедитесь, что после закрытия модального окна фокус возвращается к элементу, который его открыл.
- Прослушайте сообщения об ошибках и проверьте, понятно ли, к какому полю они относятся.
Особенно полезна проверка без мыши. Она быстро обнаруживает элементы, которые выглядят как кнопки, но не получают фокус, а также панели, из которых невозможно выйти. Видимый контур фокуса в этот момент работает как луч фонаря: показывает реальный маршрут по интерфейсу.
Надёжная реализация обычно начинается не с набора атрибутов, а с выбора правильного HTML-элемента. ARIA дополняет эту основу там, где компонент сложнее стандартной кнопки или поля. Если роль, имя, состояние и клавиатурное поведение согласованы, интерфейс остаётся понятным и на экране, и при озвучивании.