ARIA-разметка (labels / roles)

ARIA-разметка — это добавление атрибутов доступности (роли, метки aria-label/aria-labelledby, состояния aria-expanded/aria-checked и т.п.) к элементам, которым не хватает встроенной семантики HTML: кастомные меню, табы, аккордеоны, слайдеры, модалки, динамические области. Это позволяет скринридерам корректно объявлять, что это за элемент, как он называется и в каком он состоянии. Честно про главный принцип, это ключевое: первое правило ARIA — «не используй ARIA, если задачу решает нативный HTML». Обычная кнопка `<button>` доступна сама по себе; ARIA нужна там, где штатной семантики нет. Честно про риск: НЕПРАВИЛЬНАЯ ARIA хуже её отсутствия — неверная роль или несинхронизированное состояние ломает озвучивание и путает пользователя сильнее, чем «голый» элемент. Поэтому это работа для аккуратной руки и тестирования, а не «навешать атрибутов». Честно про границу: ARIA — точечный инструмент, она НЕ делает сайт доступным сама по себе и не заменяет правильную семантику, клавиатурную доступность (806) и тестирование скринридерами (805) — работает в связке. Честно про процесс: при изменении компонентов ARIA нужно поддерживать (рассинхрон состояний — частый баг). Честно про эффект: корректная ARIA делает сложные виджеты понятными для вспомогательных технологий; прямой рост продаж не гарантируем. Честно про доступ: нужен доступ к коду/шаблонам. Важная граница: это ARIA; адаптация под скринридеры в целом — 805, клавиатура — 806. Представьте: вместо «скринридер не понимает, что это за кастомный элемент» — он корректно объявляет роль, имя и состояние. Базовая цена — от 18 000 ₽ (зависит от числа компонентов).

• Скринридер не понимает кастомные виджеты — они «немые».
• Состояния (открыто/выбрано) не объявляются вспомогательным технологиям.
• ARIA навешана неправильно и ломает озвучивание.
• Кастомные меню/табы/слайдеры недоступны для незрячих.

• Аудит, где реально нужна ARIA (а где хватит нативного HTML)
• Корректные роли, метки (aria-label/labelledby)
• Корректные состояния (aria-expanded/checked/selected и т.п.)
• Синхронизация состояний с реальным поведением
• Тестирование скринридером (что объявляется верно)
• Указание границ (ARIA — точечно, не замена семантики)
• Связка с клавиатурой (806) и скринридерами (805)
• Передача и разбор с вами

• Сложные виджеты понятны вспомогательным технологиям
• Роли, имена и состояния объявляются корректно
• ARIA применена точечно и правильно (без вреда)
• Доступные кастомные компоненты (в связке с 805/806)

• Определяем, где нужна ARIA, а где достаточно HTML; собираем доступ
• Добавляем корректные роли/метки/состояния, синхронизируем
• Тестируем скринридером, даём план поддержки, разбираем с вами

• Давайте просто навесим ARIA везде для надёжности?

  Нет, это вредно. Главное правило ARIA — не использовать её там, где хватает нативного HTML, а неправильная ARIA ХУЖЕ её отсутствия: неверная роль или несинхронизированное состояние ломает озвучивание и путает пользователя. Мы применяем ARIA точечно и с тестированием, а не «на всякий случай везде».

• ARIA сделает сайт доступным?

  Сама по себе — нет. ARIA — точечный инструмент для сложных виджетов, но она не заменяет правильную семантику, клавиатурную доступность (806) и тестирование скринридерами (805). Доступность — это связка слоёв. Честно подскажем, что нужно в комплексе, а не выдаём ARIA за всё решение.

• Это нужно поддерживать?

  Да. При изменении компонентов состояния ARIA легко рассинхронизировать с реальным поведением (частый баг: визуально открыто, а aria-expanded=false). Доступность — процесс: дадим рекомендации, чтобы новые и изменённые компоненты сразу размечались корректно.