Ниже — практический пример (React) с явной проблемой доступности, описание исправления, список автоматических инструментов и способы ручного тестирования, а также как оценивать интерфейс с точки зрения разных типов нарушений.

1) Проблемный пример (React, JSX)
Пример простого переключателя уведомлений с несколькими проблемами: использован div c role="switch" без поддержки клавиатуры и фокуса, плохой цветовой контраст текста, нет явной доступной подписи/aria-label, отсутствует видимый индикатор фокуса.

Проблемный код:
function NotificationToggle({ on, setOn }) {
return (
<div
className={toggle ${on ? 'on' : 'off'}}
role="switch"
aria-checked={on}
onClick={() => setOn(!on)}
// нет tabindex, нет обработки клавиш, нет aria-label

<span className="label" style={{ color: '#bdbdbd' }}>
Notifications
);
}

Почему это плохо:

div с role="switch" требует явной поддержки клавиатуры (Enter/Space) и tabindex=0; иначе пользователи клавиатуры не смогут взаимодействовать.Поведение фокуса: браузер не показывает фокус для div, пользователь не знает, что элемент фокусируем.Цвет текста (#bdbdbd на белом) может не соответствовать требованиям контраста (низкая читаемость для людей с низким зрением).Отсутствует aria-label/информативный текст для скринридеров (в некоторых случаях визуальный текст может не быть правильно ассоциирован).Если aria-checked не синхронизируется (строкой/булевым), могут быть расхождения.

2) Исправленный вариант — лучший подход
Лучше использовать семантически корректный элемент (input[type=checkbox] + label или button с role="switch") и обеспечить:

клавиатурную доступность (Enter/Space),видимый фокус,адекватный контраст,корректные ARIA-атрибуты и/или метки.

Вариант с button (корректно реализованный переключатель):
function NotificationToggle({ on, setOn }) {
const toggle = () => setOn(!on);

return (
<button
type="button"
role="switch"
aria-checked={on}
onClick={toggle}
onKeyDown={(e) => {
if (e.key === ' ' || e.key === 'Enter') {
e.preventDefault();
toggle();
}
}}
aria-label="Включить уведомления"
className={toggle-button ${on ? 'on' : 'off'}}
// CSS должен обеспечить видимый фокус и хороший контраст

Уведомления );
}

CSS-заметки:

Цвет текста: использовать контраст >= 4.5:1 для обычного текста (WCAG AA), либо >= 3:1 для большого текста.Добавить focus-visible (outline/box-shadow) для кнопки, чтобы при навигации с клавиатуры фокус был очевиден.Сделать целевую область не менее ~44x44 CSS-пикселей (удобно для сенсорного ввода и моторных нарушений).

Альтернатива: использовать input[type="checkbox"] скрытый визуально и label, это обеспечивает нативную семантику и клавиатурное поведение «из коробки».

3) Советы по исправлениям (сводно)

Используйте семантические элементы (button, input, a), а не div/span + role, если возможно.Если используете ARIA, соблюдайте спецификацию: корректные роли, aria-checked, aria-expanded и т.п. и синхронизируйте значения.Реализуйте полную клавиатурную навигацию: tabindex, обработчики клавиш (Enter/Space/Escape), логичную последовательность фокуса и видимые индикаторы фокуса.Обеспечьте достаточный цветовой контраст и не используйте только цвет для передачи информации (добавляйте текст, иконки, паттерны).Да, проверяйте фокус-ловушки в модальных окнах, aria-live для динамического контента.Всегда добавляйте понятные метки для форм: или aria-label/aria-labelledby.

4) Автоматические инструменты для проверки (рекомендуется использовать их в CI и локально)

axe-core / axe DevTools (браузерное расширение, библиотека для CI) — очень полезно для веба.eslint-plugin-jsx-a11y — линтер для React/JSX.Lighthouse (в Chrome DevTools и в CI) — показывает базовые A11y-проблемы.Accessibility Insights (Microsoft) — инспекция + fast checks.WAVE (web accessibility evaluation tool) — визуальная диагностика.pa11y / pa11y-ci — командная строка для автоматических проверок.jest-axe — для unit-тестов доступности.Контрастные проверщики: Contrast Checker, встроенный в devtools, плагин Stark для Figma/IDE.

