Доступные интерфейсы

Вы создадите интерфейс, которым можно пользоваться клавиатурой и assistive technology, и закрепите ключевые гарантии тестами.

До начала достаточно DOM semantics, forms, component design и Testing Library. В конце должен появиться не конспект, а доступный Dialog и форма с focus lifecycle, описанными ошибками и keyboard contract.

Используйте button для действия, a для навигации, input/select для ввода, headings в логической иерархии. Нативный control уже имеет role, keyboard и platform behavior. Custom role требует воспроизвести всё вручную и легко ломается.

Рабочая проверка. Замените clickable div на button без изменения внешнего вида.

Типичная поломка. <div role="button" onClick> без tabindex/keyboard.

Control получает имя из label, текста, aria-label или aria-labelledby по алгоритму. Placeholder не заменяет label. Description связывают aria-describedby с hint/error. Имена должны оставаться понятными вне визуального контекста «нажмите сюда».

Рабочая проверка. Проверьте controls через getByRole с name.

Типичная поломка. Icon-only button без accessible name.

Все действия доступны стандартной клавиатурой, focus order следует DOM и visual flow, focus indicator заметен. Не ставьте positive tabindex для ручной перестановки. Composite widgets следуют APG pattern с roving tabindex или aria-activedescendant, а не изобретают случайные клавиши.

Рабочая проверка. Пройдите workflow Tab/Shift+Tab/Enter/Space/Escape.

Типичная поломка. outline: none без равноценной focus-visible замены.

При открытии modal focus переходит внутрь на осмысленный элемент, Tab остаётся в dialog, фон недоступен, Escape закрывает по contract, после закрытия focus возвращается trigger или логичному successor. Focus trap должен учитывать динамические controls и nested overlays.

Рабочая проверка. Откройте/закройте Dialog клавиатурой и удалите trigger во время операции.

Типичная поломка. Фокус остаётся на hidden/background element.

Error связывается с полем через aria-describedby, invalid state — aria-invalid, summary помогает перейти к ошибкам после submit. Текст объясняет исправление; цвет/иконка дополняют, но не являются единственным сигналом. Focus не должен прыгать на каждой клавише.

Рабочая проверка. Отправьте форму и проверьте announcement summary и field descriptions.

Типичная поломка. Красная рамка без текста и связи.

Изменения вне focus, важные пользователю, объявляются status/alert с подходящей срочностью. Не делайте весь app aria-live: поток станет шумом. Element live region лучше присутствует до обновления текста. Loading announcements не должны повторяться на каждый render.

Рабочая проверка. Озвучьте результат фонового сохранения один раз.

Типичная поломка. aria-live assertive на весь список результатов.

Интерфейс должен работать при zoom/reflow, large text и narrow viewport без двумерной прокрутки основного content. Не фиксируйте высоту текста и не запрещайте user zoom. Touch targets имеют достаточный размер/spacing. Landscape и reduced motion — отдельные условия.

Рабочая проверка. Проверьте 200% zoom и ширину 320 CSS px.

Типичная поломка. Обрезать перевод строки fixed-height card.

ESLint/axe ловят отсутствующие labels, роли и часть отношений. Component tests проверяют name/focus, browser E2E — keyboard/reflow, ручная проверка — screen reader и когнитивный UX. Нулевой автоматический score не доказывает соответствие WCAG.

Рабочая проверка. Составьте checklist automated + keyboard + screen reader для critical path.

Типичная поломка. Объявить приложение доступным после одного axe run.

Исправьте командную панель: div-кнопки, focus trap без возврата, невидимые labels, ошибки только цветом и неозвученный async result. Добавьте semantic controls, dialog labeling, focus restore и axe/keyboard tests.

Критерий завершения: критический сценарий проходит только клавиатурой, focus видим, accessible tree осмыслен, автоматический аудит не находит известных нарушений. Сначала зафиксируйте наблюдаемое поведение тестом или измерением, затем меняйте реализацию.