Pa11y и axe для тестирования доступности

Pa11y и axe-core — это инструменты с открытым исходным кодом, автоматизирующие проверку доступности в соответствии с WCAG. Оба разбирают страницу, применяют правила к DOM и сообщают о нарушениях. Автоматически выявляйте основную часть проблем доступности, а для остальных используйте ручное тестирование.

axe-core — это библиотека JavaScript, которая обеспечивает аудиты доступности в Chrome DevTools, Lighthouse, Jest, Cypress, Playwright и многих других инструментах. Это фактический стандарт автоматического тестирования доступности: широкий охват правил и низкая доля ложных срабатываний.

Расширение браузера axe DevTools (Chrome, Firefox, Edge) добавляет в DevTools вкладку «Доступность». Нажмите «Сканировать все страницы», и оно выведет каждое нарушение с затронутыми элементами, уровнем серьёзности и инструкциями по исправлению. Лучше всего подходит для разовых аудитов во время разработки.

Pa11y — это интерфейс командной строки Node.js: npx pa11y https://example.com проверяет URL. Результатом становится список проблем в терминале. Используйте его для быстрых аудитов, в сценариях оболочки или для простой интеграции с CI.

Сочетайте axe-core с Playwright для сквозного тестирования доступности: const results = await new AxeBuilder({ page }).analyze(). Проверьте, что results.violations.length === 0. Это позволяет выявлять регрессии до того, как они попадут в рабочую среду.

jest-axe запускает axe для отрендеренных компонентов в тестах Jest. Отрендерите компонент с помощью React Testing Library и передайте контейнер в axe: expect(await axe(container)).toHaveNoViolations(). Теперь каждый тест компонента включает проверку доступности.

Оба инструмента позволяют отключать или изменять правила для конкретного проекта: отключайте правила, противоречащие намеренным проектным решениям, и повышайте строгость для заведомо критичных правил. Документируйте каждое отключённое правило комментарием с объяснением причины — это контекст, необходимый будущим разработчикам.

Автоматические инструменты выявляют примерно 30–40% проблем WCAG. Для остальных (содержательный порядок фокуса, понятный альтернативный текст, семантическая иерархия заголовков, использование ARIA, отражающее фактическое поведение интерфейса) требуется проверка человеком. Автоматизация необходима, но сама по себе недостаточна для обеспечения доступности.

Проверяйте продукт с помощью NVDA в Windows, VoiceOver на Mac и JAWS для корпоративной аудитории. Тестирование с настоящими экранными дикторами выявляет проблемы, недоступные автоматизации: непонятные объявления, неработающие ориентиры и нелогичный порядок фокуса. Разумным исходным уровнем будет один раз за выпуск проверить продукт с каждым основным SR.

Самая ценная проверка доступности — это использование реального продукта людьми с инвалидностью. Ищите участников через консультантов по доступности, университетские службы поддержки студентов с инвалидностью или платформы тестирования, такие как UserTesting.com. Их отзывы из реальной жизни выявляют проблемы, которые не обнаруживает ни один автоматический инструмент.

Блокируйте PR при регрессиях доступности (новых нарушениях), но не при устаревших нарушениях (уже существующих в исходном уровне). Это позволяет постепенно повышать планку, не препятствуя выпуску. Отслеживайте общее число нарушений во времени как опережающий показатель общего состояния доступности.

Используйте несколько инструментов: axe для комплексной автоматической проверки, Pa11y как дополнительное независимое мнение, а ручное тестирование с экранным диктором — для качественной проверки. Пересечение их возможностей невелико; вместе они выявляют больше проблем, чем любой отдельный инструмент.

Какой процент проблем доступности WCAG можно надёжно выявить с помощью автоматических инструментов, таких как axe и Pa11y?

axe-core обеспечивает работу большинства аудитов доступности; расширение браузера отлично подходит для разовых проверок, а интеграции jest-axe и Playwright — для непрерывного тестирования. Pa11y — дополнительный интерфейс командной строки. Автоматизация выявляет примерно 30–40% проблем; для полного охвата сочетайте её с ручным тестированием экранными дикторами (NVDA, VoiceOver) и тестированием с реальными пользователями с инвалидностью. Блокируйте новые регрессии в CI, но не блокируйте процесс из-за нарушений исходного уровня.