Что такое Accessibility

Accessibility, или доступность, отвечает на простой вопрос: сможет ли человек выполнить задачу в интерфейсе, если он не пользуется мышью, плохо видит, использует screen reader, увеличивает масштаб, не различает часть цветов или работает с другим устройством ввода.

На интервью не стоит отвечать как словарь. Лучше сразу связать определение с фронтендом. Доступность появляется в HTML-разметке, CSS, обработке событий, формах, маршрутизации, модальных окнах и сообщениях об ошибках.

Короткая формулировка может быть такой:

Accessibility это практика разработки интерфейсов, которыми могут пользоваться разные люди в разных условиях. Во фронтенде это означает семантический HTML, доступность с клавиатуры, видимый фокус, достаточный контраст, понятные тексты и корректную поддержку assistive technologies.

Доступность часто ломается не из-за сложных стандартов, а из-за простых решений в коде. Например, интерактивный div выглядит как кнопка, но для клавиатуры и screen reader это может быть просто блок текста.

<!-- Плохо: выглядит как кнопка, но не является кнопкой -->
<div class="button" onclick="openDialog()">Open settings</div>

<!-- Лучше: нативный элемент уже имеет базовое поведение -->
<button type="button" onclick="openDialog()">
  Open settings
</button>

В первом варианте легко забыть фокус, Enter, Space, роль и имя элемента. Итог простой. Пользователь клавиатуры может не открыть модальное окно, а screen reader не сообщит, что перед ним действие. Во втором варианте браузер уже дает большую часть ожидаемого поведения. Поэтому на интервью полезно сказать: сначала выбираю правильный HTML, потом добавляю ARIA только если нативной семантики недостаточно.

WCAG это набор критериев, который помогает понять, насколько интерфейс доступен. В коротком ответе достаточно назвать идею и уровни A, AA, AAA. Часто продуктовые интерфейсы ориентируют на AA, но конкретные требования зависят от продукта, страны, договора и аудитории.

ARIA это способ добавить семантику там, где HTML не может выразить нужное состояние или роль. Но ARIA не исправляет плохую интерактивность автоматически. Если элемент объявлен как кнопка через role="button", вам все равно нужны фокус, обработка клавиш и понятное доступное имя.

Сильная формулировка:

Я не начинаю с ARIA. Сначала проверяю, можно ли решить задачу нативным HTML. Если делаю сложный кастомный компонент, тогда добавляю роли, состояния и клавиатурное поведение по паттерну, а потом проверяю это вручную.

Если сценарий нельзя пройти клавиатурой, он недоступен для части пользователей. Это касается не только людей с моторными ограничениями. Клавиатурой пользуются power users, пользователи временно сломанной мыши, некоторые пользователи screen reader и люди с нестандартными устройствами ввода.

Минимальная проверка: открыть страницу, нажимать Tab, Shift+Tab, Enter, Space и Escape. Фокус должен идти в логичном порядке, быть видимым и не проваливаться в скрытые элементы. Модальное окно должно получать фокус при открытии и возвращать его назад при закрытии.

Плохой признак в CSS:

/* Плохо: пользователь клавиатуры теряет ориентир */
*:focus {
  outline: none;
}

Безопаснее оставить стандартный фокус или задать свой заметный стиль через :focus-visible. Если дизайн требует кастомного фокуса, проверьте его на темном и светлом фоне, при масштабировании и в состоянии ошибки.

В SPA пользователь может нажать кнопку, а страница изменится без полной перезагрузки. Визуально это понятно, но screen reader может не сообщить о важном изменении. Поэтому для статусов, ошибок и результатов действий нужно продумать, как пользователь узнает, что произошло.

<p id="save-status" role="status" aria-live="polite"></p>

<script>
  document.getElementById("save-status").textContent = "Profile saved";
</script>

Такой пример подходит для ненавязчивого статуса. Для ошибок формы часто важнее связать сообщение с конкретным полем через aria-describedby и показать текст рядом с полем. Для модальных окон и переходов между экранами важнее управление фокусом, иначе пользователь остается в старом контексте.

Хороший ответ не обещает абсолютную доступность после одного инструмента. Лучше назвать несколько уровней проверки.

1. Семантика: кнопки являются кнопками, ссылки имеют href, заголовки идут в понятной структуре.
2. Клавиатура: основной сценарий проходится без мыши, фокус виден и не попадает в скрытый контент.
3. Визуальная читаемость: контраст, масштабирование, отсутствие смысла, который передается только цветом.
4. Формы: label связан с полем, ошибки видимы и озвучиваются, подсказки не исчезают навсегда.
5. Инструменты: axe, WAVE, Lighthouse и ручная проверка со screen reader для критичных сценариев.

На интервью это звучит практично. Вы показываете не только знание терминов, но и способ не пропустить баг в реальном продукте.