Кратко, по‑существенному — набор практик (HTML/CSS/JS) + автоматические инструменты и как их применять.
1) Семантическая HTML — основа
- Используйте семантические теги: $‘<header>‘,‘<nav>‘,‘<main>‘,‘<aside>‘,‘<footer>‘,‘<h1>‘–‘<h6>‘,‘<button>‘,‘<a>‘$. Это даёт корректное представление для экранных читалок и клавиатурной навигации.
- Старайтесь не заменять элементы с семантикой на ``/``; если вынуждены — явно добавляйте `role` и клавиатурную поддержку.
Примеры:
HTML навигации
```
ГлавнаяО проекте ```
Форма с меткой и сообщением об ошибке
```
EmailМы не передаём ваш email. ```
2) Управление фокусом и клавиатурная доступность
- Все интерактивные элементы должны быть фокусируемыми (``, ``, ``). Не убирать outline без замены видимым стилем фокуса.
- Обеспечьте логичный порядок табуляции (DOM order). Для «кнопок», реализованных через `div`, добавьте `tabindex="0"`, `role="button"` и обработку Enter/Space.
- Модальные окна: при открытии — передать фокус внутрь, при закрытии — вернуть, поместить `aria-modal="true"` и `role="dialog"`, блокировать фокус за пределами модалки (focus trap).
Пример — открытие модалки (упрощённо)
```
modalElem.setAttribute('role','dialog');
modalElem.setAttribute('aria-modal','true');
modalElem.tabIndex = -1;
modalElem.focus(); // передать фокус в модалку
```
3) ARIA — дополняйте, не заменяйте семантику
- Используйте ARIA только там, где семантических HTML‑элементов недостаточно: `aria-label`, `aria-labelledby`, `aria-describedby`, `aria-live`, `role="alert"`/`"status"`.
- Правило: «Неправильная ARIA хуже, чем её отсутствие».
Пример live‑announce
```
/* при изменении текста внутри #status экранные читалки оповестят пользователя */
```
4) Цвета, контраст и масштабируемость
- Соблюдайте контраст текста и фона: расчёт контрастного отношения:
$$\text{CR}=\frac{L_1+0.05}{L_2+0.05}$$ где $L$ — относительная яркость (см. WCAG). Для нормального текста требуется минимум CR $\ge 4.5:1$, для крупного текста — $\ge 3:1$.
- Не используйте только цвет для передачи информации; добавляйте текст/иконки/подписи.
- Текст должен быть масштабируемым (не фиксируйте размер шрифта в px без возможности увеличения) и поддерживать пользовательские настройки.
5) Анимации и «предпочтение уменьшения движения»
- Поддерживайте `@media (prefers-reduced-motion: reduce)` и минимизируйте анимации для таких пользователей.
6) Видимые индикаторы фокуса и жесты
- Не убирать outline: вместо `outline: none` применяйте кастомный, доступный стиль:
```
:focus {
outline: 3px solid #2563eb;
outline-offset: 2px;
}
```
7) Тестирование с использованием вспомогательных технологий
- Проверяйте сайт с экранными читалками (NVDA/VoiceOver), клавиатурой, и на мобильных ридерах. Локально проверяйте доступность таба, порядок фокуса, корректные роли и чтение ошибок.
8) Автоматические проверки и инструменты (рекомендации + интеграция в CI)
- Lighthouse (Chrome DevTools) — быстрый аудит доступности. Можно запускать в CI:
- `lighthouse https://example.com --output=json --only-categories=accessibility`
- axe-core (Deque) — мощная библиотека для автоматических тестов; есть интеграции:
- Для браузера: axe DevTools / axe‑browser extension.
- Для unit/CI: jest-axe / axe-core + Playwright / Puppeteer.
Пример теста с jest-axe:
```
import { axe, toHaveNoViolations } from 'jest-axe';
expect.extend(toHaveNoViolations);
test('page is accessible', async () => {
const html = renderToString();
const results = await axe(html);
expect(results).toHaveNoViolations();
});
```
- eslint-plugin-jsx-a11y — статический анализ для React/JSX (проверяет отсутствие alt, неправильные роли и т.д.).
- pa11y — CLI для автоматической проверки страниц:
- `pa11y https://example.com`
- WAVE / WAVE toolbar — визуальная проверка проблем на странице.
- Accessibility Insights (Microsoft) — автоматические и ручные проверки (FastPass, Assessment).
- color contrast checkers (Contrast Checker, accessible-colors) — проверяют соотношение контрастов.
Интеграция в CI
- Запуск axe/pa11y/lighthouse в pipeline (GitHub Actions, GitLab CI). Любые критические нарушения должны приводить к фейлу сборки.
- Статический анализ (eslint-plugin-jsx-a11y) как шаг pre‑commit/CI.
9) Что автоматические инструменты не покрывают — вручную проверить
- Логика чтения контента, порядок табуляции в сложных интерфейсах, пригодность сообщений об ошибках, удобство работы с экранными читалками, адекватность текстов подсказок, юзабилити для когнитивных нарушений.
Краткий чек‑лист для разработки
- Семантика > ARIA.
- Метки для всех форм и элементов управления.
- Видимый фокус и клавиатурная навигация.
- Контраст ≥ WCAG (4.5:1 для обычного текста).
- Поддержка prefers-reduced-motion.
- Тесты axe/lighthouse + ручное тестирование с читалками.
- Интеграция автоматических сканеров в CI.
Если нужно, могу прислать готовые шаблоны: доступная форма, доступная модалка с focus‑trap или пример конфигурации для CI с axe/pa11y.