Аудит доступности сайта по 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 день и подготовим коммерческое предложение. Также получите консультацию по приоритетности исправлений.