Доступность WCAG и визуальное тестирование: почему эти две дисциплины больше не могут игнорировать друг друга
Веб-доступность, по определению W3C, означает «проектирование и разработку веб-сайтов, инструментов и технологий таким образом, чтобы люди с ограниченными возможностями могли их использовать» (источник: W3C, Web Accessibility Initiative). Каким бы широким ни было это определение, оно в значительной степени опирается на визуальные критерии. Контраст цветов, размер текста, видимость фокуса клавиатуры, расстояние между элементами — все эти аспекты являются одновременно требованиями доступности и визуально измеримыми свойствами.
И тем не менее большинство команд рассматривают доступность и визуальное тестирование как две отдельные практики, которыми занимаются разные люди, с разными инструментами, на разных этапах цикла разработки.
Это стратегическая ошибка. Визуальная доступность тестируема автоматически, а визуальное тестирование — наиболее естественный инструмент для её непрерывного мониторинга.
Содержание
- Что WCAG требует визуально
- Почему классические инструменты доступности недостаточны
- Визуальное тестирование как страховочная сеть для доступности
- Критерии WCAG, которые визуальное тестирование выявляет нативно
- Как организовать визуальный мониторинг доступности
- FAQ
Что WCAG требует визуально
WCAG (Web Content Accessibility Guidelines) версии 2.2 содержат 86 критериев успеха, распределённых по трём уровням соответствия: A, AA и AAA. Среди этих критериев значительная доля непосредственно касается визуального оформления интерфейсов.
Рассмотрим наиболее важные.
Контраст цветов (критерий 1.4.3 для уровня AA, 1.4.6 для AAA) устанавливает минимальный коэффициент контрастности 4.5:1 для обычного текста и 3:1 для крупного текста. Этот критерий чисто визуальный: он проверяется путём сравнения цветов текста и его фона.
Размер текста (критерий 1.4.4) требует, чтобы контент мог быть увеличен до 200% без потери информации или функциональности. Это означает, что при 200% масштабе текст не должен выходить за пределы контейнеров, элементы не должны перекрываться, а информация должна оставаться читаемой. Всё это поддаётся визуальной проверке.
Индикатор фокуса (критерий 2.4.7 для AA, усиленный критериями 2.4.11 и 2.4.12 в WCAG 2.2) требует, чтобы каждый интерактивный элемент отображал видимый индикатор при получении фокуса клавиатуры. Этот индикатор должен иметь достаточный контраст и минимальную площадь. Снова — визуальный критерий.
Интервалы в тексте (критерий 1.4.12) требуют, чтобы контент оставался функциональным при изменении пользователем межстрочного интервала до 1,5 от размера шрифта, интервала между абзацами — до 2 раз, интервала между буквами — до 0,12, а между словами — до 0,16. Если эти настройки ломают вёрстку — это нарушение доступности, обнаруживаемое визуально.
Перетекание контента (критерий 1.4.10, также называемый «reflow») требует, чтобы контент отображался без горизонтальной прокрутки при ширине 320 CSS-пикселей. Это именно то, что проверяет адаптивное тестирование.
Вывод очевиден: значительная часть соответствия WCAG основана на визуально измеримых свойствах.
Почему классические инструменты доступности недостаточны
Инструменты аудита доступности, такие как axe-core или Lighthouse, незаменимы. Они анализируют DOM, проверяют атрибуты ARIA, обнаруживают отсутствующие теги и сигнализируют о структурных нарушениях. Никто это не оспаривает.
Но у этих инструментов есть фундаментальное ограничение: они анализируют код, а не рендеринг. Они проверяют то, что объявляют HTML и CSS, а не то, что пользователь видит на самом деле.
Конкретный пример. Представьте кнопку с белым текстом на синем фоне и коэффициентом контрастности 5.2:1, который соответствует стандартам. При обновлении CSS разработчик делает фон кнопки светлее, не трогая текст. Коэффициент падает до 2.8:1. axe-core может обнаружить это в некоторых случаях, но только если таблица стилей корректно интерпретирована движком анализа. Визуальное тестирование же фиксирует эту регрессию немедленно, поскольку сравнивает реальный рендеринг кнопки до и после изменения.
Другой частый случай: индикатор фокуса задан в CSS, но обновление фреймворка удаляет или перезаписывает стиль outline. Функционально кнопка остаётся кликабельной. Структурно HTML не изменился. Но визуально фокус исчез. Ни один инструмент анализа DOM не обнаруживает эту проблему надёжно. Визуальное тестирование фиксирует разницу в рендеринге.
Эти инструменты также не обнаруживают проблемы, связанные с масштабированием. Когда пользователь увеличивает текст до 200%, переполнения, наложения и обрезанный текст — это чисто визуальные проблемы. Они не обнаруживаются при статическом анализе кода.
Классические инструменты доступности необходимы, но недостаточны. Они покрывают структурные критерии (текстовые альтернативы, структура заголовков, ARIA-роли), но оставляют слепую зону во всём, что касается визуального рендеринга.
Визуальное тестирование как страховочная сеть для доступности
Автоматизированное визуальное тестирование заключается в захвате скриншотов ваших страниц и компонентов с последующим сравнением с эталоном (baseline) для обнаружения любых непреднамеренных визуальных изменений. Применительно к доступности этот механизм становится мощной страховочной сетью.
Вот почему.
Оно обнаруживает регрессии, а не только нарушения. Аудит доступности сообщает, соответствует ли ваш сайт стандартам в определённый момент. Визуальное тестирование предупреждает вас, как только изменение кода ухудшает визуальную доступность. Это разница между диагнозом и системой сигнализации.
Работает с реальным рендерингом. Визуальное тестирование фиксирует то, что браузер действительно отображает после применения всех таблиц стилей, JavaScript-скриптов и расчётов компоновки. Оно не интерпретирует CSS — оно констатирует результат.
Охватывает кросс-браузерные и мульти-разрешительные сценарии. Проблемы визуальной доступности различаются в зависимости от браузеров и размеров экрана. Контраст, соответствующий стандартам в Chrome, может не соответствовать в Safari, если шрифты рендерятся по-разному. Кросс-браузерное визуальное тестирование фиксирует эти различия.
Интегрируется в CI/CD. Запуская визуальные тесты при каждом pull request, вы обнаруживаете регрессии доступности до того, как они попадут в продакшен. Это профилактика, а не исправление.
Не требует экспертизы в области доступности для настройки. Любой член команды может настроить визуальный тест, который захватывает страницы с различными уровнями масштабирования или с принудительно включёнными стилями фокуса. Сравнение происходит автоматически.
Критерии WCAG, которые визуальное тестирование выявляет нативно
Рассмотрим по критериям аспекты WCAG, которые визуальное тестирование эффективно покрывает.
Критерии 1.4.3 и 1.4.6 — Контраст. Сочетая визуальное тестирование с фильтрами симуляции дальтонизма или извлекая цвета из скриншотов, вы можете проверять, что контраст остаётся соответствующим стандартам после каждого изменения. Изменение палитры, ухудшающее контраст, будет немедленно заметно при сравнении скриншотов.
Критерий 1.4.4 — Масштабирование текста. Захватывайте страницы при 200% масштабе. Любая регрессия (обрезанный текст, наложение элементов, переполнение контейнеров) будет обнаружена визуальным сравнением.
Критерий 1.4.10 — Reflow. Захватывайте страницы при ширине 320 CSS-пикселей. Адаптивное визуальное тестирование проверяет, что контент корректно адаптируется без горизонтальной прокрутки.
Критерий 1.4.12 — Интервалы в тексте. Внедрите стили интервалов, требуемые критерием (межстрочный интервал 1.5, интервал абзацев 2x, буквы 0.12em, слова 0.16em), и захватите результат. Сравните с baseline для обнаружения элементов, которые ломаются при этих ограничениях.
Критерии 2.4.7, 2.4.11, 2.4.12 — Видимый фокус. Принудительно установите фокус клавиатуры на каждый интерактивный элемент и захватите результат. Визуальное тестирование обнаруживает исчезновение или деградацию индикатора фокуса.
Критерий 1.4.11 — Контраст нетекстовых элементов. Иконки, границы полей форм, индикаторы состояния — все эти элементы должны иметь коэффициент контрастности не менее 3:1. Визуальное тестирование отслеживает их естественным образом.
Как организовать визуальный мониторинг доступности
Практическая реализация опирается на несколько простых принципов.
Создавайте baseline в условиях доступности. Не ограничивайтесь захватом страниц в их состоянии по умолчанию. Создавайте дополнительные baseline: при 200% масштабе, при ширине 320 пикселей, с внедрёнными стилями интервалов WCAG и с принудительным фокусом на интерактивных элементах.
Интегрируйте эти тесты в ваш CI/CD-пайплайн. Каждый pull request должен запускать визуальное сравнение по всем этим условиям. Если изменение CSS ухудшает визуальную доступность, тест блокирует merge.
Используйте адаптированные пороги допуска. Для тестов доступности уменьшите допустимый порог различий. Изменение в 2 пикселя на индикаторе фокуса может сделать его несоответствующим. Допуск должен быть строже, чем для обычного визуального теста.
Документируйте ваши baseline доступности. Каждый baseline должен быть связан с критерием WCAG, который он проверяет. Это упрощает аудит и обеспечивает прослеживаемость при проверках.
Сочетайте со средствами статического анализа. Визуальное тестирование не заменяет axe-core или Lighthouse. Оно их дополняет. Используйте инструменты анализа для структурных критериев (текстовые альтернативы, структура заголовков, ARIA), а визуальное тестирование — для критериев рендеринга. Вместе они покрывают практически все WCAG.
Такой инструмент, как Delta-QA, позволяющий настраивать визуальные тесты без написания кода, делает этот подход доступным для всей команды, включая ответственных за доступность, которые не являются разработчиками.
Визуальная доступность — не роскошь, а обязанность
С июня 2025 года Европейский закон о доступности (EAA) обязывает компании Евросоюза обеспечивать доступность своих цифровых продуктов и услуг. В России ГОСТ Р 52872-2019 устанавливает требования к доступности веб-контента для людей с ограниченными возможностями.
Финансовые санкции существуют и растут. Но помимо юридических рисков, доступность — это конкурентное преимущество. По данным Всемирной организации здравоохранения, более миллиарда людей в мире живут с той или иной формой инвалидности. Игнорировать доступность — значит игнорировать значительный рынок.
Визуальная доступность — наиболее легко автоматизируемая часть этого обязательства. Вам не нужен эксперт по WCAG, чтобы делать скриншоты в различных условиях и сравнивать результаты. Вам нужен правильно настроенный инструмент визуального тестирования.
FAQ
Заменяет ли визуальное тестирование полный аудит доступности WCAG?
Нет. Визуальное тестирование покрывает визуальные критерии WCAG (контраст, фокус, интервалы, масштабирование, reflow), но не структурные критерии — текстовые альтернативы, навигацию с клавиатуры, ARIA-роли. Оно дополняет аудит, а не заменяет его. Примерно 30–40% критериев WCAG 2.2 имеют прямой визуальный компонент.
Какие уровни соответствия WCAG помогает проверить визуальное тестирование?
Визуальное тестирование актуально для всех трёх уровней: A, AA и AAA. Уровень AA, наиболее часто требуемый нормативами, содержит несколько основных визуальных критериев (контраст 1.4.3, видимый фокус 2.4.7, reflow 1.4.10, интервалы 1.4.12). Уровень AAA усиливает требования к контрасту (1.4.6 с коэффициентом 7:1) и добавляет дополнительные критерии, все проверяемые визуально.
Как тестировать визуальную доступность без технических навыков?
С помощью no-code инструмента, такого как Delta-QA, вы настраиваете страницы для тестирования, определяете условия (размер экрана, масштаб, браузер), и инструмент автоматически захватывает и сравнивает скриншоты. Ни одной строки кода не требуется. Интерфейс показывает визуальные различия, и вы решаете, приемлемы они или нет.
Как часто нужно проверять визуальную доступность?
При каждом изменении фронтенд-кода. Интеграция в CI/CD — лучший подход: каждый pull request автоматически запускает тесты. Если вы не можете автоматизировать на этом уровне, еженедельная проверка — приемлемый минимум для обнаружения регрессий до их накопления.
Обнаруживает ли визуальное тестирование проблемы доступности на мобильных устройствах?
Да, при условии настройки тестов для распространённых мобильных разрешений (360px, 375px, 414px ширины). Адаптивное визуальное тестирование фиксирует реальный рендеринг при каждом разрешении и обнаруживает проблемы с reflow, обрезанный текст, слишком маленькие для касания элементы и ухудшенный контраст при мобильном рендеринге.
Распространяется ли Европейский закон о доступности на мою компанию?
Если вы продаёте цифровые продукты или услуги потребителям в Евросоюзе — да. EAA действует с июня 2025 года для сайтов электронной коммерции, банковских услуг, СМИ, транспорта и телекоммуникаций, среди прочих. Микропредприятия с менее чем 10 сотрудниками и оборотом менее 2 миллионов евро пользуются исключениями, но остальные обязаны соответствовать.
Заключение
Визуальная доступность и визуальное тестирование — две стороны одной медали. Наиболее часто нарушаемые критерии WCAG (контраст, фокус, интервалы, масштабирование) — это визуальные свойства, измеримые автоматически. Инструменты анализа DOM покрывают только часть проблемы. Визуальное тестирование заполняет эту слепую зону, проверяя то, что пользователь видит на самом деле.
Вместо того чтобы рассматривать доступность как разовый аудит раз в год, интегрируйте визуальное тестирование в ваш пайплайн для непрерывного мониторинга. Это эффективнее, надёжнее и несоизмеримо дешевле позднего исправления.