Что, почему и как!
Тема доступности, к сожалению, игнорируется в веб-разработке, несмотря на ее важность. Исследование показывает, что для некоторых отраслей до 70% веб-сайтов содержат критически важные блокираторы для слабовидящих пользователей. Это не только разделяет контент в Интернете, но также может привести к потере рынка для компаний, которые пренебрегают потенциальными клиентами, не предоставляя им эквивалентный опыт на своих страницах.
Создание доступного веб-сайта означает предоставление вашего контента каждому пользователю, который получает к нему доступ, независимо от нарушений. Первый и самый важный шаг – эмпатия. Следуя передовым методам, таким как использование семантического HTML и хороших цветовых контрастов, а также гарантируя, путем тестирования, что одинаковый опыт предоставляется всем пользователям, мы можем сделать Интернет более доступной и восприимчивой средой.
Использование библиотек аудита для автоматизированного тестирования доступности может быть весьма полезным на этом пути, чтобы интегрировать эти проверки в процесс разработки. Обычно они не требуют специальных знаний в этой области и позволяют командам изучать и развивать продукт, одновременно решая проблемы доступности.
axe: Тестирование доступности
«Axe был создан, чтобы отразить то, как на самом деле работает веб-разработка. Он работает со всеми современными браузерами, инструментами и средами тестирования, которые может использовать команда разработчиков. С Axe тестирование доступности может выполняться как часть вашего модульного тестирования, интеграционного тестирования, тестирования браузера и любого другого функционального тестирования, которое ваша команда уже выполняет изо дня в день».
Axe by Deque — это ведущий на сегодняшний день инструментарий цифровой доступности; очень мощный и легко интегрируемый в любой тип проекта. Список тестовых наборов и фреймворков, которые имеют готовые интеграции для тестирования доступности библиотеки axe-core, можно найти на этой странице.
Теперь мы собираемся изучить, как мы можем интегрировать тестирование доступности axe-core library в наш процесс разработки, интегрировав его с комплектами для тестирования. strong> через Cypress. Хотя мы не будем охватывать все возможные интеграции, это должно дать хорошее представление о том, как это работает и чего можно достичь, независимо от инструментов тестирования, которые вы используете в своем проекте.
Кипарис + топор
Здесь мы рассмотрим, как установить и использовать axe с Cypress, используя пакет cypress-axe.
Установка
Во-первых, мы должны установить пакет в нашем проекте (учитывая, что у нас уже установлен и настроен Cypress):
npm install axe-core --save-dev npm install cypress-axe --save-dev
Затем все, что нам нужно сделать, это добавить эту строку в файл cypress/support/index.js в нашем проекте (или cypress/support/e2e.jsдля Cypress v10+), чтобы импортировать cypress-axe команды:
import 'cypress-axe';
Использование
Мы все настроили, и теперь мы можем начать использовать его в наших тестах! Первый шаг — внедрить его при посещении url для тестирования, как показано ниже.
beforeEach(() => {
cy.visit('http://localhost:4200/');
cy.injectAxe();
});
Это внедряет среду выполнения Axe Core на страницу, поэтому она доступна во время выполнения наших тестов. Теперь мы просто вызываем команду checkA11y, которая будет запускать проверки оси на нашей странице.
it('should find no detectable a11y violations', () => {
(...)
cy.checkA11y();
});
Команда будет выполняться в текущем состоянии загруженной страницы в axe для нашего текущего теста. В отчете будут показаны элементы, содержащие проблемы с доступностью, если таковые обнаружены и не прошли тест.
Примечание: важно, чтобы мы не запускали команду только один раз, а для изменения состояния на нашей странице. Элементы загружаются динамически, добавляются и удаляются из DOM и т. д., поэтому мы должны запускать команду после внесения изменений, чтобы аудит выполнялся для всех возможных состояний.
Это самая базовая настройка, которую мы получаем из коробки.
Но мы можем настроить запуск тестов со всеми конфигурациями, которые предоставляет нам основная библиотека axe.
Мы можем передать три необязательных параметра в checkA11y(), которые эквивалентны API запуска топора. По предоставленной ссылке вы можете проверить эти параметры и возможные варианты конфигурации.
Ниже приведен пример того, как это можно использовать в своих интересах, например проверять только те проблемы доступности, которые считаются критическими.
it('should find no detectable a11y critical violations', () => {
cy.checkA11y(null, {
includedImpacts: [‘critical’]
});
})
Кроме того, у нас также есть команда под названием configureAxe(), которая позволяет нам настраивать конфигурацию, эквивалентную API конфигурации axe. По предоставленной ссылке вы можете проверить эти параметры и возможные варианты конфигурации.
Ниже приведен пример того, как использовать это в своих интересах, например, указать правила для запуска или обойти правила для определенного контекста.
it('should find no detectable a11y critical violations', () => {
cy.configureAxe({
rules: [{
id: “aria-required-children”,
enabled: false,
}],
});
// Here we would bypass (and make tests pass) when
// "aria-required-children" rule is not respected
cy.checkA11y(null, {
includedImpacts: [‘critical’]
});
})
Расширение Chrome
Axe также предоставляет нам расширение Google Chrome, которое можно использовать непосредственно в браузере. Это может быть очень интересно, так как он может генерировать аудиты практичным и быстрым способом анализа страниц в опубликованных средах.
После установки расширения вы должны найти новую вкладку axe при открытии Dev Tools.
Просто зайдите на страницу для тестирования и нажмите кнопку Анализ, чтобы создать отчет. При выборе отображается описание каждой ошибки, и можно определить, какой элемент на странице имеет указанную проблему, серьезность проблемы и ссылку на более подробное описание проблемы. Отчет будет отображаться в Dev Tools, как показано ниже.
obs: хотя расширение Google Chrome является мощным, практичным и очень полезным, я особенно считаю, что интеграция axe с тестом проекта (как показано с Cypress) необходима, поскольку вы гарантируете, что эти проблемы доступности будут обнаружены во время разработки и, возможно, в CI. .
Доступность, безусловно, является очень важным вопросом, которому сегодня не уделяется должного внимания в мире веб-разработки. Как мы видели, мы можем легко интегрировать аудит доступности в наши проекты, чтобы гарантировать, что мы устраним по крайней мере критические проблемы, чтобы обеспечить более доступную среду для всех людей.
Однако важно отметить, что одних этих тестов недостаточно, и тестирование на реальных пользователях по-прежнему необходимо для обеспечения доступности веб-сайта для всех людей. В конце концов, наша цель состоит в том, чтобы каждый человек мог потреблять контент и перемещаться по нашему веб-сайту, независимо от того, кто этот человек и какие ограничения у него могут быть.
Надеюсь, поможет! 😉
Рекомендации
https://www.deque.com/blog/research-shows-internet-is-unavailable-to-blind-users/
https://www.deque.com/axe/core-documentation/api-documentation/#api-name-axeconfigure
