Коротко и по делу.
Почему это плохая практика
- Браузер и AT (скрин‑ридеры, клавиатурные навигаторы) ожидают семантические элементы. div без роли и tabindex:
- не фокусируется по Tab → недоступен для клавиатурных пользователей;
- не объявляется скрин‑ридером → незаметен для пользователей AT;
- не обрабатывает клавиши Enter / Space по умолчанию → поведение отличается от ожидаемого кнопки;
- лишает вас доступных состояний (disabled, pressed) и нативных взаимодействий (формы, submit).
- UX: пользователи с ограничениями не смогут выполнить действие; ухудшается восприятие и доверие; возможны потери конверсии.
- Юридически: риск несоответствия требованиям WCAG $2.1$ Level AA и соответствующим законам/стандартам (ADA/Section 508 в США, EN $301549$ / EU Accessibility Directive и др.) — возможны претензии и санкции.
Правила семантического HTML и ARIA
- Всегда предпочитайте нативный элемент:
- Используйте \ для кнопок (лучшее поведение, управление фокусом, состояния).
- Используйте \ для навигации.
- ARIA — только когда нативного элемента недостаточно:
- Не заменяйте нативное поведение ролью: «If you can use a native HTML element, use that instead» (WAI‑ARIA).
- Если вынуждены использовать див, добавьте минимум: role="button", tabindex="0", обработку клавиш Enter и Space, и корректные aria‑атрибуты (например, aria-pressed для переключателей).
- Управление состояниями:
- Используйте нативный disabled на \ или aria-disabled="true" + предотвращение взаимодействия, если нативного атрибута нет.
- Для раскрывающихся/переключаемых контролов — aria-expanded, aria-controls, aria-pressed и т.п.
- Визуальная доступность:
- Не убирайте outline для :focus; вместо этого стилизуйте фокус явно.
- Убедитесь в достаточном контрасте (соответствие WCAG).
Практические требования для реализации (минимум)
- Лучший вариант:
- \Label\ - Если невозможно использовать \, минимум:
- \Label\ - Обработчики: click + keydown (Enter → запуск; Space → preventDefault() + запуск).
- Не забыть скрыть от AT, если декоративно: aria-hidden="true".
- Тестируйте поведение клавиатуры и состояния фокуса вручную.
Тестирование доступности (что и как проверять)
- Ручное:
- Клавиатурный тест: навигация Tab / Shift+Tab, активация Enter/Space, последовательность фокуса.
- Скрин‑ридер: проверить с NVDA (Windows), JAWS, VoiceOver (macOS/iOS), TalkBack (Android).
- Мобильные жесты и фокус на сенсорных устройствах.
- Автоматизированные инструменты:
- axe‑core, Lighthouse, WAVE, Pa11y — обнаружат многие проблемы, но не все.
- Контрольные пункты:
- Фокус доступен и видим;
- Действие доступно с клавиатуры;
- Элемент озвучивается корректно скрин‑ридером (label, role, state);
- Порядок табуляции логичен;
- Контраст текста и элементов соответствует WCAG $2.1$ (уровень AA).
- Процесс:
- Включить accessibility checks в CI (axe‑core), + периодические ручные проверки с реальными пользователями с инвалидностью.
Влияние на UX и юридические последствия
- UX: ухудшение для людей с моторными, зрительными и когнитивными ограничениями; больше ошибок, бОльшая фрустрация, снижение конверсии и удержания.
- Закон/соответствие: многие юрисдикции требуют соответствия WCAG $2.1$ Level AA; несоответствие может привести к жалобам, судебным искам и репутационным рискам.
Краткий чек‑лист для исправления кнопки (минимум)
- Использовать \, или:
- добавить role="button", tabindex="0";
- реализовать Enter/Space в keydown (Space — preventDefault);
- не убирать :focus, обеспечить видимый фокус;
- добавить aria‑атрибуты для состояний;
- протестировать клавиатурой и скрин‑ридером.
Если нужно — пришлите фрагмент кода кнопки, и я покажу исправление.