Автоматизация соответствия WCAG 2.1 AA

Updated Jul 2026

Стандарт

Руководство по обеспечению доступности веб-контента (WCAG) 2.1 на уровне соответствия AA — это стандарт, на который ссылается большинство законов. Он определяет критерии успеха по четырём принципам (Воспринимаемость, Управляемость, Понятность, Надёжность), которые делают веб-контент доступным для людей с ограниченными возможностями.

Автоматизация проверок соответствия выявляет примерно 30-40% проблем доступности — остальные требуют ручного тестирования и экспертной оценки. Эти 30-40% включают наиболее распространённые нарушения: отсутствующий alt-текст, недостаточный цветовой контраст, отсутствующие метки форм и нарушенную иерархию заголовков. Автоматическое выявление этих проблем при каждом PR — минимально необходимая практика обеспечения доступности.

Что можно автоматизировать, а что нельзя

Можно автоматизировать	Требует экспертной оценки
Отсутствующий alt-текст на изображениях	Является ли alt-текст осмысленным
Коэффициенты цветового контраста	Используется ли цвет для передачи смысла
Отсутствующие метки форм	Является ли текст метки понятным
Отсутствующие роли ARIA	Являются ли роли ARIA корректными
Фокусируемость с клавиатуры	Является ли порядок фокуса логичным
Иерархия заголовков (h1-h6)	Описывают ли заголовки контент
Наличие атрибута lang	Корректен ли язык для контента
Наличие текста ссылок	Является ли «нажмите здесь» достаточно описательным
Дублирование ID	Являются ли ссылки на ID семантически корректными
Наличие заголовков таблиц	Структурированы ли таблицы данных логично

Соотношение 30/70

Автоматизированные инструменты отвечают на вопросы «присутствует ли?». Люди (или AI-агенты) должны отвечать на вопросы «корректно ли?».

Automated: "Does this image have an alt attribute?"  -> Yes/No
Human:     "Does the alt text accurately describe the image for
            someone who cannot see it?"                -> Judgment required

Automated: "Is the color contrast ratio >= 4.5:1?"   -> Yes/No
Human:     "Is color the ONLY way this information
            is communicated?"                          -> Judgment required

Automated: "Does this form input have a <label>?"    -> Yes/No
Human:     "Does the label clearly explain what
            the user should enter?"                    -> Judgment required

Обзор критериев успеха WCAG 2.1 AA

Принцип	Ключевые критерии	Автоматизируемо?	Частые нарушения
Воспринимаемость	1.1.1 Нетекстовый контент	Частично	Отсутствующий alt-текст
	1.3.1 Информация и взаимосвязи	Частично	Отсутствующие заголовки, плохая структура таблиц
	1.4.3 Контраст (минимум)	Да	Текст ниже соотношения 4.5:1
	1.4.11 Контраст нетекстовых элементов	Частично	UI-компоненты ниже соотношения 3:1
Управляемость	2.1.1 Клавиатура	Частично	Нефокусируемые интерактивные элементы
	2.4.3 Порядок фокуса	Нет	Нелогичная последовательность tab
	2.4.4 Назначение ссылки	Нет	Ссылки «Нажмите здесь»
	2.4.7 Видимый фокус	Частично	Отсутствующие индикаторы фокуса
Понятность	3.1.1 Язык страницы	Да	Отсутствующий атрибут lang
	3.2.1 При фокусе	Нет	Неожиданные изменения контекста
	3.3.2 Метки или инструкции	Частично	Отсутствующие метки форм
Надёжность	4.1.1 Парсинг	Да	Дублирование ID, невалидный HTML
	4.1.2 Имя, роль, значение	Частично	Отсутствующие атрибуты ARIA

Построение стратегии тестирования доступности

Уровень 1: автоматическое сканирование (каждый PR)

Запускайте axe-core или аналогичные инструменты на каждой странице при каждом PR. Это выявляет 30-40% проблем, обнаруживаемых сканированием на основе правил.

# Minimum viable accessibility CI
npx playwright test tests/accessibility/ --reporter=json > a11y-results.json

Уровень 2: AI-аудит (еженедельно)

Используйте AI-агентов для оценки качественных аспектов — качества alt-текста, потока чтения, ясности сообщений об ошибках. Это выявляет дополнительные 20-30% проблем.

Уровень 3: ручной экспертный аудит (ежеквартально)

