Эта статья изначально была опубликована в моем блоге code punnet.
Когда мы создаем приложения, мы хотим убедиться, что они работают. Чтобы убедиться в этом, мы напишем наши обычные модульные, заглушки и интеграционные тесты. Однако одна вещь, которую обычно не тестируют в этих костюмах, — это доступность наших веб-приложений.
На смену приходит axe-core, который был разработан deque systems. Я кратко расскажу, как мы можем легко настроить и использовать axe для наших нужд и как его можно интегрировать в ваш текущий инструментарий, чтобы мы могли начать находить (и исправлять!) дефекты специальных возможностей в наших веб-приложениях СЕГОДНЯ 😃
Что такое топор
Из репозитория axe-core.
Axe – это механизм тестирования доступности для веб-сайтов и других пользовательских интерфейсов на основе HTML. Он быстрый, безопасный, легкий и легко интегрируется с любой существующей тестовой средой, поэтому вы можете автоматизировать тестирование специальных возможностей наряду с обычным функциональным тестированием.
Это означает, что мы можем использовать axe для анализа структуры DOM наших веб-приложений на предмет проблем с доступностью. Это делается с помощью системы, основанной на правилах, позволяющей настроить axe под свои нужды и требования, все правила axe вы можете найти здесь. Эти правила проверяются на соответствие общим рекомендациям и стандартам доступности, таким как WCAG, Раздел 508 и собственный набор правил axe.
Пример простой конфигурации топора ниже.
// axe-config.js
module.exports = {
rules: [
{
id: 'landmark-one-main',
enabled: false
}
]
}
Эта конфигурация может стать намного более сложной с расширенными атрибутами, которые вы можете использовать, такими как селекторы CSS, теги или исключение скрытых элементов, что делает axe-core легко настраиваемым для ваших требований к тестированию.
Эту же конфигурацию можно импортировать в любой из проектов, использующих движок axe-core, что позволит вам стандартизировать и совместно использовать ваши конфигурации для инструментов и приложений.
Как я могу использовать топор для проверки доступности
Теперь, когда мы знаем, что ax может позволить нам тестировать доступность в наших веб-приложениях, как мне его реализовать? Ниже я расскажу о нескольких распространенных способах, которыми вы можете легко внедрить axe в свое тестирование.
Развернутые сайты (axe-cli)
Если ваше приложение уже развернуто и доступно через HTTP/S, это так же просто, как запустить интерфейс командной строки axe для URL-адреса вашего приложения.
npm install -g axe-cli
axe http://your-site.com/page
Это решение лучше всего подходит для простых HTML-страниц без аутентификации или для легкого перехода по URL-адресам. Если вам требуются какие-либо действия пользователя для доступа к нужным страницам для тестирования, просмотрите разделы, посвященные реализации axe в Puppeteer или Selenium.
React (реакт-топор)
Это отличный инструмент, который можно довольно легко включить практически в любое реагирующее приложение. Для этого достаточно всего лишь следующего фрагмента кода, просто убедитесь, что вы загрузили его перед загрузкой основного реагирующего приложения.
var React = require('react'); var ReactDOM = require('react-dom');
if (process.env.NODE_ENV !== 'production') { var axe = require('react-axe'); axe(React, ReactDOM, 1000); }
React Axe теперь может показать вам ошибки a11y и даже дать вам хорошее выделение DOM, где возникает проблема, когда это применимо.
React axe также достаточно умен, чтобы перезагружать и повторно анализировать, когда компоненты в DOM повторно визуализируются, что делает его использование удобным для разработчиков.
Jest (шут-топор)
Теперь, если ваша команда использует что-то вроде jest, интегрировать axe в набор для тестирования так же просто, как в приведенном ниже фрагменте кода.
const { axe, toHaveNoViolations } = require('jest-axe')
expect.extend(toHaveNoViolations)
it('should demonstrate this matcher`s usage', async () => { const render = () => '<img src="#"/>'
// pass anything that outputs html to axe const html = render()
expect(await axe(html)).toHaveNoViolations() })
В этой реализации есть несколько хороших вспомогательных методов, таких как функция toHaveNoViolations
. После того, как вы запустите свои тесты, вы получите правильно отформатированные ошибки следующим образом.
Кукловод (топор-кукольник)
С помощью axe-puppeteer снова легко внедрить axe в ваши существующие тесты, причем axe вводится автоматически для вас, и вам просто нужно вызвать функцию analyze
, когда DOM находится в желаемом состоянии для тестирования.
const { AxePuppeteer } = require('axe-puppeteer') const puppeteer = require('puppeteer')
(async () => { const browser = await puppeteer.launch() const page = await browser.newPage() await page.setBypassCSP(true)
await page.goto('https://dequeuniversity.com/demo/mars/')
const results = await new AxePuppeteer(page).analyze() console.log(results)
await page.close() await browser.close() })()
Одно примечание к этой реализации заключается в том, что вам придется провалить свои тесты, оценив объект результатов в соответствии с вашими требованиями к тестированию, поскольку простая функция не предоставляется, как реализация шутливого топора.
Селен (axe-webdriverjs)
Наконец, если вы используете что-то вроде selenium axe-core, его все равно можно интегрировать в ваши текущие тесты с помощью axe-webdriverjs. Это решение просто подключается к объекту веб-драйвера и запускает анализ визуализированного DOM при вызове функции analyze
.
var AxeBuilder = require('axe-webdriverjs'); var WebDriver = require('selenium-webdriver');
var driver = new WebDriver.Builder() .forBrowser('firefox') .build();
driver .get('https://dequeuniversity.com/demo/mars/') .then(function() { AxeBuilder(driver).analyze(function(err, results) { if (err) { // Handle error somehow } console.log(results); }); });
Как и в случае с кукловодом, вам нужно будет оценить объект результатов для более детального контроля над критериями отказа для анализа топора.
Подведение итогов
Используя axe для тестирования доступности в вашем веб-приложении, вы можете убедиться, что ваши приложения как минимум соответствуют одним из лучших стандартов, когда речь идет о доступности в Интернете. Кроме того, перемещение как можно большего количества простого тестирования доступности, охватываемого axe, в код должно позволить вам быстрее выявлять простые ошибки, экономя время и деньги для пользовательского тестирования в дальнейшем.
Если ваш инструмент или фреймворк не был рассмотрен, обязательно ознакомьтесь с полным списком проектов, использующих движок axe здесь.
Подключайтесь дальше
- Читайте больше статей в блоге Code Punnet.
- Рассмотрите возможность подписки на еженедельную рассылку блогов.
- Следите за новостями в twitter или в блогах RSS feed.