Четыре типичные ошибки доступности из Lighthouse, которые есть почти на каждом сайте
Аудит доступности через Lighthouse или axe DevTools на типичных сайтах почти неизменно выдаёт одни и те же четыре ошибки — и все они легко исправляются. Разбираем, что именно проверяет каждый критерий и где проблемы прячутся.
Инструменты автоматического аудита ловят лишь часть реальных проблем доступности, но те четыре ошибки, которые они находят на каждом втором сайте — это действительно грубые упущения, которые мешают реальным пользователям.
О чём речь и чего ожидать
Исходная статья опубликована на dev.to с дисклеймером: текст подготовлен при участии ИИ-агента, действующего от имени Джейсона Санчеса, и проверен на соответствие критериям WCAG 2.2. Пройти автоматическую проверку не означает сертификацию по WCAG, ADA или EAA — это важная оговорка, которую стоит запомнить. Автоматика находит грубые нарушения, но не заменяет ручное тестирование с экранным диктором и клавиатурной навигацией.
Тем не менее перечисленные в оригинале четыре критерия действительно составляют «большую четвёрку» самых распространённых провалов. Это не гипотеза — подтвердит любой, кто запускал Lighthouse на лендинге, интернет-магазине или корпоративном сайте.
Как запустить проверку за две минуты
Перед исправлениями нужно получить список конкретных нарушений. Два стандартных подхода:
# Только категория accessibility
npx lighthouse https://example.com --only-categories=accessibility --view
# Альтернатива — axe-core CLI
npx @axe-core/cli https://example.com
Можно и в консоли DevTools — вставить скрипт, который подгружает axe-core с CDN и выводит таблицу нарушений. Но тут есть нюанс: строгая Content-Security-Policy на сайте может заблокировать загрузку стороннего скрипта. Используйте этот подход только на локальных стендах или там, где CSP точно не мешает.
Все идентификаторы правил из вывода можно свести к четырём ниже.
1. color-contrast — недостаточный контраст текста
Это критерий WCAG 1.4.3 уровня AA. Требования простые:
- Обычный текст — минимум 4.5:1 по отношению к фону.
- Крупный текст (от 24px обычного начертания или от ~18.7px жирного) — минимум 3:1.
Типичная ошибка
/* #999 на #fff ≈ 2.8:1 — провал */
.muted { color: #999; }
/* #595959 на #fff ≈ 7:1 — проходит AA и AAA */
.muted { color: #595959; }
Где прячется проблема
Серый текст в футере и мета-данных, белый текст на жёлтых или оранжевых кнопках, текст поверх hero-изображений без затемняющего оверлея, плейсхолдеры в полях ввода, которые пользователи воспринимают как инструкции.
В Chrome DevTools есть встроенный пикер: выбираете элемент, кликаете на цветовой сватч в панели Styles — инструмент покажет текущий коэффициент и линии AA/AAA. Можно тянуть ползунок, пока не добьётесь нужного значения. Доступно прямо из коробки, никаких расширений не нужно.
2. image-alt — изображения без текстовой альтернативы
Критерий WCAG 1.1.1 уровня A. Изображение должно нести описание того, что оно communicates in this context — то есть не формальное «картинка 1», а то, что важно для понимания контента.
Правильные паттерны
<!-- Информативное изображение -->
<img src="team.jpg" alt="Наши три пекаря раскатывают тесто в 5 утра">
<!-- Декоративное — пустой alt, скринридер пропустит -->
<img src="swirl.svg" alt="">
<!-- Ссылка-логотип — описываем назначение -->
<a href="/"><img src="logo.png" alt="Пекарня Роза — на главную"></a>
Практические детали
Не начинайте alt с «Изображение» или «Фото» — скринридер и так объявляет элемент как изображение. Если картинка обёрнута в ссылку, alt описывает назначение ссылки, а не содержимое картинки.
В WordPress alt заполняется в поле «Альтернативный текст» Медиабиблиотеки. В Shopify — в специальном поле при загрузке изображения товара или файла. Пропускать эти поля — значит обречь себя на провал в аудите.
3. link-name / button-name — элементы управления без доступного имени
Критерии WCAG 2.4.4 и 4.1.2 уровня A. Проблема массовая: иконки соцсетей, гамбургер-меню, крестик закрытия, лупа поиска, стрелки каруселей — всё это объявляется скринридеру просто как «ссылка» или «кнопка» без какого-либо пояснения.
Решение
<!-- Иконка Instagram — aria-label на ссылке, aria-hidden на самой иконке -->
<a href="https://instagram.com/rosas" aria-label="Пекарня Роза в Instagram">
<i class="icon-instagram" aria-hidden="true"></i>
</a>
<!-- Гамбургер с состоянием -->
<button type="button" class="menu-toggle"
aria-label="Открыть меню" aria-expanded="false">
<svg aria-hidden="true" focusable="false">…</svg>
</button>
Важный нюанс из WCAG 2.5.3 (Label in Name): если на кнопке есть видимый текст, доступное имя должно содержать этот текст. Это нужно для пользователей голосового управления — они произносят то, что видят на экране, и система должна найти совпадение. Поэтому aria-label не должен противоречить видимой надписи.
4. label — поля формы без лейблов
Критерии WCAG 1.3.1 и 3.3.2 уровня A. Самая коварная ошибка из четырёх, потому что дизайнеры часто считают placeholder достаточным. Это не так: плейсхолдер исчезает при вводе и обычно имеет низкий контраст (что добавляет ещё и провал по color-contrast).
Правильный подход
<!-- Явная связь label с input -->
<label for="email">Электронная почта</label>
<input id="email" type="email" name="email" autocomplete="email">
<!-- Если дизайн не предполагает видимый label — хотя бы aria-label -->
<input type="search" name="q" aria-label="Поиск товаров">
Типичные места утечки
Форма подписки на рассылку в футере, поисковая строка в шапке, поле количества на странице товара, модальные окна обратной связи. Везде, где input стоит один без привязки к label — это нарушение.
Ограничения автоматического аудита
Автоматические инструменты находят только часть проблем. Они не проверят:
- Полноту и точность alt-текстов (пустой alt допустим для декоративных изображений, но инструмент не отличит информативное изображение с плохим описанием от хорошего).
- Логичность порядка заголовков (
heading-order— отдельная тема). - Реальную навигацию с клавиатуры: фокус может «теряться», элементы могут быть недоступны по Tab — это автоматика не увидит.
- Корректность ARIA-атрибутов: неверный
aria-expandedилиaria-roleможет пройти синтаксическую проверку, но дать скринридеру ложную информацию.
После автоматического аудита стоит пройтись по странице Tab-ом, увеличить масштаб до 200% и хотя бы раз запустить VoiceOver или NVDA. Это не замена полноценному тестированию, но уже отсечёт грубейшие ошибки.
Двадцатиминутный план исправлений
Если нужно быстро поднять оценку accessibility в Lighthouse, последовательность такая:
- Запустите проверку, зафиксируйте идентификаторы проваленных правил.
- Исправьте контраст на основном тексте, primary-кнопках и футере.
- Добавьте alt-тексты на информативные изображения,
alt=""на декоративные. - Обеспечьте каждую иконку-контроль доступным именем.
- Привяжите label к полям поиска, рассылки и оформления заказа.
- Перезапустите проверку, затем пролистайте страницу по Tab и увеличьте до 200%.
Все четыре ошибки — это уровень A и AA базового стандарта WCAG. Их исправление не требует переработки архитектуры, не ломает дизайн и, как правило, занимает не больше часа на средний сайт. Факт, что они стабильно всплывают при каждом аудите, говорит не о сложности требований, а о культуре разработки, где доступность до сих пор воспринимается как опциональное улучшение, а не как часть спецификации.