Доступность на фронтенде: ARIA и клавиатурная навигация - практический гайд

Представьте, что вы открываете новый сайт, но не можете увидеть его. Или видите, но мышь сломалась, а тачскрин не работает. Для миллионов людей это не гипотетическая ситуация, а повседневная реальность. Если ваш интерфейс недоступен для них, он просто не существует. Доступность (accessibility) на фронтенде перестала быть «приятным бонусом» и стала обязательным требованием к качеству продукта.

В этом материале мы разберем два ключевых инструмента, которые позволяют сделать веб-интерфейсы понятными для всех пользователей: ARIA и правильную клавиатурную навигацию. Мы не будем углубляться в теорию ради теории, а сразу перейдем к тому, как эти технологии работают в коде и почему их игнорирование приводит к потере аудитории.

Почему доступность важна прямо сейчас

Многие разработчики думают, что доступность нужна только людям с серьезными нарушениями зрения. Но статистика говорит об обратном. По данным ВОЗ, около 2,5 миллиарда человек в мире имеют различные степени нарушений зрения. Однако проблема шире:

Когда вы делаете интерфейс доступным, вы улучшаете его для всех. Хорошая семантика HTML помогает поисковым роботам лучше понимать структуру страницы. Четкие фокус-стили делают интерфейс более отзывчивым. А правильная работа с ARIA снижает нагрузку на JavaScript-логику, так как браузер берет часть ответственности на себя.

ARIA: когда нативного HTML не хватает

ARIA (Accessible Rich Internet Applications) - это набор атрибутов, который добавляет дополнительные сведения о структуре и поведении элементов интерфейса для скринридеров и других вспомогательных технологий. Главное правило ARIA звучит так: «Не используй ARIA, если есть нативный HTML-элемент, который делает то же самое».

Например, вместо того чтобы создавать кнопку из <div> и добавлять ей атрибуты role="button" и обработчик onclick, лучше использовать настоящий элемент <button>. Он уже имеет правильную роль, реагирует на Enter и Space, и его легко найти через CSS.

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

Базовые принципы клавиатурной навигации

Клавиатурная навигация - это способность пользователя перемещаться по странице, взаимодействовать с элементами и выполнять задачи, используя только клавиши Tab, Shift+Tab, Enter, Space и стрелки.

Для этого нужно соблюдать несколько фундаментальных правил:

1. Логичный порядок фокуса. Элементы должны получать фокус в том же порядке, в котором они появляются визуально сверху вниз и слева направо. Не ломайте этот порядок с помощью отрицательных значений z-index или абсолютного позиционирования без необходимости.
2. Видимый индикатор фокуса. Никогда не удаляйте стандартные рамки фокуса (:focus) без замены на свои. Пользователь должен четко видеть, где находится курсор. Используйте контрастные цвета и достаточную толщину рамки.
3. Управление стрелками. В сложных компонентах (таблицах, списках, каруселях) пользователи ожидают, что стрелки будут перемещать фокус между элементами. Это требует написания дополнительной логики на JavaScript.
4. Захват и освобождение фокуса. Когда открывается модальное окно, фокус должен попасть внутрь него. Когда оно закрывается, фокус должен вернуться на тот элемент, который открыл окно.

Если пользователь не может завершить задачу с клавиатуры, значит, интерфейс сломан для части аудитории.

Практические примеры использования ARIA

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

<div id="alert-container" aria-live="polite" aria-atomic="true">
  <!-- Сюда будет вставлено сообщение -->
</div>

Атрибут aria-live="polite" говорит скринридеру, что изменения внутри этого контейнера нужно озвучить, но не прерывая текущее чтение. Значение assertive использовалось бы для критически важных ошибок, которые требуют немедленного внимания.

Еще один пример - табы. Вместо создания собственных механик переключения, можно использовать паттерн, описанный в WAI-ARIA Authoring Practices Guide. Ключевые атрибуты здесь: role="tablist", role="tab", role="tabpanel" и состояние aria-selected.

Типичные ошибки и как их избежать

Даже опытные разработчики часто допускают одни и те же промахи. Вот список самых частых проблем, которые я встречаю в код-ревью:

• Лишние роли. Добавление role="button" к элементу <a href="#">. Лучше использовать <button> или, если ссылка ведет на другую страницу, оставить ее как есть.
• Невидимый текст для скринридера. Использование display: none для скрытия текста, который должен читаться. Правильный инструмент - класс .visually-hidden, который скрывает текст визуально, но оставляет его доступным для вспомогательных технологий.
• Отсутствие имен для форм. Поле ввода без связанного <label>. Скринридер скажет «поле ввода», но не даст понять, какие данные туда вводить. Всегда связывайте label с input через атрибут for и id.
• Сложная структура без заголовков. Страница без иерархии <h1>, <h2>. Пользователи скринридеров часто навигируют по заголовкам, чтобы быстро ориентироваться.

Инструменты для проверки доступности

Ручное тестирование обязательно, но автоматизация экономит время. Вот базовый набор инструментов, который стоит держать под рукой:

• DevTools Chrome/Firefox. Вкладка Accessibility показывает дерево доступности и подсказывает об ошибках.
• WAVE. Браузерное расширение, которое визуализирует проблемы с контрастом, отсутствием альтернативных текстов и другими аспектами.
• axe DevTools. Более глубокий анализатор, который интегрируется с DevTools и находит сложные логические ошибки ARIA.
• Скринридеры. JAWS, NVDA (для Windows) и VoiceOver (для macOS/iOS). Тестирование хотя бы одним из них дает понимание реального пользовательского опыта.

Автоматические инструменты находят около 30-40% проблем. Остальные требуют человеческого глаза и логики.

Как внедрить доступность в рабочий процесс

Доступность не должна быть этапом после разработки. Она должна присутствовать на каждом этапе жизненного цикла проекта.

1. Дизайн. Убедитесь, что контраст цветов соответствует стандартам WCAG AA (минимум 4.5:1 для обычного текста). Предусмотрите состояния фокуса в макетах.
2. Разработка. Используйте семантические теги по умолчанию. Применяйте ARIA только там, где это необходимо. Пишите чистый, предсказуемый JavaScript для управления фокусом.
3. Тестирование. Проведите ручное тестирование с клавиатуры. Запустите автоматические сканеры. Попросите коллегу пройти основной путь пользователя, используя только клавиатуру и скринридер.

Это требует времени, но экономит деньги на переделках и судебных исках, которые становятся все более частыми в США и Европе из-за требований ADA и EAA.

Часто задаваемые вопросы