Тестирование после миграции

Axe-core — это мощная библиотека для автоматизированного тестирования доступности веб-приложений. Она реализует проверку интерфейса по стандартам WCAG (Web Content Accessibility Guidelines) и помогает выявлять ошибки, связанные с доступностью элементов для пользователей с ограниченными возможностями.

Библиотека предоставляет API для запуска сканирования DOM и получения подробных отчётов о нарушениях. В JavaScript Axe-core интегрируется через npm-пакет axe-core и может работать как в браузере, так и в средах тестирования на базе Node.js.

Установка и подключение

Для работы с Axe-core необходимо установить пакет через npm:

npm install axe-core

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

import axe from 'axe-core';

или через включение скрипта на страницу:

<script src="node_modules/axe-core/axe.min.js"></script>

После подключения библиотека готова к анализу DOM.

Запуск сканирования DOM

Основной метод для проверки доступности — axe.run. Он принимает два параметра:

  1. target — элемент DOM или селектор, который необходимо проанализировать.
  2. options — конфигурация правил сканирования.

Пример базового запуска:

axe.run(document, {
  runOnly: {
    type: 'tag',
    values: ['wcag2a', 'wcag2aa']
  }
}).then(results => {
  console.log(results.violations);
});

Ключевые моменты:

  • runOnly позволяет ограничить проверку определёнными тегами или уровнями WCAG.
  • results.violations возвращает массив объектов, каждый из которых содержит описание ошибки, элементы DOM, где она обнаружена, и рекомендации по исправлению.

Настройка правил и фильтров

Axe-core поддерживает гибкую настройку правил:

axe.run(document, {
  rules: {
    'color-contrast': { enabled: true },
    'label': { enabled: false }
  }
});
  • Можно включать или отключать отдельные правила.
  • Возможна настройка порогов и параметров для конкретных проверок (например, минимальный контраст текста).

Также существует возможность фильтрации элементов:

axe.run(document.querySelector('#main-content'));

Это позволяет анализировать только определённые блоки страницы, что полезно после миграции, когда часть интерфейса обновлена, а остальная остаётся прежней.

Интеграция с тестовыми фреймворками

Для автоматизированного тестирования Axe-core хорошо интегрируется с Jest, Mocha, Cypress и другими инструментами.

Пример с Jest:

import { configureAxe } from 'jest-axe';
import { render } from '@testing-library/react';
import MyComponent from './MyComponent';

const axe = configureAxe();

test('Компонент соответствует стандартам доступности', async () => {
  const { container } = render(<MyComponent />);
  const results = await axe(container);
  expect(results).toHaveNoViolations();
});
  • jest-axe оборачивает axe-core и интегрирует его с Jest.
  • Метод toHaveNoViolations упрощает проверку: тест падает, если найдены нарушения.

Пример с Cypress:

import 'cypress-axe';

cy.visit('/page');
cy.injectAxe();
cy.checkA11y();
  • injectAxe добавляет библиотеку в контекст теста.
  • checkA11y выполняет проверку доступности и выводит результаты в консоль.

Работа с результатами

Объект results содержит несколько ключевых полей:

  • violations — массив ошибок.
  • passes — массив успешно пройденных правил.
  • incomplete — правила, которые не удалось полностью проверить.
  • inapplicable — правила, которые не применимы к текущему DOM.

Пример структуры violation:

{
  "id": "color-contrast",
  "impact": "serious",
  "description": "Недостаточный контраст текста",
  "nodes": [
    {
      "html": "<span class='text'>Пример</span>",
      "target": ["#main-content .text"],
      "failureSummary": "Контраст текста слишком низкий для WCAG 2.1 AA"
    }
  ]
}
  • impact указывает серьёзность ошибки (minor, moderate, serious, critical).
  • nodes содержит элементы, нарушающие правило.

Использование Axe-core после миграции

После миграции интерфейса важно проверять:

  1. Старые компоненты — чтобы убедиться, что их доступность не нарушена.
  2. Новые компоненты — для выявления проблем, которые могли появиться при интеграции новых библиотек и стилей.

Рекомендовано:

  • Сквозное тестирование ключевых страниц.
  • Проверка динамически подгружаемого контента (модальные окна, вкладки, списки).
  • Автоматизация проверок в CI/CD, чтобы ошибки доступности не попадали в продакшен.

Расширенные возможности

  • Асинхронная проверка: позволяет работать с SPA и контентом, который появляется после загрузки страницы.
  • Пользовательские правила: можно создавать собственные проверки специфичных для проекта элементов.
  • Локализация сообщений: поддержка разных языков для описания ошибок.

Пример добавления пользовательского правила:

axe.registerRule({
  id: 'custom-link-check',
  selector: 'a',
  evaluate(node) {
    return node.getAttribute('href') !== '';
  },
  meta: {
    description: 'Все ссылки должны иметь href',
    impact: 'critical'
  }
});

Советы по оптимизации тестирования

  • Разделять проверки по страницам и компонентам.
  • Использовать селекторы, а не весь документ, для ускорения тестов.
  • Интегрировать проверку в существующие тестовые пайплайны, чтобы поддерживать высокое качество доступности после каждой миграции.

Хотите, я подготовлю примеры комплексного отчёта после тестирования нескольких страниц сразу? Это будет полезно для понимания работы Axe-core на больших проектах.

Оглавление