Доступность - тема, которую почти все согласны делать и которую почти никто не делает. Расскажем, что у нас в студии встроено в процесс, чтобы a11y перестал быть «отдельной задачей в бэклоге».
Минимальная база
- Семантический HTML. <button> для кнопок, <a href> для ссылок, не <div onClick>.
- Клавиатурная навигация работает на всём. Tab, Shift+Tab, Esc, Enter - без сюрпризов.
- Контраст текста и фона минимум 4.5:1 (WCAG AA). Проверяем на дизайн-ревью, не на разработке.
- Все формы - с метками и связанными ошибками.
- Focus visible - никогда не убираем outline без замены.
Что у нас в pre-commit
ESLint-плагин eslint-plugin-jsx-a11y в strict-режиме. Не пропускает PR без alt у картинок, без onClick без role, без onKeyDown к интерактивным div'ам. Минимальный фильтр 80% типичных ошибок.
Что у нас в CI
axe-core прогон на критичных страницах в Playwright. Любая новая ошибка accessibility блокирует merge, как тестовая. Это самый эффективный способ из всего, что мы пробовали.
Какие компоненты пишем сами
Любой компонент со сложной семантикой (combobox, modal, accordion, tabs) - берём из Radix UI или React Aria. Своих не пишем - слишком много a11y-нюансов, на которых ломаются даже опытные команды.
Что не делаем
- Не клеим accessibility-плагин для overlay-баннера. Это не помогает реальным пользователям.
- Не считаем, что aria-label всегда исправляет ошибку - часто это попытка спрятать плохую структуру.
- Не оставляем accessibility QA только на финальную фазу. К этому моменту переписывать дороже.