Задача CI — автоматически выявлять нарушения доступности веб-интерфейса: какой механизм следует встроить в автотесты?
В CI следует встроить автоматизированный аудит доступности страниц и компонентов с помощью анализатора правил доступности, например инструмента на базе axe-core. Он проверяет DOM, роли, атрибуты, контраст и другие машинно выявляемые признаки нарушений.
Такой аудит нужно запускать на критичных страницах и блокировать сборку только по согласованным нарушениям высокой значимости. Он не заменяет ручную проверку клавиатурой, скринридером и оценку удобства интерфейса.
Проверка доступности долгое время выполнялась преимущественно вручную: специалист проходил сценарии с клавиатурой, экранным диктором и другими вспомогательными технологиями. Это давало качественный результат, но плохо подходило для частого запуска после каждого изменения.
Автоматизированные анализаторы появились как способ регулярно выявлять повторяемые нарушения, которые можно определить по структуре страницы и её вычисленным свойствам. Их развитие связано с практическим применением рекомендаций WCAG, однако сами правила доступности включают и аспекты, не сводимые к статическому анализу.
Изменение компонента может незаметно удалить подпись поля, нарушить связь между заголовком и содержимым, ухудшить контраст или сделать элемент недоступным с клавиатуры. Если проверять это только перед релизом, дефекты обнаруживаются поздно и требуют повторной проверки большого числа экранов.
Полное блокирование CI по любому предупреждению тоже опасно. Автоматический инструмент может находить неоднозначные случаи, не видеть ошибки в пользовательском сценарии или сообщать о нарушении в области, которую конкретный продукт сознательно обрабатывает иначе. Поэтому важно отделять надёжные ошибки от рекомендаций и задавать понятную политику гейта.
Автотест должен открыть страницу или компонент в состоянии, близком к пользовательскому, дождаться загрузки динамического содержимого и передать результирующее дерево доступности анализатору. Инструмент сопоставляет найденные элементы с набором правил и возвращает нарушения, предупреждения и сведения о непроверенных случаях.
Практическая схема обычно включает:
Тестовая пирамида здесь также важна. Быстрые проверки компонентов дают ранний сигнал, а небольшой набор проверок полноценных страниц выявляет ошибки, возникающие только после интеграции компонентов и данных.
Автоматический аудит имеет ограничения. Он хорошо обнаруживает отсутствие обязательных атрибутов, некоторые ошибки структуры и контраста, но не может надёжно определить, понятен ли текст, логичен ли порядок фокуса для пользователя или корректно ли объявляется сложный динамический сценарий. Поэтому нужны отдельные проверки клавиатурой, скринридером и, при необходимости, участием пользователей с ограничениями.
Исключения следует оформлять явно: указывать причину, владельца и срок пересмотра. Простое отключение правила или игнорирование всего отчёта превращает автоматизацию в формальность и скрывает регрессии.
После переработки формы оплаты команда обнаружила, что визуально интерфейс не изменился, но несколько полей потеряли доступные имена, а сообщение об ошибке не связывалось с полем. Ручная проверка выполнялась только перед выпуском, поэтому подобные дефекты могли находиться поздно.
Рассматривались три варианта. Полностью ручная проверка давала наиболее широкий охват, но не подходила для каждого изменения. Сравнение скриншотов почти не помогало обнаружить семантические проблемы. Запуск автоматического анализатора был быстрым и хорошо обнаруживал типовые нарушения, но требовал дополнения ручными проверками.
Выбрали аудит компонентов при изменениях и проверку нескольких критичных пользовательских маршрутов в CI. Сборку блокировали только по новым нарушениям высокой и средней подтверждённой значимости, а сомнительные результаты отправляли на проверку. В результате дефекты структуры и связности полей стали обнаруживаться до ручной приёмки, но команда не стала считать зелёный автоматический аудит доказательством полной доступности.
Нет. Анализатор проверяет только формализуемые признаки и может не понять смысл текста, корректность сценария, порядок фокуса в сложном интерфейсе или качество объявления изменений скринридером. Поэтому зелёный результат означает отсутствие обнаруженных правилом проблем, а не полное соответствие потребностям пользователей.
Отчёт может содержать предупреждения, неоднозначные случаи и результаты, требующие человеческой оценки. Если любое сообщение сразу блокирует сборку, команда начнёт массово добавлять исключения или отключит проверку целиком. Надёжнее разделить результаты по уверенности и серьёзности, блокировать только согласованный набор и контролировать новые исключения.
Нужны оба уровня с разными целями. Проверка компонентов быстрее и локализует дефект рядом с изменением, но не видит ошибки интеграции, состояния после взаимодействия и проблемы маршрута. Проверка страниц дороже, зато выявляет нарушения, возникающие из сочетания компонентов, данных и динамической логики; поэтому обычно её включают в небольшой набор критичных сценариев.