Настройка автоматического тестирования доступности через Pa11y

Резин проблем доступности? Автоматизируйте аудит с Pa11y

Вы потратили недели на вёрстку, а клиент на скринридере не видит кнопку «Купить». Или хуже — получили претензию от Роскомнадзора за несоответствие WCAG 2.1. Ручная проверка 500 страниц — это дни работы QA. Pa11y решает проблему: запускается в CLI, читает sitemap.xml и выдаёт отчёт по всем страницам за один проход. Мы используем Pa11y в CI/CD более 5 лет на 50+ проектах — делимся опытом. Автоматизация проверки доступности веб-сайта с Pa11y сокращает время аудита на 70%, а стоимость обслуживания снижается за счёт раннего обнаружения багов. Оцените экономию: на проекте с 2000 страниц мы сократили аудит с 3 дней до 2 часов и нашли 47 критических ошибок, которые пропустили QA.

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

Без автоматики вы пропустите 30–50% нарушений. Pa11y проверяет цветовой контраст, alt-тексты, ARIA-атрибуты, навигацию с клавиатуры. Мы настраиваем его так, чтобы он не пропускал критические ошибки, но игнорировал ложные срабатывания (например, контраст на заблокированных элементах). Типичные проблемы: отсутствие alt у изображений, неправильные ARIA-роли, низкий контраст текста. Автоматизация доступности (a11y testing) снижает затраты на аудит и ускоряет релизы.

Как интегрировать Pa11y в CI/CD?

Процесс настройки занимает 1–2 дня и включает пять шагов:

1. Анализ — собираем URL из sitemap.xml, определяем стандарт (обычно WCAG 2.1 AA).
2. Конфигурация — создаём .pa11yci.json с нужными параметрами и исключениями.
3. Интеграция — добавляем команду pa11y-ci в ваш пайплайн (GitLab CI, GitHub Actions, Jenkins).
4. Тестирование — запускаем пробный аудит, корректируем ложные срабатывания.
5. Документация — описываем процесс работы для команды.

Анализ и конфигурация

Процесс начинается с анализа вашего сайта: собираем список URL из sitemap.xml, шотов. Определяем стандарт (обычно WCAG2AA), таймауты, исключения. На выходе — .pa11yci.json:

// .pa11yci.json { "defaults": { "standard": "WCAG2AA", "timeout": 30000, "wait": 1000, "ignore": [ "WCAG2AA.Principle1.Guideline1_4.1_4_3.G18.Fail" ], "chromeLaunchConfig": { "args": ["--no-sandbox", "--disable-setuid-sandbox"] } }, "urls": [ "https://example.com", "https://example.com/about", "https://example.com/contact", { "url": "https://example.com/login", "actions": [ "wait for element #login-form to be visible" ] } ] } 

Интеграция в пайплайн

Добавляем шаг в CI: на GitLab — pa11y-ci --config .pa11yci.json --threshold 5, на GitHub Actions — аналогично. Параметр --threshold задаёт допустимое количество ошибок. Строгий режим (--threshold 0) означает, что пайплайн упадёт при любой ошибке.

Чтение из sitemap.xml

pa11y-ci --sitemap https://example.com/sitemap.xml \ --sitemap-find "https://example.com" \ --sitemap-replace "http://localhost:3000" \ --threshold 0 

Как игнорировать ложные срабатывания?

Pa11y иногда ругается на контраст для disabled-элементов или на ARIA-роли, заданные фреймворком. Мы добавляем ignore-список в конфиг — это правка под ваш UI-кит. Например:

"ignore": [ "WCAG2AA.Principle1.Guideline1_4.1_4_3.G18.Fail", "WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.InputSearch.Name" ] 

Это устраняет до 90% ложных срабатываний без потери критических проверок.

Сравнение Pa11y и axe-core

Pa11y выигрывает, когда нужно прогнать весь сайт. Axe предпочтительнее в unit-тестах. Мы комбинируем: Pa11y для ночных аудитов, axe в пре-коммит хуках. Это даёт полное покрытие без дублирования.

Пример отчёта Node.js API

// scripts/a11y-audit.js const pa11y = require('pa11y'); const fs = require('fs'); const PAGES = [ { url: 'http://localhost:3000', name: 'Главная' }, { url: 'http://localhost:3000/catalog', name: 'Каталог' }, { url: 'http://localhost:3000/checkout', name: 'Оформление заказа' }, ]; async function audit() { const results = []; for (const page of PAGES) { console.log(`Checking: ${page.name}`); const result = await pa11y(page.url, { standard: 'WCAG2AA', timeout: 20000, actions: page.actions || [], }); results.push({ name: page.name, url: page.url, issues: result.issues.length, critical: result.issues.filter(i => i.type === 'error').length, warnings: result.issues.filter(i => i.type === 'warning').length, violations: result.issues, }); } fs.writeFileSync('a11y-report.json', JSON.stringify(results, null, 2)); console.table(results.map(r => ({ Страница: r.name, Ошибки: r.critical, Предупреждения: r.warnings, }))); if (results.some(r => r.critical > 0)) { process.exit(1); } } audit(); 

Что вы получаете?

После настройки Pa11y вы получаете:

• Рабочий конфигурационный файл .pa11yci.json с настройками под ваш проект.
• Интеграцию в CI/CD — автоматический запуск аудита при каждом пуше.
• Кастомный игнор-лист для ложных срабатываний.
• Документацию по интерпретации отчётов и исправлению типичных ошибок.
• Обучение команды: как читать отчёты Pa11y и фиксить баги доступности.

Этапы настройки Pa11y

Сроки и стоимость

Базовая настройка занимает 1–2 дня. Расширенная с кастомными правилами, скриншотами и обучением — до 5 дней. Стоимость рассчитывается индивидуально под объём сайта. Окупаемость настройки — менее 3 месяцев. Оценим проект за 1 час — свяжитесь с нами.

Pa11y запускает headless-браузер (Chrome), загружает каждую страницу и проверяет её на соответствие выбранному стандарту WCAG. Результаты группируются по типу ошибок: error (критические), warning (замечания), notice (информационные). Это позволяет быстро выявить проблемные места и приоритезировать правки.

Как начать?

Свяжитесь с нами для консультации. Закажите аудит доступности, и если после нашего аудита вы получите штраф за нарушение WCAG — перепроверим бесплатно. Вложения в автоматизацию окупаются уже через 2–3 месяца. Получите вашу конфигурацию Pa11y и избавьтесь от ручных проверок навсегда.