5 проверок доступности, которые стоит выполнить перед релизом

Перед релизом выполните пять проверок в таком порядке: пройдите по всему интерфейсу клавишей Tab, запустите автоматическое сканирование, проверьте семантику HTML и подписи (labels), проверьте цветовой контраст и протестируйте интерфейс при масштабе 200%.

Каждый, кто когда-либо выпускал модальное окно, которое тихо «запирало» пользователей клавиатуры, а затем узнавал об этом спустя недели из багрепорта, понимает, зачем нужен такой список. Это как раз то, что никто не заметит, держа руку на мыши.

Вместе эти проверки занимают несколько минут и отлавливают самые распространённые нарушения доступности. Не нужна ни специальная экспертиза, ни дорогие инструменты, ни недели изучения материалов. Это предрелизный чеклист по доступности, который можно применять к каждому pull request; он быстрый и честно признаёт собственные ограничения. Он не сделает ваше приложение полностью соответствующим WCAG 2.2 (действующий стандарт, опубликованный как W3C Recommendation в октябре 2023 года и принятый как ISO/IEC 40500:2025), но устранит те нарушения, которые сильнее всего мешают реальным пользователям. Сделать немного — существенно лучше, чем не сделать ничего.

1. Пройдите по всему интерфейсу с клавиатуры

Самый быстрый настоящий тест бесплатен и занимает меньше минуты: уберите мышь, пройдите по странице клавишей Tab и убедитесь, что вы видите фокус, можете добраться до всех интерактивных элементов и выйти из любого модального окна, не оказавшись в ловушке. Следите за четырьмя вещами: видимый индикатор фокуса на каждом элементе, логичный порядок обхода, доступность каждой кнопки/ссылки/поля ввода и отсутствие ловушек фокуса в выпадающих списках и диалогах.

Большинство проблем с клавиатурой вызывают две ошибки. Первая — кастомные элементы управления, у которых скрыли нативный outline, чтобы перестилизовать его. Если вы так сделали, верните видимый стиль :focus (или :focus-visible):

.custom-checkbox input:focus-visible + .box {
  outline: 2px solid #2563eb;
  outline-offset: 2px;
}

Вторая — кликабельный <div>. Замените его на <button>, который по умолчанию получает фокус и бесплатно даёт активацию по Enter/Space и роль кнопки. У <div> ничего из этого нет:

// Not reachable by keyboard
<div onClick={handleClick}>Save</div>
// Focusable and operable by default
<button onClick={handleClick}>Save</button>

Ваш ручной проход по Tab проверяет тот сценарий, который вы сами и спроектировали. Session replay реальных сессий вскрывает те проблемы с клавиатурой и фокусом, которые проявляются только «в бою»: пользователь попадает табом в модальное окно и не может из него выйти, или фокус после закрытия диалога улетает в начало документа, и пользователь клавиатуры теряется. Replay показывает, где реальное поведение фокуса расходится с тем, что одобрил ваш сканер.

2. Запустите автоматическое сканирование (Lighthouse + axe DevTools)

Сканер найдёт от трети до 40% проблем доступности на странице, поэтому зелёная оценка означает, что вы закрыли простые пункты (отсутствующий alt-текст, поля без подписей, низкий контраст, отсутствующий атрибут lang) — и не более. Именно такой диапазон обычно приводят поставщики инструментов тестирования, и это скорее нижняя, а не верхняя граница: исследование Deque 2021 года утверждает, что если считать количество найденных проблем, а не долю охваченных критериев успеха, то покрытие автоматических проверок приближается к 57%. Так или иначе, найденные таким образом проблемы дешевле всего исправить.

Запустите сканирование из панели Lighthouse в Chrome DevTools: откройте DevTools, выберите панель Lighthouse, отметьте Accessibility и сгенерируйте отчёт. Прогон только по доступности завершается быстро. Аудит доступности в Lighthouse построен на открытом наборе правил axe-core от Deque, но использует лишь его часть, поэтому добавьте расширение axe DevTools, которое прогоняет полный набор правил и занимается исключительно доступностью. Сначала исправляйте проблемы уровня Critical и Serious.

3. Проверьте семантику HTML и подписи

Скринридеры передают структуру через семантику, поэтому используйте элемент, соответствующий задаче: <button> для действий, <a href> для навигации, <ul>/<li> для списков, <nav> и <main> для ориентиров (landmarks), а заголовки — по порядку (h1 → h2 → h3, без пропуска уровней). Когда всё вокруг — <div>, скринридер объявляет «group, group, group», и страница теряет форму.

Каждому полю ввода нужен связанный с ним <label>; кнопкам только с иконкой нужен aria-label, чтобы они не объявлялись просто как «button»:

<label htmlFor="email">Email</label>
<input id="email" type="email" />

<button aria-label="Copy to clipboard" onClick={copy}>
  <ClipboardIcon />
</button>

Типичный сбой в продакшене: отполированная сторонняя библиотека компонентов поставляет недоступную разметку — например, аккордеон или combobox, у которого <input> не имеет <label>, поэтому скринридер не объявляет ничего. Красивый компонент — не гарантия. Проинспектируйте DOM, который рендерит библиотека, и убедитесь, что подписи действительно на месте.

4. Проверьте цветовой контраст и не полагайтесь только на цвет

