♿ Доступность нельзя чинить одним аудитом перед релизом
Миша Просмицкий пишет о доступности как о части инженерного процесса, а не как о пункте в чек-листе. Команды теперь могут генерировать интерфейсы быстрее, чем раньше, но скорость легко маскирует базовые проблемы: кнопка оказывается div с обработчиком клика, фокус не работает, скринридер видит плоский текст, а пользователь не может оплатить заказ.
Особенно больно это становится с ИИ-кодом. Модель часто повторяет то, на чём училась: несемантичную разметку, красивые пиксели и минимум ограничений. Поэтому доступность нужно встраивать в систему заранее: правила для ИИ, доступные компоненты в дизайн-системе, проверка в pull request, Definition of Done, тесты в CI, понятная передача фокуса, подписей, состояний и порядка клавиатурной навигации. Аудиты всё ещё нужны, но они не заменяют процесс.
Внутри:
– Почему аудит доступности быстро устаревает после нескольких релизов;
– Как ИИ ускоряет создание интерфейсов и одновременно множит ошибки;
– Почему красивый компонент может быть бесполезен для скринридера;
– Зачем ограничивать ИИ правилами до генерации кода;
– Почему сложные элементы лучше брать из проверенных библиотек, а не писать заново;
– Как дизайн-система помогает масштабировать доступность на тысячи экранов;
– Какие проверки стоит встроить в ревью, Definition of Done и CI;
– Почему тесты с реальными пользователями с инвалидностью всё равно нельзя заменить линтером.
➡️
Читать статью
———
💻
Вакансии в IT и digital
😍
Про дизайн
🔥
Вакансии дизайнерам
🎨
Референсы
![Изображение канала: SINTEZ [синтез]](https://content.desigram.ru/avatar/e49acc31-0200-40e5-a80f-96711707fdbb.jpg){kind=small}