Приходилось ли работать с доступностью и требованиями к ней

Что проверяют

Знаете ли вы доступность как требование с проверяемыми критериями, а не как набор атрибутов, которые дописывают в конце спринта. Смотрят, отличаете ли вы семантику от ARIA и проходили ли свой интерфейс клавиатурой и скринридером.

Как отвечать

Главная мысль: доступность начинается с нативной семантики. Кнопка, ссылка, поле с подписью и заголовки нужного уровня бесплатно дают роль, фокус и работу с клавиатуры, а div с обработчиком клика не даёт ничего. Отсюда и правило: ARIA применяют, когда подходящего элемента нет, и она дополняет разметку, а не заменяет её.

Что стоит перечислить из практики:

• клавиатура: логичный порядок обхода, видимый фокус, удержание фокуса внутри модального окна и возврат на кнопку после закрытия, реакция на Escape;
• формы: подпись связана с полем, ошибка передаётся текстом и объявляется через aria-live, состояние поля через aria-invalid;
• восприятие: контраст текста, смысл не только цветом, работоспособность при увеличении шрифта, осмысленный alt и пустой у декоративных картинок;
• одностраничные приложения: смена маршрута сама себя не объявляет, нужен перенос фокуса на заголовок нового экрана.

Требования формулируются через критерии WCAG, обычно уровень AA, и попадают в задачу наравне с остальными.

Где спотыкаются

Делают кнопку из div: навешивают роль и tabindex, а обработку Enter и пробела, недоступное состояние и стиль фокуса забывают. Получается элемент, который скринридер называет кнопкой, но нажать его с клавиатуры нельзя.

Полагаются на автоматические проверки. Линтер и аудит ловят лишь часть, в основном формальную: контраст, отсутствие подписи, дубли идентификаторов. Осмысленность текста ссылки, порядок чтения и проходимость сценария проверяются только руками.

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