5) Ручное тестирование (обязательно; автоматические инструменты не поймут всё)

Клавиатурная навигация:
Переключение с Tab/Shift+Tab, взаимодействие с Enter/Space, проверка Esc для закрытия модалей.Убедиться, что порядок фокуса логичен, нет «потерянных» элементов.Видимый индикатор фокуса присутствует.Скринридеры:
Windows: NVDA (бесплатно) + браузер Firefox/Chrome. JAWS — коммерческий.macOS: VoiceOver.Протестировать: корректность озвучивания меток, ролей, значений aria-*, правильность чтения заголовков/порядка.Масштабирование и увеличение:
Увеличение страницы до 200% (WCAG тест) — элементы должны оставаться доступными и не ломать верстку.Цветовые нарушения:
Использовать симуляторы дальтонизма, проверить, не зависит ли информация только от цвета.Сенсорные и моторные:
Проверить размеры интерактивных зон, отсутствие мелких целей, время на ввод (если есть ограничения по времени — предоставить опции).Лайв-демонстрации динамики:
Проверить aria-live, уведомления, смену контента: скринридер пользователя должен получать обновления.Тестирование с реальными пользователями (наиболее ценно):
Провести сеансы с людьми, использующими ассистивные технологии.

6) Как оценивать доступность для разных типов нарушений

Полная слепота (используют скринридер):
Показатели: корректные роли, aria-label/aria-labelledby, семантические теги (header/main/nav/form/legend), логичное DOM-порядок, aria-live для динамики.Тесты: NVDA/VoiceOver чтение страницы, управление формами и компонентами, логика заголовков.Слабовидящие пользователи / люди пользующиеся экранным увеличением:
Показатели: масштабируемость (200%), отзывчивая верстка, отсутствие фиксированных размеров, контраст >= 4.5:1 для текста.Тесты: масштабирование, тесты с высоким контрастом/тематикой ОС.Цветовая слепота:
Показатели: информация не только по цвету (добавить текст/иконки/паттерны), контраст между элементами и фоном.Тесты: симуляторы дальтонизма, отключение цветов.Моторные нарушения (ограниченная мобильность):
Показатели: крупные зоны нажатия, возможность навигации с клавиатуры, поддержка альтернативных способов ввода, больше времени для операций.Тесты: попытки взаимодействовать только клавиатурой, проверка размеров touch targets.Нарушения когнитивные:
Показатели: простая и предсказуемая навигация, короткие инструкции, явные ошибки и подсказки, стабильно понятные лейблы.Тесты: читаемость, упрощение текста, проверка понятности ошибок и подсказок.

7) Критерии приемки (примерно)

WCAG 2.1 уровень AA: контраст ≥ 4.5:1 для обычного текста, все интерактивные элементы доступны с клавиатуры, формы имеют метки, динамические изменения озвучиваются/анонсируются.Нет критических ошибок, помеченных axe как "violation".Прохождение ручного тестирования с клавиатурой и скринридером (ключевые сценарии: регистрация/вход/формы/модальные окна/основной поток).

8) Интеграция в процесс разработки

Линтинг (eslint-plugin-jsx-a11y).Unit/E2E тесты на доступность (jest-axe, cypress-axe).Автоматический отчет в CI (axe/pa11y/Lighthouse CI) — предотвратить регрессии.Регулярный ручной аудит перед релизом и тесты с реальными пользователями с инвалидностью.

Короткая контрольная карта (checklist) для интерфейса:

Семантика: теги и роли используются корректно.Метки: все поля и интерактивные элементы имеют понятные подписи.Клавиатура: все функции доступны с клавиатуры; видимый фокус.Контраст: текст и UI соответствуют порогам WCAG.Динамика: aria-live и уведомления работают корректно.Формы: ошибки доступны и объяснены.Модали/диалоги: фокус захватывается и возвращается после закрытия.Тестирование: запущены автоматические проверки и выполнены ручные тесты со скринридером.

Если хотите, могу:

Привести исправленный пример с input[type=checkbox] и полной стилизацией + CSS (фон, размеры, focus-visible).Показать примеры конфигурации axe/pa11y в CI или пример теста с jest-axe.Подготовить чек-лист для ручного тестирования в виде файла (PDF/MD).

Какая из этих доработок полезнее вам сейчас?