Как выбрать правильный подход к тестированию доступности для автоматизации тестирования

Выбор правильного инструмента тестирования доступности может способствовать успеху или краху вашей стратегии автоматизации. Этот сравнительный анализ между axe-core и IBM Equal Access помогает командам разработчиков сопоставить ключевые различия в точности, гибкости, отчетности и интеграции в рабочий процесс, чтобы найти наиболее подходящий вариант для масштабируемого автоматизированного тестирования доступности.

В нашей предыдущей статье «Внедрение доступности в качество с помощью автоматизации тестирования» мы продемонстрировали практические способы добавления проверок доступности в существующую автоматизацию тестирования для быстрого достижения результатов. Эта продолженная статья делает следующий шаг: сравнивает механизмы сканирования доступности, чтобы помочь командам разработчиков выбрать инструмент, который лучше всего соответствует их потребностям.

Эта публикация посвящена исключительно сравнительному анализу axe-core и IBM Equal Access Accessibility Checker. Мы выбрали эти два инструмента, поскольку оба могут интегрироваться непосредственно в существующие рабочие процессы сквозной (E2E) автоматизации тестирования, особенно с использованием таких инструментов, как Playwright и Cypress. Это важно, так как позволяет командам запускать проверки доступности не только для URL-адреса страницы, но и для приложения в определенном состоянии после того, как тест уже выполнил определенные действия пользователя. На практике это означает, что вы можете сканировать интерфейс после открытия модального окна, развертывания аккордеона, заполнения шага формы или навигации по рабочему процессу — именно там, где всплывает множество проблем с доступностью.

Существуют и другие надежные инструменты тестирования доступности, заслуживающие внимания, включая QualWeb или Pa11y. Однако они не являются предметом данного сравнения, поскольку реже соответствуют рассматриваемому здесь сценарию использования: встраиванию проверок доступности в существующий набор E2E-тестов. Pa11y позиционируется в первую очередь как инструмент командной строки и Node.js для тестирования страниц по отдельности, в то время как QualWeb обычно используется через собственный процесс автоматизации, а не в качестве легковесного сканера внутри теста. Это не значит, что эти инструменты хуже. Это просто означает, что они менее естественно подходят для ситуации, когда целью является запуск проверок доступности в рамках того же тестового процесса и для того же состояния страницы, которым уже управляют Playwright или Cypress.

С учетом этих рамок в данной статье сравниваются axe-core и IBM Equal Access по критериям, которые наиболее важны на практике:

• Философия обнаружения и баланс между строгостью и ложноположительными результатами
• Настраиваемость, включая выбор правил и определение области видимости
• Интеграция в существующие рабочие процессы автоматизации тестирования
• Отчетность, триаж и работа с унаследованными проблемами
• Типы команд и проектов, для которых каждый инструмент подходит лучше всего

Краткий обзорі: Какой инструмент подходит лучше всего?

Хотя эта статья подробная, если вы предпочитаете краткую версию этого анализа, она представлена в таблице ниже:

Хорошо подходит для целенаправленного сканирования определенных областей DOM или компонентов

Поддержка и экосистема

Лучший выбор

Тем не менее, если вы цените наши усилия и более комплексный анализ, в оставшейся части статьи подробно объясняется каждое из этих различий.

Обзор axe-core и IBM Equal Access

axe-core — один из наиболее широко используемых движков для тестирования доступности. Он лежит в основе многочисленных коммерческих инструментов, расширений браузера и CI-интеграций. Его набор правил тесно связан с требованиями WCAG и ARIA, и он широко считается стабильным, зрелым и относительно консервативным в отношении снижения числа ложноположительных результатов.

