Почему доступность ломается не в дизайне, а на уровне мелких UI-решений

Почему доступность ломается не в дизайне, а на уровне мелких UI-решений

Чаще всего a11y портят не «сложные кейсы», а базовые паттерны:
— контраст текста и фона выглядит нормально в макете, но проваливается в сером и disabled-состояниях;
— кнопка выглядит как ссылка, а ссылка — как кнопка;
— фокус есть только у клавиатуры, но его не видно;
— ошибка показана красным текстом, без связи с полем и без подсказки, как исправить.

Что важно: доступность — это не отдельный слой в конце проекта, а часть логики интерфейса. Если элемент нельзя понять по цвету, форме, порядку таба и тексту без контекста, он уже требует доработки. Для продукта это не «улучшение для меньшинства», а снижение количества ошибок у всех пользователей.

Что делать на практике:
— проверять каждый интерактивный элемент без мыши;
— не полагаться только на цвет для статуса и ошибок;
— писать понятные label и helper text, а не «красивые» заглушки;
— держать видимый focus state;
— делать кликабельную область больше визуальной иконки.

Хороший accessibility-чек — это не аудит на полдня, а привычка смотреть на интерфейс через 4 вопроса: видно ли, понятно ли, достижимо ли с клавиатуры и можно ли исправить ошибку без догадок.