Разделение проверок

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

Типы проверок и их классификация

Все проверки в Axe-core организованы в виде правил (rules), которые объединены в категории (tags). Каждое правило содержит условия, необходимые для его выполнения, и описание возможного нарушения. Основные теги:

  • wcag2a, wcag2aa, wcag2aaa — соответствие уровням WCAG 2.0/2.1. Позволяет выбирать проверки в зависимости от критичности требований доступности.
  • best-practice — рекомендации по улучшению качества интерфейса, которые не являются обязательными с точки зрения стандартов.
  • experimental — новые или нестабильные проверки, находящиеся в стадии тестирования.

Разделение по тегам позволяет запускать только необходимые группы правил, уменьшая нагрузку на систему и время аудита.

Конфигурация проверок

Для управления набором правил используется объект конфигурации при вызове axe.run(). Примеры ключевых параметров:

  • runOnly — определяет, какие категории проверок будут выполнены. Может быть объектом с массивом тегов или с указанием конкретных правил:
await axe.run(document, {
  runOnly: {
    type: 'tag',
    values: ['wcag2aa', 'best-practice']
  }
});
  • rules — позволяет включать или отключать отдельные правила независимо от категории:
await axe.run(document, {
  rules: {
    'color-contrast': { enabled: false },
    'image-alt': { enabled: true }
  }
});

Использование rules особенно полезно для игнорирования ложноположительных срабатываний или специфичных условий проекта.

Селективное выполнение проверок

Axe-core поддерживает выполнение проверок не на всей странице, а на выбранных элементах DOM. Это достигается передачей селектора или элемента в axe.run():

const section = document.querySelector('#main-content');
const results = await axe.run(section, {
  runOnly: { type: 'tag', values: ['wcag2aa'] }
});

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

Настройка игнорируемых элементов

В сложных интерфейсах некоторые элементы не должны проверяться (например, декоративные изображения или сторонние виджеты). Для этого используется параметр exclude:

await axe.run(document, {
  exclude: [['#ads', '.decorative-icons']]
});

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

Разделение отчетов по категориям

После выполнения проверки результаты можно фильтровать и группировать по тегам. Структура объекта results.violations содержит подробную информацию о каждом нарушении:

  • id — уникальный идентификатор правила.
  • impact — критичность (critical, serious, moderate, minor).
  • tags — категории проверки.
  • nodes — список элементов, на которых обнаружено нарушение.

Пример фильтрации критичных нарушений уровня WCAG 2.1 AA:

const criticalAA = results.violations.filter(v => 
  v.impact === 'critical' && v.tags.includes('wcag2aa')
);

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

Интеграция с CI/CD

Разделение проверок облегчает автоматизацию тестирования в пайплайнах CI/CD. Использование селективных правил снижает время выполнения тестов и минимизирует ложные срабатывания. Типичный подход:

  1. Nightly build — запуск полного набора правил для проверки всей страницы.
  2. Pull request — запуск только критичных WCAG-2.1 AA проверок для измененных компонентов.
  3. Release build — включение всех best-practice и experimental проверок для окончательного аудита.

Такое разделение позволяет балансировать скорость, точность и полноту проверки.

Расширение и кастомизация правил

Axe-core предоставляет возможность добавления пользовательских правил. Новые правила могут быть привязаны к существующим тегам или иметь собственные. Формат пользовательского правила включает:

  • id — уникальный идентификатор.
  • description — описание проверки.
  • tags — категории для фильтрации.
  • evaluate — функция, выполняющая проверку на элементах DOM.

Пример пользовательской проверки:

axe.configure({
  rules: [
    {
      id: 'custom-heading-order',
      description: 'Проверка правильного порядка заголовков',
      tags: ['wcag2aa', 'best-practice'],
      evaluate: function(node) {
        // логика проверки заголовков
      }
    }
  ]
});

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

Разделение проверок в Axe-core обеспечивает гибкость, управляемость и масштабируемость тестирования доступности. Комбинация фильтрации по тегам, выборочных элементов и настройки индивидуальных правил делает библиотеку мощным инструментом для интеграции в любые процессы разработки.

Оглавление