Что относится к доступности в Web помимо клавиатуры и скрин-ридера

Вопрос проверяет, не воспринимаете ли вы accessibility как набор приемов только для незрячих пользователей. Клавиатура и скрин-ридер важны, но доступность шире. Она касается людей с плохим зрением, дальтонизмом, нарушениями слуха, моторными ограничениями, вестибулярной чувствительностью, когнитивной нагрузкой, временными травмами и разными условиями использования.

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

На интервью удобно назвать несколько направлений и сразу показать, что вы понимаете практику:

• семантический HTML и правильные нативные элементы;
• контраст, размер текста, zoom и адаптивность;
• доступные формы, понятные ошибки и сохранение введенных данных;
• альтернативный текст для изображений и текстовые альтернативы для медиа;
• управление анимациями через prefers-reduced-motion;
• язык страницы через lang, ясные тексты и понятные состояния;
• тестирование реальных сценариев, а не только зеленый отчет инструмента.

Так вы показываете, что accessibility для вас не отдельный чеклист в конце задачи, а часть проектирования UI.

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

Плохой пример:

<div className="button" onClick={submitForm}>
  Отправить
</div>

Визуально это может выглядеть как кнопка, но поведение нужно собирать вручную. Это фокус, активация с клавиатуры, disabled-состояние, имя элемента. Без этого пользователь может не дойти до действия, Enter или Space не сработают, а состояние отправки формы будет непонятным.

Безопаснее:

<button type="submit" className="button">
  Отправить
</button>

На интервью можно сказать так: "Я стараюсь сначала использовать нативные элементы и семантику. ARIA добавляю там, где нативного поведения не хватает, например в сложных кастомных компонентах".

Доступная форма не ограничивается наличием label. Пользователь должен понимать, что от него ждут, где ошибка, как ее исправить и что произошло после отправки.

<label htmlFor="email">Email</label>
<input
  id="email"
  name="email"
  type="email"
  aria-describedby="email-hint email-error"
  aria-invalid="true"
/>
<p id="email-hint">Мы отправим подтверждение на этот адрес.</p>
<p id="email-error">Введите email в формате name@example.com.</p>

В реальном проекте aria-invalid стоит ставить только когда поле действительно в ошибке. Если ошибка появляется после submit, не очищайте введенные данные без причины. Потеря ввода после ошибки это плохой UX и частая причина брошенной формы. Если текст ошибки рендерится условно, следите, чтобы aria-describedby не ссылался на несуществующий элемент.

Доступность касается не только структуры DOM. Видео без субтитров недоступно для человека, который не слышит звук или смотрит ролик в шумном месте. Иконка без текста может быть непонятна. Текст с низким контрастом сложно читать при плохом зрении, ярком солнце или некачественном экране. Маленькая зона клика плохо работает на сенсорных устройствах и для людей с моторными ограничениями.

Для анимаций важно учитывать системную настройку пользователя:

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    scroll-behavior: auto !important;
    transition-duration: 0.01ms !important;
  }
}

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

Хорошая структура ответа простая:

1. Сначала скажите, что доступность шире одного способа ввода или одного типа assistive technology.
2. Затем назовите области: семантика, контраст, масштабирование, формы, ошибки, медиа, движение, язык, понятность текста.
3. После этого добавьте, как вы проверяете качество: ручные сценарии плюс автоматические инструменты.

Пример короткого ответа:

Помимо клавиатуры и скрин-ридера я думаю про читаемость, контраст, масштабирование, доступные формы, ошибки, альтернативы для медиа, уменьшение анимации, язык страницы и понятные состояния. Для меня accessibility это способность пользователя завершить сценарий без лишних барьеров. Поэтому я не ограничиваюсь audit score, а прохожу ключевые flow вручную и проверяю места, где чаще всего ломается UX.