Светло-серый текст на белом фоне может выглядеть аккуратно на дизайнерском мониторе, но быть нечитаемым на телефоне, солнце или для пользователя со сниженным зрением. Контраст проверяется численно для фактических цветов и состояний, а не по субъективному ощущению.

Для уровня WCAG AA обычному тексту обычно требуется отношение не ниже 4.5:1, крупному — 3:1; значимым границам и графическим элементам интерфейса часто требуется 3:1. Размер, жирность, прозрачность и реальный фон влияют на классификацию.

Что проверить в первую очередь

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

  • Соберите фактические computed color/background-color, включая opacity и родительские слои.
  • Проверьте основной, вторичный, ссылочный, disabled, hover, focus, error и placeholder-текст.
  • Отдельно проверьте текст поверх фотографий, градиентов и видео на разных кадрах.
  • Уточните целевой уровень WCAG и реальные размеры/начертания шрифтов.

Почему возникает проблема

У подобных сбоев редко бывает одна универсальная причина. На итог одновременно влияют конфигурация приложения, окружение, данные, кеш, права и внешние сервисы. Проверка должна идти от внешнего симптома к конкретному уровню, на котором впервые появляется неверное состояние.

  • В дизайн-системе один muted-цвет используется на нескольких разных фонах.
  • Opacity применяется к контейнеру и одновременно ослабляет текст и фон.
  • Hover/focus делает ссылку светлее и нарушает контраст именно при взаимодействии.
  • Текст на изображении проверен только на одном удачном участке.
  • Placeholder используется вместо постоянной подписи и имеет слишком слабый цвет.

Пошаговая диагностика

Диагностику проводите на копии или в контролируемое время. Перед изменениями сохраните конфигурацию, данные и журналы. Каждый шаг должен отвечать на один вопрос и оставлять измеримый результат: код ответа, запись в логе, состояние процесса, значение поля или воспроизводимый тест.

  • Пройдите автоматическим сканером ключевые страницы, но подтвердите результаты ручным инструментом.
  • Снимите пары цветов из computed styles, а не только из макета.
  • Проверьте мобильные размеры: текст может перестать считаться крупным.
  • Переключите темы, состояния ошибок, disabled и режимы высокой контрастности.
  • Проверьте фокус с клавиатуры и информацию, переданную только цветом.

Как считать контраст правильно

Отношение строится по относительной яркости итоговых цветов после смешивания прозрачности с фоном. Hex из CSS-переменной сам по себе может не совпасть с видимым цветом.

  • Обычный текст проверяйте по порогу 4.5:1 для AA.
  • Крупным считается текст не по названию класса, а по размеру и жирности согласно критерию WCAG.
  • Границы полей, иконки и индикаторы состояния оценивайте отдельно от текста.
  • Логотипы и неактивные элементы имеют исключения, но не используйте их для важного контента.
  • Цвет не должен быть единственным способом показать ошибку, выбор или статус.

Как исправить проблему

Исправление лучше разбить на небольшие обратимые изменения. После каждого шага повторяйте исходный сценарий и проверяйте соседние функции. Если правка касается данных, сначала выполните ее на ограниченной выборке и сохраните журнал затронутых записей.

  • Скорректируйте дизайн-токены текста и поверхностей, а не десятки отдельных компонентов.
  • Замените прозрачный серый на непрозрачный цвет с предсказуемым итоговым контрастом.
  • Добавьте подложку или перенесите текст с изображения на стабильный фон.
  • Сохраните различимость ссылок не только цветом: подчеркивание, форма или другой устойчивый признак.
  • Создайте доступные токены для default/hover/focus/disabled/error в светлой и темной теме.

Безопасный порядок внедрения

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

Как проверить результат

Успешный разовый тест еще не доказывает исправление. Нужны повторный запуск, крайние случаи и проверка после очистки кеша, перезапуска процесса или новой сессии. Для критичных сценариев полезно сохранить автоматический тест или хотя бы короткий регрессионный чек-лист.

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

Типичные ошибки при исправлении

  • Делать весь текст почти черным и разрушать иерархию вместо настройки токенов.
  • Проверять только default-состояние и забывать hover, placeholder и ошибку.
  • Считать жирный текст крупным независимо от размера.
  • Ориентироваться только на автоматический аудит без динамических состояний и изображений.

Как предотвратить повторение

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

  • Добавьте контрастные пары в дизайн-токены и документацию компонентов.
  • Проверяйте доступность в CI и визуальном QA новых страниц.
  • Запретите произвольные полупрозрачные цвета для смыслового текста.
  • Включайте контраст, клавиатуру и масштаб 200% в критерии приемки.

Что подготовить для разбора

  • Краткое описание ожидаемого и фактического поведения без паролей, токенов и персональных данных.
  • Точное время и последовательность действий, после которых появляется проблема.
  • Версии приложения, окружения и зависимостей, а также перечень последних изменений.
  • Фрагменты журналов с контекстом до и после ошибки; секреты в них необходимо скрыть.
  • Описание уже выполненных проверок и способ безопасно повторить проблему.

Частые вопросы

Нужно ли достигать 7:1 везде?

7:1 относится к более строгому уровню AAA для обычного текста. Для большинства проектов базовой целью является AA, но требования проекта могут быть выше.

Почему инструмент показывает другой результат, чем макет?

На странице участвуют opacity, смешивание слоев, изображение и реальные computed styles. Проверять нужно итоговые цвета в браузере.

Когда нужна помощь специалиста

Если аудит отмечает десятки проблем контраста, я могу сгруппировать их по дизайн-токенам, исправить системно без потери визуальной иерархии и проверить компоненты, состояния и мобильные размеры по WCAG.