Аудит доступности сайта по WCAG 2.1 AAA — максимальный уровень

Аудит доступности сайта по стандарту WCAG 2.1 (уровень AAA)

Вы замечали, что пользователи со скринридерами не могут заполнить форму на вашем сайте? Или пожилые клиенты жалуются на мелкий текст с низким контрастом? Это типичные проблемы, которые решает аудит доступности по уровню AAA. Мы знаем, как выявить такие точки отказа и дать конкретные исправления.

Мы провели аудит доступности для 50+ сайтов — от государственных порталов до банковских приложений. Наш опыт показывает: даже некритичные на первый взгляд нарушения приводят к потере до 30% аудитории с ограниченными возможностями.

WCAG 2.1 AAA — наивысший уровень соответствия стандарту веб-доступности. Он включает 28 дополнительных критериев поверх AA. Полное соответствие AAA на всём сайте практически недостижимо и не является целью — W3C прямо указывает это в документе. Используют AAA для критически важных разделов: государственных услуг, медицинских платформ, образовательных сервисов.

Какие дополнительные требования появляются на уровне AAA?

Воспринимаемость:

1.2.6 Sign Language (AAA) — синхронный перевод видео на жестовый язык. 1.2.7 Extended Audio Description (AAA) — расширенное аудиоописание для видео, где паузы недостаточны для описания действия. 1.4.6 Contrast Enhanced (AAA) — минимальный контраст 7:1 для обычного текста, 4.5:1 для крупного:

/* AAA: 7:1 для основного текста */
body {
    color: #1a1a1a;       /* 17.1:1 на белом ✓ */
    background: #ffffff;
}
.text-secondary {
    color: #595959;       /* 7.0:1 на белом — ровно AAA */
}
/* Visual Presentation (1.4.8) — настройки блоков текста */
article {
    max-width: 80ch;
    line-height: 1.5;
}
p + p { margin-top: 1.5em; }
article { text-align: left; }

1.4.9 Images of Text (AAA) — текст не должен отображаться как изображение (кроме логотипов).

Управляемость:

2.1.3 Keyboard (No Exception) (AAA) — абсолютно все функции с клавиатуры, без исключений. AA допускает исключения для рисования и подобного — AAA не допускает ничего. 2.2.3 No Timing (AAA) — никаких временных ограничений вообще. 2.2.6 Timeouts (AAA) — предупреждать пользователя о таймауте за 20+ секунд. 2.3.2 Three Flashes (AAA) — ничего, что мигает чаще 3 раз в секунду. 2.4.8 Location (AAA) — пользователь понимает, где находится в структуре сайта:

<nav aria-label="Breadcrumb">
    <ol>
        <li><a href="/">Главная</a></li>
        <li><a href="/products">Продукты</a></li>
        <li aria-current="page">Смартфоны</li>
    </ol>
</nav>

2.4.9 Link Purpose — Link Only (AAA) — назначение каждой ссылки понятно из её текста без контекста:

<!-- Нарушает AAA -->
<a href="/read-more">Подробнее</a>

<!-- Соответствует AAA -->
<a href="/products/iphone-15">Смартфон iPhone 15 Pro — подробнее</a>

Понятность:

3.1.3 Unusual Words (AAA) — механизм объяснения необычных слов и жаргона:

<abbr title="Единый налог на вменённый доход">ЕНВД</abbr>
<p>Использован метод <a href="/glossary#kpi">KPI</a> оценки.</p>

3.1.4 Abbreviations (AAA) — расшифровка аббревиатур через <abbr>. 3.1.5 Reading Level (AAA) — упрощённая версия контента если уровень выше 9-го класса:

<details>
    <summary>Упрощённое объяснение</summary>
    <p>Говоря простыми словами: ...</p>
</details>

3.2.5 Change on Request (AAA) — ничего не меняется без явного действия пользователя. Никаких автоматических редиректов, автоматических обновлений контента без запроса. 3.3.4 Error Prevention (All) (AAA) — для любых отправок форм: возможность проверить, исправить или отменить.

Когда действительно нужен уровень AAA?

• Государственные порталы и e-government сервисы
• Медицинские информационные системы
• Образовательные платформы (СДПО, дистанционное обучение)
• Финансовые сервисы с пожилой аудиторией
• Любой сервис, где исключение части пользователей недопустимо по закону