Одно из его главных достоинств — настраиваемость: команды могут ограничивать сканирование определенными компонентами, включать или исключать отдельные правила и адаптировать движок под существующую стратегию тестирования. Для Playwright интеграция axe-core задокументирована в официальном руководстве по доступности (открывается в новой вкладке). Для Cypress доступна документация по использованию cypress-axe (открывается в новой вкладке). Кроме того, Cypress Accessibility — премиум-плагин — предлагает расширенную интеграцию axe-core в пользовательском интерфейсе Cypress, хотя для него требуется платная лицензия. Помимо самого сканирующего движка, Deque также предоставляет axe для дизайнеров в Figma, что помогает командам выявлять распространенные проблемы доступности и улучшать передачу от дизайна к разработке на более ранних этапах процесса.

IBM Equal Access — это движок тестирования доступности от IBM для обеспечения соблюдения требований WCAG в сочетании с внутренними стандартами доступности IBM. По сравнению с axe-core, он склонен выявлять более широкий спектр проблем, поскольку в некоторых областях применяет более строгие трактовки. Хотя он менее гибкий в повседневной настройке, он обеспечивает надежную отчетность и последовательное соблюдение требований. Правила можно отключать, но уровни сбоев оказываются более жесткими после настройки.

Важным преимуществом IBM Equal Access является поддержка базовых линий (baselines), что особенно полезно для унаследованных приложений. Базовая линия позволяет командам различать существующие и вновь появившиеся проблемы, поэтому будущие сканирования фокусируются на регрессиях и изменениях, а не на многократном всплывании уже известного отставания. Это может сделать внедрение более практичным в крупных или долгосрочных проектах, где исправление всех исторических проблем сразу зачастую нереалистично.

Аналогичным образом IBM также предоставляет набор IBM Accessibility Design Kit для Figma и Sketch, который помогает командам внедрять рекомендации по доступности на этапе проектирования и обеспечивает более плавный переход к реализации.

Сравнение возможностей настройки и контроля

Гибкость против строгости: axe-core делает упор на гибкость, позволяя командам адаптировать движок под свои конкретные потребности в тестировании. IBM Equal Access использует более бескомпромиссный подход, применяя более строгие настройки по умолчанию и предоставляя меньше возможностей для переопределения.

Включение и исключение правил: axe-core поддерживает выборочное включение и исключение правил, а конфигурация передается непосредственно в такие функции, как analyze() или checkA11y(). Это позволяет легко адаптировать проверки к различным контекстам в рамках одного набора тестов. IBM Equal Access позволяет отключать правила, но не поддерживает выборочное включение или разные наборы правил для конкретных компонентов. Конфигурация обычно обрабатывается централизованно через файлы вроде .achecker.yml или aceconfig.js в корне проекта.

Область видимости на уровне компонентов: axe-core предоставляет специальный и хорошо задокументированный механизм определения области видимости с помощью селекторов include и exclude, позволяя тестам нацеливаться на конкретные области DOM или компоненты. Это делает его особенно хорошо подходящим для компонентного тестирования, дизайн-систем и изолированных сценариев пользовательского интерфейса. IBM Equal Access не предлагает эквивалентного API высокого уровня для определения области видимости. Его публичный метод getCompliance() оценивает переданный ему узел DOM, поэтому технически он может анализировать определенное поддерево при передаче узла, отличного от document. Однако это поведение не представлено как официальная функция области видимости, а интеграции с Cypress и Playwright не предоставляют сопоставимых параметров области видимости. На практике это делает ограничение области видимости возможным лишь более ручным, низкоуровневым способом, в то время как axe-core предоставляет более полноценно поддерживаемый рабочий процесс.

Уровни сбоев: IBM Equal Access вводит уровни сбоев, которые классифицируют проблемы по степени серьезности и обеспечивают более жесткое встроенное соблюдение требований после настройки. axe-core не навязывает эту модель напрямую, оставляя обработку степени серьезности окружающему тестовому фреймворку или CI-пайплайну.

Различия в обнаружении — и почему это важно