Эксперт по доступности использует экранные чтецы, навигацию только клавиатурой и инструменты увеличения для поиска оставшихся проблем. Это незаменимо для сложных взаимодействий, когнитивной доступности и соответствия WCAG AAA.

Уровень 4: пользовательское тестирование (раз в полгода)

Тестирование с реальными пользователями с ограниченными возможностями. Они находят проблемы, которые ни один инструмент или эксперт не предвидел.

Быстрые победы: наиболее частые нарушения WCAG

Эти пять нарушений составляют большинство проблем доступности, обнаруживаемых автоматическим сканированием:

Отсутствующий alt-текст (WCAG 1.1.1) -- каждое значимое изображение нуждается в описательном alt-тексте
Недостаточный цветовой контраст (WCAG 1.4.3) -- текст должен иметь контраст 4.5:1 относительно фона
Отсутствующие метки форм (WCAG 1.3.1) -- каждый input нуждается в связанном <label>
Пустые ссылки (WCAG 2.4.4) -- ссылки должны иметь различимый текст
Отсутствующий язык документа (WCAG 3.1.1) -- <html lang="en"> должен присутствовать

Исправление этих пяти проблем устраняет большинство автоматически обнаруживаемых нарушений доступности. Они просты в исправлении и легко тестируемы.

<!-- Fix #1: Add alt text -->
<img src="product.jpg" alt="Blue running shoes, size 10">

<!-- Fix #2: Use sufficient contrast -->
<style>
    /* BAD: #999 on white = 2.85:1 ratio */
    .label { color: #999; }
    /* GOOD: #595959 on white = 7:1 ratio */
    .label { color: #595959; }
</style>

<!-- Fix #3: Associate labels with inputs -->
<label for="email">Email address</label>
<input id="email" type="email" name="email">

<!-- Fix #4: Give links meaningful text -->
<!-- BAD -->
<a href="/products">Click here</a>
<!-- GOOD -->
<a href="/products">View all products</a>

<!-- Fix #5: Set document language -->
<html lang="en">

Эти исправления занимают минуты каждое и оказывают непропорционально большое влияние на оценки соответствия доступности и реальный пользовательский опыт.

Интеграция проверок соответствия в ваш рабочий процесс

Pre-commit: линтинг HTML на доступность

До того как код попадёт в CI, линтуйте HTML-шаблоны на типичные нарушения:

# Using axe-linter or htmlhint with accessibility rules
npx htmlhint --rules "alt-require,title-require" src/**/*.html

CI: автоматическое сканирование страниц

Запускайте axe-core на каждой странице вашего приложения в CI. Блокируйте сборку при критических и серьёзных нарушениях, предупреждайте при умеренных.

// tests/accessibility/scan-all-pages.spec.ts
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

const pages = [
    '/',
    '/products',
    '/cart',
    '/checkout',
    '/account',
    '/help',
];

for (const pagePath of pages) {
    test(`a11y scan: ${pagePath}`, async ({ page }) => {
        await page.goto(pagePath);
        const results = await new AxeBuilder({ page })
            .withTags(['wcag2a', 'wcag2aa'])
            .analyze();

        // Fail on critical and serious
        const blocking = results.violations.filter(
            v => v.impact === 'critical' || v.impact === 'serious'
        );
        expect(blocking).toEqual([]);
    });
}

Пост-релиз: мониторинг

После развёртывания запускайте периодические сканирования доступности на продакшене для выявления регрессий, внесённых изменениями контента, обновлениями CMS или инъекциями сторонних скриптов, обходящих CI.

Маппинг WCAG на типы тестов

Критерий WCAG	Тип теста	Инструмент
1.1.1 Нетекстовый контент	Автоматический + AI-ревью	axe-core + AI-агент
1.4.3 Контраст	Полностью автоматический	axe-core
2.1.1 Клавиатура	Полуавтоматический	Тесты клавиатуры Playwright
2.4.7 Видимый фокус	Полуавтоматический	Визуальная регрессия состояний фокуса
3.3.1 Идентификация ошибок	Ручной + AI	AI-агент + ревью человеком
4.1.2 Имя, роль, значение	Автоматический	Проверки ARIA axe-core

Этот маппинг помогает командам решить, куда инвестировать усилия в автоматизацию, а где экспертная оценка человека незаменима.