Тестирование доступности: слои, ловящие то, что не видит axe

getByRole — самый дешёвый гейт, который у вас уже есть

Прежде чем добавлять инструменты, заметьте тот, что уже в сборке: приоритет запросов React Testing Library (RTL). getByRole("button", { name: "Save" }) — не просто селектор, а утверждение, что дерево доступности содержит узел с ролью кнопки и доступным именем «Save». Конвертируйте кликабельный div из первого урока — и тест не сможет его найти: нет роли, нет совпадения, красный тест. Сорвите подпись с кнопки-иконки — и опция name перестаёт совпадать. Оберните список опций в div, ломающий семантику списка, — и getAllByRole("listitem") вернётся короче. Каждый тест компонента, написанный так, — дымовой тест доступности, который не стоит ничего дополнительно и бежит на каждом PR; именно поэтому документация RTL ранжирует запросы по тому, насколько они отражают восприятие AT: сначала роль, затем подпись, затем текст, и data-testid как явная последняя инстанция. Антипаттерн — тянуться к testid по умолчанию: он пришпиливает тесты к невидимым атрибутам, снимая давление, из-за которого семантические регрессии падают громко. Полезное командное правило: testid требует комментария, объясняющего, почему ни один ролевой запрос не подошёл.

Тот же приоритет лепит API компонентов. Тест, которому нужен getByRole("dialog", { name: "Подтвердите удаление" }), заставляет компонент диалога принять и провести доступный заголовок; тест с toHaveAccessibleName() на кнопке-иконке протаскивает проп aria-label насквозь. Тесты, написанные в словаре дерева доступности, толкают компоненты к тому, чтобы это дерево экспонировать, — дешёвый добродетельный цикл.

Что axe автоматизирует — честно

jest-axe подключает axe-core к тестам компонентов: отрендерить, выполнить axe(container), утвердить отсутствие нарушений. Что axe-core проверяет на самом деле — статически вычислимые факты об отрендеренном дереве: изображения без alt, поля без подписей, ARIA-атрибуты, невалидные для роли, отсутствующая структура ориентиров, дубли id, ломающие aria-labelledby, цветовой контраст. На этой территории он превосходен — быстрый, детерминированный, с низким уровнем ложных срабатываний как целью дизайна. Граница — всё, что требует суждения или взаимодействия: имеет ли порядок фокуса смысл; хорошее ли имя «Подробнее» для двенадцатой одинаковой ссылки (наличие имени проверяемо, качество — нет); даёт ли тайминг тоста скринридеру дочитать фразу; закрывает ли Escape пикер; описывает ли alt на самом деле график. Поставьте числа на границу и держите их консервативными: собственное заявление Deque «по объёму» — около 57%; аудит автоматических инструментов британского правительства и большинство независимых исследований приземляются возле трети обнаруживаемых нарушений WCAG. В любом случае зелёный axe ограничивает меньше половины проблемы — считайте его полом и никогда сертификатом.

Одно jsdom-специфичное честное замечание про jest-axe: проверке контраста нужны настоящие layout и отрисовка, которых jsdom не делает, — правило там ненадёжно и обычно отключено. Серьёзное развёртывание — axe в настоящем браузере, @axe-core/playwright против работающего приложения, где полный набор правил применяется к настоящим страницам с настоящим CSS. Покомпонентный jest-axe всё равно отрабатывает свой хлеб как быстрая регрессионная сеть для валидности ARIA и подписей, но засчитывается именно браузерный прогон.

Ручной проход, CI-гейты и регрессионное правило

Слой, до которого автоматизация не дотягивается, закрывается ритуалом, а не героизмом: скриптованный проход скринридером по критическим потокам — checkout, регистрация, форма движения денег — перед каждым релизом. Скриптованный значит письменный чек-лист на поток: достижим ли каждый контрол через Tab и стрелки; объявляет ли каждый осмысленные роль, имя и состояние; объявляется ли смена роута; восстанавливает ли диалог фокус; читается ли сообщение об ошибке. Гоняйте его на VoiceOver плюс Safari на macOS и NVDA плюс Chrome или Firefox на Windows — связках, на которых сидят настоящие пользователи, — и проход занимает двадцать-тридцать минут на поток, когда скрипт уже существует. Регулярность бьёт охват: три критических потока каждый релиз превосходят героический аудит всего приложения раз в год, потому что регрессии кучкуются там, где код шевелится.

В CI слои сортируются по латентности и охвату. eslint-plugin-jsx-a11y работает в редакторе и в lint-CI: статический анализ JSX — интерактивные элементы без клавиатурных обработчиков, отсутствующие alt, ARIA-атрибуты, невалидные для роли. Он быстрый и мелкий; видит только литеральный JSX, не вычисленные значения и не runtime-композицию. Ролевые запросы RTL бегут с юнит-тестами на каждом PR. Браузерный axe идёт по ключевым страницам на PR или ночью, гейтуя по принципу ноль новых нарушений — храповик, а не мандат на уборку: существующий долг инвентаризован, новый блокируется. Ручной проход гейтует сам релиз.

Регрессионное правило связывает систему: баг доступности сначала получает падающий тест, ровно как любой другой дефект. Баг восстановления фокуса — interaction-тест, утверждающий document.activeElement после закрытия. Лгущий aria-expanded — RTL-утверждение атрибута против состояния открытости. Необъявленный тост — тест, утверждающий смену текста live region. Считать a11y-находки нетестируемым фольклором — способ отгрузить один баг трижды; считать их дефектами с репродукциями — способ удешевлять ручной проход каждый квартал, потому что всё, что он когда-либо ловил, теперь пришпилено машиной.