Методология AAA-аудита

AAA-аудит включает всё из AA плюс:

1. Видеоконтент — субтитры, аудиодескрипция, жестовый язык (при наличии)
2. Ручное тестирование с пользователями — привлечение людей с различными нарушениями
3. Когнитивная доступность — проверка читаемости текста (Flesch-Kincaid, Fog Index)
4. Тест в режиме монохромного отображения — Windows High Contrast Mode

Что входит в работу

• Детальный отчёт с указанием каждого нарушения WCAG 2.1 AAA и его приоритета
• Дорожная карта исправлений с оценкой трудозатрат по каждому пункту
• Рекомендации по исправлению с готовыми примерами кода (HTML/CSS/JS)
• Повторная проверка (регресс) после внесения изменений
• Консультация с вашими разработчиками по сложным сценариям
• Доступ к нашей базе знаний по веб-доступности

Срок проведения аудита

Наши специалисты сертифицированы и имеют более 7 лет опыта в области веб-доступности. Мы гарантируем качество аудита и предоставляем поддержку на всех этапах исправления. Свяжитесь с нами, чтобы обсудить ваш проект и получить консультацию по объёму работ.

W3C Web Content Accessibility Guidelines 2.1 — https://www.w3.org/TR/WCAG21/

Доступность сайтов: WCAG, скринриндеры, клавиатурная навигация

На сайте крупного банка кнопка «Подать заявку» в разметке была <div class="btn" onclick="...">. Скринридер NVDA её не анонсировал, Tab пропускал, Enter не срабатывал. Для тысяч незрячих пользователей этот банк просто не существовал как онлайн-сервис. Мы видим такие проблемы каждый день в десятках проектов — и разработка доступных сайтов по стандарту WCAG 2.2 AA становится единственным способом избежать дискриминации и юридических рисков. Штрафы за недоступность для юрлиц достигают 300 000 ₽, а судебные иски — миллионы.

В этой карточке — как мы делаем веб-доступность a11y работающей, на реальных кейсах, с конкретным стеком и цифрами. Без общих фраз.

Почему семантическая разметка — основа веб-доступности a11y?

Большинство проблем доступности решается правильным HTML, а не дополнительными ARIA-атрибутами. <button> вместо <div onclick>, <nav> вместо <div class="navigation">, <h1>–<h6> в правильной иерархии, <label for="field-id"> вместо <div class="label">. Это базовый уровень, но на практике каждая вторая форма в российских интернет-магазинах не имеет корректных <label>.

ARIA нужна там, где нативный HTML не справляется: кастомные компоненты — выпадающие меню, тултипы, модальные окна, табы, accordion. И вот тут начинается сложность.

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

• role="combobox" на инпуте
• aria-expanded="true/false" при открытии/закрытии
• aria-controls="listbox-id" указывает на список
• aria-activedescendant — ID текущего выбранного элемента
• role="option" и aria-selected на каждом варианте

Это не теория, это то, что тестируется скринридером. NVDA + Chrome или VoiceOver + Safari — обязательная часть QA.

<div role="combobox" aria-expanded="false" aria-controls="listbox-1" aria-activedescendant="" tabindex="0">
  <label for="input-1">Выберите город</label>
  <input id="input-1" type="text" role="combobox" aria-autocomplete="list" />
  <ul id="listbox-1" role="listbox" aria-label="Города">
    <li role="option" aria-selected="false" id="opt-1">Москва</li>
    <li role="option" aria-selected="false" id="opt-2">Санкт-Петербург</li>
  </ul>
</div>

Стоимость исправления одного нарушения уровня A — от 5 000 до 15 000 ₽ в зависимости от сложности. Внедрение a11y с этапа проектирования сокращает бюджет на рефакторинг в 2–3 раза по сравнению с доработкой готового сайта.

Как правильно построить клавиатурную навигацию?

Tab-порядок должен совпадать с визуальным порядком элементов. Если в HTML кнопка «Отмена» стоит перед «Подтвердить», но CSS их меняет местами — пользователь клавиатуры в замешательстве.

Focus trap в модальных окнах. Когда модалка открывается, Tab должен циклиться только внутри неё. При закрытии — возврат фокуса на элемент, который открыл модалку. Без этого пользователь после закрытия оказывается в начале страницы.