Для уровня AA текст должен иметь коэффициент контрастности не менее 4.5:1 для обычного текста и 3:1 для крупного текста (18pt/24px или 14pt/18.66px полужирным) согласно WCAG Success Criterion 1.4.3. Считайте оба значения жёсткими минимумами. Округление вверх до них не допускается, поэтому измеренные 4.499:1 — это провал. Элементы интерфейса и значимые иконки попадают под отдельное, более низкое требование — 3:1 относительно соседних цветов (SC 1.4.11 Non-Text Contrast), а значит, проходящий проверку цвет текста не гарантирует, что ваши кнопки и границы полей форм тоже проходят.

Lighthouse отмечает многие нарушения контраста текста; WebAIM Contrast Checker подтверждает точные значения. Конкретно: #999999 на белом — это 2.85:1 и не проходит; #595959 на белом — это 7:1 и проходит.

Контраст — не вся история. Никогда не обозначайте ошибку одним лишь цветом. Красная рамка невидима для многих пользователей с нарушениями цветовосприятия, поэтому дополните её иконкой и текстом, чтобы смысл сохранялся и без цвета. Добавьте рядом с полем сообщение «⚠ Email is required», а не только красную обводку.

5. Увеличьте масштаб до 200% и учитывайте reduced motion

При 200% масштабирования в браузере ничто не должно перекрываться, обрезаться или вызывать горизонтальную прокрутку. Удерживайте Ctrl/Cmd и нажимайте +, пока масштаб не достигнет 200%, затем пощёлкайте по интерфейсу: обычные виновники — контейнеры фиксированной ширины и размеры в пикселях. Размеры в rem и overflow-wrap сохраняют «текучесть» вёрстки:

.container { max-width: 60rem; padding: 1rem; }
p { overflow-wrap: break-word; }

Далее — учитывайте prefers-reduced-motion: оберните необязательную анимацию в media-запрос, чтобы пользователи, попросившие ОС уменьшить движение, не страдали от неё. Эта настройка просит убрать движение, существующее для декорации, а не вырезать вообще всю анимацию, поэтому оставьте работать всё, что несёт смысл (индикатор загрузки, индикатор прогресса).

@media (prefers-reduced-motion: reduce) {
  /* Target the decorative motion, not every animation on the page.
     Loading spinners and other essential feedback should keep moving. */
  .parallax,
  .carousel-autoplay,
  .hero-animation {
    animation: none;
    transition: none;
  }
}

Бонус, 60 секунд: включите скринридер и послушайте. На macOS нажмите Cmd + F5 для VoiceOver; на Windows установите бесплатный NVDA. Пройдите табом и убедитесь, что заголовки, подписи и поля объявляются осмысленно.

Выпускайте — а затем копайте глубже

Эти пять проверок — минимум, а не максимум. Они не затрагивают сложные ARIA-паттерны, управление фокусом в одностраничных приложениях и доступные таблицы данных — всё это реальная работа для другого раза. Возьмите следующую фичу, прогоните пять проверок перед тем, как открыть PR, и исправьте найденные Critical-проблемы. Когда будете готовы идти дальше, WCAG 2.2, WebAIM и документация по доступности на MDN — основные источники, достойные вашего времени. Доступность — это направление, в котором вы движетесь, и выполнение этих пяти проверок продвигает вас туда уже сегодня.

Часто задаваемые вопросы

Какой коэффициент контрастности нужен для доступности?

Для WCAG 2.2 уровня AA обычный текст должен иметь коэффициент контрастности не менее 4.5:1 относительно фона, а крупный текст (18pt/24px или 14pt/18.66px полужирным) — не менее 3:1, согласно Success Criterion 1.4.3. Элементы интерфейса и значимые иконки подпадают под отдельный критерий 1.4.11, требующий 3:1 относительно соседних цветов. Ни одно из этих значений нельзя получить округлением вверх, поэтому измеренные 4.499:1 не проходят.

Находят ли автоматические инструменты доступности всё?

Нет. Lighthouse и axe выявляют от трети до 40 процентов проблем доступности, в основном простые пункты: отсутствующий alt-текст, поля без подписей, низкий контраст и отсутствующий атрибут lang. Они не могут оценить, осмыслен ли alt-текст, логичен ли порядок обхода табом и управляется ли фокус после взаимодействия. Зелёная оценка Lighthouse закрывает дешёвые исправления, но не всю страницу, поэтому дополняйте каждое сканирование тестированием с клавиатуры и со скринридером.

В чём разница между Lighthouse и axe DevTools?

Аудит доступности в Lighthouse построен на наборе правил axe-core от Deque, хотя использует лишь его часть, и идёт рядом с аудитами производительности, SEO и лучших практик — всё из панели Lighthouse в Chrome DevTools. Браузерное расширение axe DevTools прогоняет полный набор правил axe-core и сосредоточено исключительно на доступности. Запускайте Lighthouse для быстрой проверки, а затем используйте axe DevTools для более глубокого покрытия только по доступности.

Какой версии WCAG следовать в 2026 году?

Следуйте WCAG 2.2 — действующему стандарту. Он получил статус W3C Recommendation в октябре 2023 года, был обновлён в декабре 2024 года и теперь также существует как ISO/IEC 40500:2025, идентичный версии от октября 2023 года. WCAG 3.0 существует лишь как Working Draft, который W3C периодически пересматривает; статус Candidate Recommendation прогнозируется на конец 2027 года, а финальная Recommendation не ожидается раньше 2028 года. Сегодня WCAG 3.0 ничего не регулирует.