Mocha и Chai

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

npm install axe-core --save-dev

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

const axeCore = require('axe-core');
const { expect } = require('chai');

Для интеграции с браузерными тестами можно использовать axe-core через WebDriver или Puppeteer, вставляя скрипт в контекст страницы и выполняя проверку доступности.

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

Базовая инициализация axe-core происходит через вызов функции run, принимающей DOM-элемент или весь документ и объект конфигурации:

axeCore.run(document, {
  runOnly: {
    type: 'tag',
    values: ['wcag2a', 'wcag2aa']
  },
  rules: {
    'color-contrast': { enabled: true },
    'label': { enabled: true }
  }
}, (err, results) => {
  if (err) throw err;
  console.log(results);
});

Ключевые моменты конфигурации:

  • runOnly — фильтрация проверок по тегам или правилам.
  • rules — включение или отключение отдельных правил доступности.
  • include и exclude — позволяет ограничивать область проверки определёнными селекторами.

Интеграция с Mocha

Для автоматизации тестов доступности используется Mocha как фреймворк тестирования. Тесты строятся по стандартной структуре describe/it. Пример базового теста:

describe('Проверка доступности страницы', function() {
  it('не содержит критических ошибок доступности', function(done) {
    axeCore.run(document, {}, (err, results) => {
      if (err) return done(err);

      const violations = results.violations;
      expect(violations).to.be.an('array').that.is.empty;
      done();
    });
  });
});

Особенности:

  • Используется асинхронный подход через done или async/await.
  • Результаты axe-core содержат массив violations, где каждая ошибка описана с точки зрения влияния на доступность, локатора элемента и рекомендации по исправлению.
  • Проверка через expect(violations).to.be.empty позволяет мгновенно выявить критические проблемы.

Использование Chai для расширенной валидации

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

axeCore.run(document, {}, (err, results) => {
  if (err) throw err;

  const criticalIssues = results.violations.filter(v => v.impact === 'critical');
  expect(criticalIssues).to.have.lengthOf(0);
});

Также можно проверять конкретные правила:

const labelIssues = results.violations.filter(v => v.id === 'label');
expect(labelIssues).to.be.empty;

Таким образом формируется точная автоматизация доступности по корпоративным стандартам.

Интеграция с браузерным контекстом

При тестировании компонентов в реальном браузере (например, через Puppeteer или Selenium WebDriver) axe-core можно внедрять динамически:

await page.addScriptTag({ path: require.resolve('axe-core') });
const results = await page.evaluate(async () => {
  return await axe.run(document, { runOnly: ['wcag2aa'] });
});
expect(results.violations).to.be.empty;

Особенности работы в браузере:

  • Скрипт axe-core вставляется непосредственно в страницу.
  • Возможность проверки отдельных элементов через селекторы, например: axe.run(document.querySelector('#form')).
  • Поддержка асинхронных SPA-приложений с динамическим DOM.

Обработка результатов

Результаты axe-core структурированы и содержат несколько ключевых полей:

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

Пример форматированного вывода для логов:

results.violations.forEach(v => {
  console.log(`Правило: ${v.id}`);
  console.log(`Описание: ${v.description}`);
  console.log(`Элементы:`);
  v.nodes.forEach(node => console.log(node.target.join(', ')));
});

Настройка CI/CD

Для интеграции в конвейер непрерывной интеграции axe-core можно запускать вместе с тестами Mocha:

"scripts": {
  "test:accessibility": "mocha test/accessibility/**/*.spec.js"
}
  • В GitHub Actions или GitLab CI можно добавить шаг, который запускает тесты доступности.
  • При нарушениях expect вызывает падение теста, что предотвращает публикацию недоступного контента.

Практические рекомендации

  • Выбирать набор тегов wcag2a, wcag2aa, wcag2aaa в зависимости от требований проекта.
  • Регулярно обновлять правила axe-core, так как стандарты доступности изменяются.
  • Для динамических интерфейсов выполнять проверку после полной загрузки контента.
  • Локализовать отчёты ошибок для команды разработки через форматирование JSON или HTML.

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

Оглавление