tabindex="-1" — элемент не попадает в Tab-последовательность, но может получить фокус программно. Используется для элементов, которые получают фокус через JavaScript (заголовки секций после навигации по якорям).

tabindex="1" и выше — почти всегда ошибка. Явный порядок ломает естественный и создаёт непредсказуемое поведение. Управляйте порядком через DOM, не через tabindex.

Skip links — ссылка «Перейти к содержимому», скрытая визуально, видимая при Tab. Позволяет пользователям скринридеров пропустить повторяющуюся навигацию.

Цвет и контраст: требования и частые нарушения

WCAG 2.2 AA требует контраст 4.5:1 для обычного текста, 3:1 для крупного (18px+ или 14px+ bold). AAA требует 7:1 и 4.5:1.

Самые частые нарушения: серый placeholder в инпутах (#999 на белом = 2.9:1), светло-серый secondary текст, белый текст на пастельном фоне.

Цвет не должен быть единственным индикатором: «поля обязательные выделены красным» без звёздочки — нарушение для людей с цветовой слепотой.

Инструменты проверки: axe DevTools, WAVE, Accessibility Inspector в Chrome DevTools. axe-core интегрируется в Playwright-тесты: автоматическая проверка на 80+ правил при каждом деплое. Ручное тестирование находит примерно на 60% больше ошибок, чем автоматическое.

Медиаконтент и динамика: что важно?

Изображения без alt — частый базовый провал. alt должен быть смысловым: не alt="image_123.jpg", а описание содержимого, релевантное контексту. Декоративные изображения — alt="" (пустой, не отсутствующий атрибут).

Видео должно иметь субтитры. YouTube автосубтитры — не стандарт, они ошибаются. WebVTT-файлы с корректными субтитрами для всего образовательного и маркетингового видеоконтента.

Анимации — проблема для пользователей с вестибулярными расстройствами. @media (prefers-reduced-motion: reduce) — медиа-запрос, отключающий или замедляющий анимации для пользователей с такой настройкой в ОС.

Что изменилось в WCAG 2.2?

Версия 2.2 вступила в силу с новыми критериями:

Эти критерии повышают порог входа, но мы уже включаем их в стандартный чек-лист.

Аудит и устранение нарушений

Автоматические инструменты находят около 30–40% нарушений. Остальное — только ручное тестирование. Минимальный сценарий: пройти весь критический user flow (регистрация, покупка, форма) только клавиатурой и со скринридером.

Процесс работы

1. Автоматический аудит — axe-core, Lighthouse, WAVE — выдача 80+ правил.
2. Ручное тестирование — NVDA, VoiceOver, клавиатура — 2–3 дня на типовой сайт.
3. Приоритизация нарушений — P1 (блокирует использование), P2 (создаёт сложности), P3 (улучшения).
4. Исправление — итерациями, встраиваем проверки в CI через Playwright + axe.
5. Повторный аудит — закрытие всех P1/P2 перед релизом.
6. Документация и передача — отчёт с результатами, рекомендации по поддержке, обучение команды.

Результаты и объём работ

• Полный отчёт по аудиту с приоритизацией нарушений (PDF/HTML)
• Исправленный код: семантическая разметка, ARIA, клавиатурная навигация
• Интеграция axe-core в CI/CD для регрессионного контроля
• Обучение разработчиков заказчика по работе с a11y (2-часовая сессия)
• Доступ к репозиторию с примерами корректных компонентов
• Гарантия соответствия WCAG 2.2 AA на момент сдачи

Сроки

Бюджет рассчитывается индивидуально после аудита. Свяжитесь с нами — оценим ваш проект за 1 день. Получите консультацию и чек-лист бесплатно при заказе аудита.

Опыт и гарантии

Мы занимаемся веб-доступностью a11y более 8 лет. Реализовали более 50 проектов для банков, ритейла и госсектора. Сертифицированные специалисты (IAAP CPACC, WAS). Гарантируем прохождение аудита третьей стороной или дорабатываем бесплатно.

Стандарт WCAG 2.2 — официальная рекомендация W3C, определяющая требования к доступности веб-контента.

Wikipedia: Web Content Accessibility Guidelines
Wikipedia: ARIA

— уровни веб-доступности a11y по версии 2.2.

Закажите аудит сейчас — получите чек-лист и предварительную оценку бесплатно. Пишите в Telegram или на почту — ответим в течение часа.