Аудит доступности сайта по WCAG 2.1 AA: проверка и отчёт

Типичная ситуация: после запуска сайта выясняется, что 20% пользователей не могут оформить заказ из-за отсутствия alt-текстов и неправильной фокусировки. Или приходит предписание от регулятора — обеспечить доступность по WCAG 2.1 AA. Мы проводим аудит доступности сайта: автоматизированное и ручное тестирование, детальный отчёт и план устранения нарушений.

WCAG 2.1 AA — международный стандарт, обязательный для госсайтов в ЕС (EN 301 549) и США (Section 508). Уровень AA включает 50+ критериев, охватывающих воспринимаемость, управляемость, понятность и надёжность. Наш опыт показывает: ручное тестирование выявляет в 2 раза больше проблем, чем автоматические инструменты, поэтому мы используем оба подхода.

Зачем нужен аудит WCAG 2.1 AA?

Юридические требования — не единственная причина. Доступный сайт охватывает аудиторию с ограниченными возможностями (около 15% населения). Это улучшает SEO: поисковики учитывают семантику page structure и alt-тексты. Кроме того, это доказательство compliance при проверках.

Какие проблемы мы решаем?

• Недостаточная контрастность текста (SC 1.4.3) — серый текст на белом фоне часто ниже 4.5:1. Ошибка типична для кнопок и подсказок.
• Отсутствие alt у изображений — особенно на страницах продуктов, где screen reader не может передать визуальную информацию.
• Кастомные UI-компоненты (селекты, слайдеры) без поддержки клавиатуры и ARIA-атрибутов. Например, datepicker без ARIA label или неправильного role.
• Формы с placeholder вместо label — screen reader не идентифицирует поля, а текст исчезает при вводе.
• Порядок фокуса (Focus Order) не соответствует визуальному потоку — пользователь теряется при табуляции.

Вот реальный кейс: на лендинге финтех-стартапа кастомный выпадающий список не выводил опции при клике, если используются клавиши. Наш аудит показал отсутствие aria-expanded и обработчиков keydown. Исправление заняло 2 часа, но до этого 30% пользователей с моторными нарушениями не могли выбрать тариф.

Инструментарий аудита

Автоматические инструменты (находят ~30% проблем):

// axe DevTools — расширение Chrome/Firefox
// Запустить на каждой странице: F12 → Accessibility

// axe-core через Playwright
npm install -D @axe-core/playwright

// audit.spec.ts
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

const pagesToAudit = [
    '/', '/about', '/contact', '/login', '/dashboard'
];

for (const path of pagesToAudit) {
    test(`${path} has no WCAG 2.1 AA violations`, async ({ page }) => {
        await page.goto(`https://staging.example.com${path}`);

        const results = await new AxeBuilder({ page })
            .withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
            .analyze();

        expect(results.violations).toEqual([]);
    });
}

# WAVE
https://wave.webaim.org/

# Pa11y
pa11y --standard WCAG2AA https://example.com --reporter html > report.html

# Lighthouse
lighthouse https://example.com --only-categories=accessibility --output html

Ручное тестирование (60-70% проблем):

• Навигация только с клавиатуры — пройти весь user flow
• Проверка с NVDA + Chrome / JAWS + IE / VoiceOver + Safari
• Тест с увеличением 200% и 400% (SC 1.4.10 Reflow)
• Тест в режиме высокого контраста Windows
• Отключить CSS — структура должна оставаться осмысленной

Почему ручное тестирование незаменимо?

Автоматика находит синтаксические ошибки: отсутствие alt, низкую контрастность, пропущенные roles. Но она не способна оценить, насколько осмыслен порядок табуляции или корректно ли объявляются динамические изменения. Например, при открытии модального окна screen reader должен услышать его заголовок, а после закрытия — вернуться к исходному элементу. Это проверяется только вручную.

Сравнение автоматического и ручного тестирования

Комбинация обоих подходов даёт максимальную полноту. Ручное тестирование выявляет в 2 раза больше проблем, чем автоматическое, особенно в сценариях с динамическим контентом.

Что входит в аудит?

• Полный отчёт с перечнем нарушений по каждому критерию WCAG 2.1 AA
• Приоритизация (Critical, Major, Minor) с пояснением влияния
• Скриншоты и HTML-пути к проблемным элементам
• Рекомендации по исправлению с примерами кода
• План устранения с оценкой трудозатрат
• Консультация по итогам (1 час онлайн)

Типичные находки на российских сайтах

• Отсутствие lang атрибута на HTML-элементе
• Плохая контрастность серого текста на белом фоне
• Кастомные селекты и дропдауны без keyboard support
• Формы с placeholder вместо label
• Слайдеры и карусели без кнопок управления
• Отключённый zoom (maximum-scale=1)

Как быстро можно устранить нарушения?

Сроки зависят от объёма и сложности. Простые исправления (добавление alt, исправление контраста) выполняются за день. Глубокая переработка компонентов с переписыванием ARIA-атрибутов может занять несколько недель. Мы предоставляем план с пошаговыми рекомендациями и можем взять реализацию на себя.

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

Наши инженеры имеют 5+ лет опыта в accessibility. Закажите аудит доступности вашего сайта — оценим масштаб работ за 1 день и подготовим коммерческое предложение. Также получите консультацию по приоритетности исправлений.

Доступность сайтов: 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 или на почту — ответим в течение часа.