Доступность как конверсия: что из WCAG 2.2 реально влияет на продажи

Отчёт WebAIM Million ежегодно фиксирует одну и ту же цифру: около 96% главных страниц миллиона популярных сайтов содержат автоматически обнаруживаемые нарушения WCAG. На средней странице больше 50 ошибок. При этом британское исследование Click-Away Pound оценивает потери ритейла от ухода пользователей с ограничениями в 17 миллиардов фунтов в год.

В России тема доступности звучит в основном через ГОСТ Р 52872 и требования к госсайтам. Для коммерческого бизнеса аргумент другой: критические нарушения доступности — это дефекты, которые мешают всем. Поэтому в методологии UX-аудита проверка по WCAG идёт как измеримый слой, а не как отдельный «социальный» блок.

Уровни WCAG и почему аудит берёт только A

WCAG 2.2 делит критерии на три уровня. A: минимум, без которого интерфейс непригоден для части пользователей. AA: целевой уровень для большинства законодательств. AAA: расширенный, редко достижимый целиком.

Для коммерческого аудита разумный контур: критические и серьёзные нарушения уровня A по классификации axe-core. Они однозначны, автоматически проверяемы и почти всегда совпадают с проблемами для обычных пользователей. Критерии AA, особенно контраст 4.5:1, часто конфликтуют с брендбуком и требуют ручного суждения: серый текст на светлом фоне может быть намеренной иерархией, а не ошибкой. Поэтому контраст AA остаётся за скобками приоритетного аудита, а в отчёте о нём говорят отдельно и без севирити high.

Пять критериев, которые стоят денег

1. 1
   Подписи полей (1.3.1, 4.1.2).Поле без связанного label невидимо для экранного диктора и непонятно для всех после ввода: плейсхолдер исчез, и что здесь было, неизвестно. Прямая связь с ошибками микрокопии.
2. 2
   Имя кнопки (4.1.2).Иконка-корзина без aria-label: «кнопка» для диктора и загадка для новичка. В сгенерированном коде это самая частая ошибка: разбор в статье о вайбкодинге.
3. 3
   Видимый фокус (2.4.7).outline: none ради «чистоты», и пользователь клавиатуры, планшета с клавиатурой или просто человек, заполняющий форму через Tab, теряет позицию. Формы без фокуса заполняют дольше и бросают чаще.
4. 4
   Размер цели (2.5.8).Минимум 24×24 CSS-px. Ниже промахи на смартфоне у всех, не только у людей с тремором. Детали в разборе тач-таргетов.
5. 5
   Альтернативный текст (1.1.1).Картинка товара без alt: потеря для диктора, для поиска по картинкам и для пользователя с отключёнными изображениями в метро.

Что даёт axe-core и чего не даёт

axe-core — это открытый движок Deque, который работает в Chrome DevTools, Lighthouse и Playwright. Он проверяет DOM снятой страницы по нескольким десяткам правил и классифицирует нарушения по четырём уровням серьёзности. Для аудита берут critical и serious: отсутствующие подписи, пустые кнопки и ссылки, дубли id, недоступные модалки.

Автоматика покрывает, по оценке самой Deque, 30–40% критериев WCAG. Остальное требует суждения: логичен ли порядок фокуса, понятно ли сообщение об ошибке, не потеряется ли человек в модальном окне. Поэтому результат axe — это вход для эксперта, а не итоговый вердикт.

Как не превратить доступность в шум

Первый прогон axe по типичному сайту даёт сотни строк. Если вывалить их в отчёт как есть, команда закроет его и не вернётся. Три правила, чтобы этого не произошло:

• Группировать по компоненту, не по странице.Шапка без имён кнопок на 40 страницах — это одна задача для одного разработчика, а не 40 находок.
• Ранжировать по пути к цели.Поле без подписи в форме заказа важнее, чем alt у иллюстрации в блоге. Серьёзность определяется тем, где стоит элемент.
• Проверять исправление.Доступность ломается каждым релизом: новый компонент из библиотеки, новый баннер без alt. Без повторной проверки список устаревает за неделю, об этом статья о регрессиях интерфейса.

Аргумент для бизнеса в одном абзаце

Доступность уровня A не про долю пользователей с инвалидностью в вашей воронке. Это про то, что интерфейс работает предсказуемо на любом устройстве, при любом способе ввода и при плохой связи. Каждый из пяти критериев выше повторяется в обычных UX-исследованиях как причина брошенных форм. Большинство из них исправляют за часы работы фронтенд-разработчика, без редизайна.