С точки зрения философии обнаружения, axe-core придерживается относительно консервативной стратегии, стремясь сократить количество ложных срабатываний и сделать результаты автоматизации более простыми для использования. IBM Equal Access в некоторых областях применяет более строгие интерпретации, что позволяет выявить более широкий спектр проблем, но также может потребовать больше человеческого участия при их первичной оценке.

Оба движка обнаруживают множество одинаковых базовых проблем доступности, включая структурные проблемы, такие как неправильное использование ARIA, проблемы с метками и нарушения контрастности цветов. IBM Equal Access часто добавляет предупреждения или рекомендации, которые выходят за рамки строго устранимых сбоев, выделяя области, которые могут заслуживать более пристального внимания с точки зрения доступности.

Если говорить о ложных срабатываниях и опыте разработчиков, то консервативный подход axe-core может облегчить внедрение для команд разработки, особенно когда проверки доступности впервые внедряются в существующие конвейеры. IBM Equal Access может потребовать больше ручной проверки из-за своих более строгих и иногда более широких результатов, но этот компромисс может быть ценен для команд, которым требуется более жесткое соблюдение правил и которые готовы более внимательно изучать результаты.

Обслуживание, сообщества и управление

axe-core извлекает выгоду из крупного открытого сообщества, частых обновлений и широкого распространения в экосистеме доступности и тестирования. Такая зрелость облегчает поиск примеров, сторонних интеграций и знаний сообщества, когда у команд возникают вопросы по реализации. IBM Equal Access поддерживается компанией IBM и регулярно обновляется в соответствии с внутренними стандартами и инициативами IBM в области доступности. Хотя его публичное сообщество меньше, чем у axe-core, он предлагает модель, более ориентированную на корпоративный сектор, с сильным управлением и долгосрочной стабильностью.

Интеграции в экосистему

У axe-core в целом более широкая экосистема, включающая интеграции с Cypress, Playwright, Jest, Storybook, расширениями браузера и многими коммерческими инструментами. У IBM Equal Access более узкая, но все же практичная история интеграций для сценариев использования, рассматриваемых в этой статье, особенно благодаря поддержке Cypress и пакету npm для рабочих процессов на базе Playwright.

И наконец, что же выбрать?

И axe-core, и IBM Equal Access являются мощными движками тестирования доступности, но они оптимизированы под несколько разные приоритеты. axe-core лучше подходит для команд, которые ценят гибкость, точное определение границ и тесную интеграцию в существующие рабочие процессы автоматизации тестирования. Он особенно хорошо подходит для команд, которые хотят адаптировать проверки доступности к различным контекстам и сохранять контроль над тем, как результаты применяются в CI. IBM Equal Access лучше подходит для команд, которые предпочитают более строгие настройки по умолчанию, более жесткое встроенное соблюдение требований и поддержку работы с устаревшими приложениями с помощью базовых линий. Для него может потребоваться больше ручного контроля, но этот компромисс может быть оправдан в средах, где более широкое обнаружение и структурированное управление важнее максимальной гибкости.

Для некоторых команд наилучшим подходом может стать даже использование обоих движков в качестве дополняющих друг друга: axe-core для целенаправленной, гибкой интеграции в автоматизированные рабочие процессы и IBM Equal Access для более строгого контроля и более широкого обзора.

Для некоторых команд наилучшим подходом может стать даже использование обоих движков в качестве дополняющих друг друга: axe-core для целенаправленной, гибкой интеграции в автоматизированные рабочие процессы и IBM Equal Access для более строгого контроля и более широкого обзора.

Правильный выбор в конечном итоге зависит не столько от того, какой движок «лучше» в абсолютном выражении, сколько от того, какой из них лучше всего соответствует тому, как ваша команда создает, тестирует и поддерживает программное обеспечение.

Правильный выбор в конечном итоге зависит не столько от того, какой движок «лучше» в абсолютном выражении, сколько от того, какой из них лучше всего соответствует тому, как ваша команда создает, тестирует и поддерживает программное обеспечение.