Wiki · Технологии разработки

axe-core

4 мин чтенияАвтор: Дмитрий КолесниковСоавторы: Евгений Баев

axe-core – это открытая библиотека на JavaScript, которая автоматически проверяет страницу на соответствие правилам доступности WCAG: контраст текста, alt у картинок, подписи полей формы, названия кнопок. Её развивает компания Deque Systems, код распространяется по лицензии MPL 2.0.

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

Что axe-core проверяет на странице

Библиотека разбирает готовую страницу в браузере и прогоняет набор правил. Правила привязаны к WCAG 2.0, 2.1 и 2.2 на уровнях A, AA и AAA, плюс отдельные рекомендации Deque. Чаще всего на коммерческих сайтах всплывает вот что:

Серый текст на светлом фоне. По WCAG для уровня AA обычному тексту нужен контраст не ниже 4,5:1, крупному не ниже 3:1.
Картинки без атрибута alt, особенно товары и баннеры со ссылками.
Поля формы без подписи: вместо label только серый текст внутри поля, который исчезает при вводе.
Кнопки-иконки без названия: «корзина», «лупа», «крестик» для диктора звучат как просто «кнопка».
У страницы не указан язык, и диктор читает русский текст английским произношением.

Deque заявляет принцип нулевых ложных срабатываний: если axe пишет «нарушение», это нарушение (ошибки в самой библиотеке, конечно, бывают). Спорные места он не записывает в ошибки, а помечает как требующие ручной проверки.

Где axe-core уже встроен

Чаще всего его запускают, даже не зная названия:

Lighthouse и PageSpeed Insights. Оценка доступности считается по аудитам, которые описаны правилами axe, и взвешивается по их влиянию на пользователя. Ручные проверки в баллы не входят.
Расширение axe DevTools для браузера от Deque. Показывает каждое нарушение с подсветкой элемента и подсказкой, как исправить.
Автотесты. Пакет @axe-core/playwright подключает проверку к сценариям на Playwright: тест открывает корзину и форму заказа и падает, если появилось новое нарушение.

Схема: движок axe-core работает в Lighthouse и PageSpeed Insights, в расширении axe DevTools и в автотестах на Playwright — Где работает движок axe-core

Последний вариант полезнее всего на живом проекте. Разовый аудит быстро устаревает: новый баннер или форма, и серый текст снова на месте. Проверка в автотестах ловит такие вещи до выкладки.

Зачем доступность сайту, который продаёт

Плохой контраст мешает и людям без инвалидности. Его не прочитает покупатель постарше и человек с телефоном на солнце. Форма, которую нельзя пройти с клавиатуры, неудобна всем, кто привык к Tab. Часть правил совпадает с SEO: alt, заголовки, понятный текст ссылок.

В России требования к доступности описаны в ГОСТ Р 52872-2019, он введён с 1 апреля 2020 года и основан на WCAG 2.1. Национальные стандарты применяются добровольно, если закон или договор не делают их обязательными, поэтому проверьте, что сказано в вашем техзадании или в требованиях отрасли.

Чего автоматическая проверка не увидит

По оценке самой Deque, axe-core находит в среднем 57% проблем WCAG. Остальное видит только человек:

alt есть, но бессмысленный: «image1» или «фото» у всех товаров. axe проверяет наличие, а не смысл.
Фокус клавиатуры прыгает по странице в странном порядке или прячется под закреплённой шапкой.
Ошибка формы показана только красной рамкой без текста.
Всплывающее окно нельзя закрыть без мыши.

Сравнение: какие ошибки доступности находит axe-core автоматически, а какие требуют ручной проверки человеком — Что видит axe и что остаётся человеку

Поэтому отчёт axe с нулём ошибок не значит «сайт доступен». Это значит, что очевидного не осталось. Дальше нужна ручная проверка: пройти главные сценарии клавиатурой, послушать страницу экранным диктором, а лучше провести юзабилити-тестирование с реальными пользователями. Многие проблемы закладываются ещё в вёрстке, про это статья Семантическая вёрстка.

Проверка доступности сайта через axe и Lighthouse

Почему Lighthouse ставит 100 баллов за доступность, а сайтом всё равно неудобно пользоваться?

Баллы Lighthouse считаются только по автоматическим аудитам, а ручные проверки в оценку не входят. Порядок фокуса, смысл подписей к картинкам и понятность ошибок в формах машина не оценит, поэтому 100 баллов означают лишь отсутствие очевидных нарушений.

Чем проверка axe отличается от версии для слабовидящих?

Версия для слабовидящих меняет оформление по кнопке: крупный шрифт, контраст, отключение картинок. axe-core проверяет сам сайт: можно ли им пользоваться без отдельной версии, с диктором и клавиатурой. Одно другое не заменяет, а при доступной основной вёрстке отдельная версия часто становится лишней.

Как проверить сайт на доступность без программиста?

Откройте страницу в Chrome, запустите Lighthouse в инструментах разработчика и выберите категорию доступности. Подробнее с подсветкой элементов покажет расширение axe DevTools. Проверяйте кроме главной корзину, форму заявки и личный кабинет.

Сколько проблем доступности находит axe-core автоматически?

По данным Deque, в среднем около 57% проблем WCAG. Остальные требуют человека: смысл подписей, порядок фокуса, понятность ошибок в формах. Спорные элементы axe отдаёт в отчёте отдельным списком на ручную проверку.

Где в разработке подключают axe-core, чтобы ошибки не возвращались?

В автотестах, которые запускаются при каждом обновлении сайта. Сценарий на Playwright открывает главные страницы, axe проверяет их, и сборка останавливается, если появилось новое нарушение. Так серый текст или кнопка без подписи не попадают на боевой сайт незамеченными.

Проверку доступности по WCAG включаем в UX/UI-аудит: прогоняем axe по главным страницам и формам и проходим сценарии вручную. Найденные проблемы исправляем при UX/UI-оптимизации сайта.

Документация axe, WCAG и ГОСТ

Deque Systems: репозиторий axe-core и его описание
W3C: Web Content Accessibility Guidelines (WCAG) 2.2
Chrome for Developers: Lighthouse accessibility scoring
Playwright: Accessibility testing
ГОСТ Р 52872-2019 «Интернет-ресурсы и другая информация, представленная в электронно-цифровой форме. Приложения для стационарных и мобильных устройств, иные пользовательские интерфейсы. Требования доступности для людей с инвалидностью и других лиц с ограничениями жизнедеятельности»

См. также: HTML, UX (User Experience).