Как проверить контрастность цветов без установки каких-либо инструментов

Аудит контрастности цветов часто воспринимают как специализированную задачу по доступности: открыть дизайн-файл, установить плагин, экспортировать скриншоты, запустить отчет, поспорить о брендовых цветах. Это может быть полезно, но большинству команд стоит начинать не с этого.

Для production-сайта самый быстрый надежный аудит обычно выполняется прямо в браузере, который у вас уже открыт. Современные браузерные DevTools позволяют проверять вычисленные цвета, показывать коэффициенты контрастности, выявлять стили состояний и тестировать неудобные случаи, которые пропускают автоматические отчеты.

В этом руководстве предполагается, что вы ничего не устанавливаете. Никаких браузерных расширений. Никаких дизайн-плагинов. Никаких платных audit suite. Только страница, браузер и простой метод.

Правила контрастности, которые действительно нужны

Для большинства веб-задач требования WCAG к контрастности сводятся к нескольким порогам:

• Обычный текст: контрастность не менее 4.5:1 относительно фона.
• Крупный текст: не менее 3:1. WCAG определяет это примерно как 24 CSS-пикселя или около 18.66 CSS-пикселя, если текст полужирный.
• UI-компоненты и графические объекты: не менее 3:1 для значимых границ, иконок, состояний и частей графиков, необходимых для понимания интерфейса.
• Повышенная контрастность: 7:1 для обычного текста и 4.5:1 для крупного текста, если вы стремитесь выйти за пределы базового уровня.

Есть исключения, например неактивные элементы управления, декоративные элементы и логотипы. Используйте эти исключения осторожно. «Это часть бренда» — не исключение, а дизайн-ограничение.

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

Начинайте с отрисованной страницы, а не с дизайн-файла

Дизайн-файлы полезны, но они не учитывают все реальные переменные: CSS-переопределения, прозрачность, hover-состояния, рендеринг шрифтов в браузере, пользовательский zoom, dark mode, унаследованные стили, контент из CMS и маркетинговые вставки.

Аудируйте страницу в том виде, в котором ее получают пользователи.

Откройте страницу в актуальном desktop-браузере. Chrome, Edge, Firefox и Safari — у всех есть полезные инструменты инспектирования. Точные названия отличаются, но workflow один и тот же:

1. Щелкните правой кнопкой мыши по тексту или UI-элементу.
2. Выберите Inspect.
3. Найдите вычисленные color и background-color.
4. Используйте цветовой образец браузера или панель доступности, чтобы посмотреть коэффициент контрастности.
5. Зафиксируйте pass, fail и неопределенные случаи.

В браузерах на базе Chromium color picker часто показывает коэффициент контрастности и подсказки WCAG о pass/fail для текста. Firefox DevTools также показывает информацию о доступности и инструменты для работы с цветом. Safari Web Inspector может показывать вычисленные стили и информацию о доступности, хотя workflow немного отличается.

Главное — не конкретный браузер. Главное — читать вычисленный результат, а не значение, которое, как кому-то кажется, использует компонент.

Сначала составьте небольшой список для аудита

Не инспектируйте случайный текст, пока не устанете. Составьте короткий перечень паттернов:

• Основной текст на главном фоне страницы.
• Приглушенный текст, подписи, метаданные и placeholders.
• Ссылки в normal, hover, visited и focus состояниях.
• Primary, secondary и destructive кнопки.
• Метки форм, вспомогательный текст, ошибки и сообщения об успехе.
• Элементы навигации, breadcrumbs и вкладки.
• Cards, badges, pills и tags.
• Иконки, передающие смысл.
• Графики, карты, progress bars и статусные цвета.
• Текст поверх изображений, видео, градиентов или полупрозрачных наложений.

Этого достаточно, чтобы найти большинство ошибок на типичном сайте. Это также привязывает аудит к компонентам, а не к разовым пикселям.

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

Проверяйте контрастность текста в DevTools

Для обычного текста на сплошном фоне браузер обычно может рассчитать контрастность за вас.

Инспектируйте элемент и найдите свойство color. Откройте color picker из цветового образца. Если браузер может определить фон, он покажет коэффициент контрастности. Некоторые инструменты также рисуют линию в color picker, показывающую, где цвет пройдет пороги 3:1, 4.5:1 или 7:1.

Когда браузер сообщает о failure, верьте ему, пока не сможете доказать обратное. Когда он сообщает о pass, все равно применяйте здравый смысл. Мелкий тонкий шрифт, дисплеи низкого качества, сильное сглаживание и сложные фоны могут сделать технически проходящий текст визуально слабым.

Практическое правило: если основной текст едва проходит на 4.55:1, не празднуйте. Дайте ему больше запаса. Требования к контрастности — это минимумы, а не идеальные цели.

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

Проверяйте реальный фон, включая прозрачность

Многие ошибки контрастности возникают потому, что видимый фон не совпадает с объявленным фоном.

Распространенные ловушки:

• Текст внутри полупрозрачной карточки.
• Текст на родителе, к которому применен opacity.
• Наложения с использованием rgba() или color-mix().
• Градиенты за заголовками.
• Фоновые изображения, которые меняются по области текста.
• Theme variables, которые изменяются в dark mode.

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

Для текста поверх изображений не берите образец с самой удачной части изображения. Берите образец с худшей правдоподобной области за текстом. Если изображение меняется через загрузки в CMS, карусели или responsive crops, это неустойчивая система контрастности. Добавьте надежное наложение, тень текста, сплошной контейнер или градиентную обработку, которая защищает текст независимо от изображения.

Хорошая система наложений на изображения скучна: одинаковая сила наложения, предсказуемая область кадрирования, достаточная контрастность даже с яркими фотографиями. Скучно — нормально. Пользователи пытаются читать.

Не забывайте о состояниях

Статические скриншоты пропускают многие проблемы контрастности. Проверяйте интерактивные состояния прямо в браузере.

В DevTools принудительно включайте псевдоклассы, такие как:

• :hover
• :focus
• :focus-visible
• :active
• :visited
• :disabled
• :checked
• :invalid

Затем снова проверяйте вычисленные цвета.

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

Для disabled элементов управления правила WCAG по контрастности предусматривают исключение для неактивных компонентов. Это не означает, что disabled элементы по умолчанию должны быть нечитаемыми. Если disabled-состояние несет полезную информацию, сделайте его читаемым. Если нет — подумайте, нужно ли вообще его показывать.

Используйте Lighthouse, но не передавайте ему право суждения

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

Автоматические проверки хорошо находят текстовые узлы с очевидными failure по вычисленной контрастности. Они слабее в случаях:

• Текст, встроенный в изображения.
• Метки, отрисованные в canvas.
• Пограничные случаи SVG.
• Failure, проявляющиеся только на hover.
• Качество индикатора фокуса.
• Графики, где смысл передается цветовыми связями.
• Компоненты, скрытые за аутентификацией, меню или шагами формы.

Если отчет зеленый, вам все равно нужно инспектировать репрезентативные компоненты. Если отчет красный, не паникуйте и приоритизируйте ошибки по влиянию на пользователей. Тот же принцип в целом применим к отчетам о производительности и доступности: воспринимайте вывод инструмента как свидетельство, а не как приговор. Мы используем такой подход в нашем руководстве по чтению отчета Lighthouse без паники, и здесь он применяется напрямую.

Проверяйте и нетекстовую контрастность

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

Проверьте как минимум эти случаи:

• Границы input относительно фона страницы.
• Обводки checkbox и radio.
• Состояния toggle.
• Кнопки только с иконкой.
• Иконки ошибок и предупреждающие символы.
• Линии, столбцы и подписи графиков.
• Индикаторы прогресса.
• Индикаторы выбранной вкладки или активной навигации.

Цель обычно составляет 3:1 относительно соседних цветов. Например, светло-серая граница input на белом фоне может быть почти невидимой. График с пятью пастельными линиями может выглядеть элегантно и при этом оставаться непригодным для использования.

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

Фиксируйте результаты в формате, удобном разработчикам

Полезный аудит контрастности не говорит «некоторые серые не проходят». Он указывает компонент, состояние, текущие значения, ожидаемый порог и предлагаемое исправление.

Хорошо работает компактный формат:

| Component | State | Foreground | Background | Ratio | Target | Result | Suggested fix | |---|---:|---:|---:|---:|---:|---|---| | Метаданные карточки | Default | #8A8F98 | #FFFFFF | 3.2:1 | 4.5:1 | Fail | Использовать --color-text-muted-strong | | Primary button | Hover | #FFFFFF | #2F6FEA | 4.8:1 | 4.5:1 | Pass | Оставить | | Граница input | Default | #D7DCE2 | #FFFFFF | 1.4:1 | 3:1 | Fail | Затемнить border token |

Привязывайте исправления к design tokens, если они есть на сайте. Не исправляйте двадцать отдельных компонентов, если настоящая проблема — один слабый token.

Делайте исправления немного сильнее минимума

Ошибки контрастности часто легко исправить плохо. Команды слегка двигают цвет, пока checker не покажет 4.51:1, и идут дальше. Это не оставляет запаса на рендеринг шрифтов, прозрачность, различия браузеров, theming, вариативность изображений или будущие правки бренда.

Предпочитайте комфортные цели:

• Основной текст: ближе к 7:1, когда это практично.
• Приглушенный текст: все равно выше 4.5:1, если это настоящий контент.
• UI-границы и иконки: уверенно выше 3:1.
• Текст поверх изображений: используйте контролируемое наложение вместо угадывания для каждого изображения.

Веб просматривают на дешевых ноутбуках, тусклых телефонах, ярких тротуарах, тонированных мониторах и стареющих дисплеях. Минимальное соответствие — не то же самое, что комфортное чтение.

<!-- tool-cta:start -->

💡 Попробуйте это: При проверке контрастных пар, взятых из DevTools, Color Converter помогает преобразовывать значения между hex, RGB и HSL, чтобы они совпадали с вашими заметками аудита.

<!-- tool-cta:end -->

Чек-лист аудита контрастности без установки инструментов

Используйте эту последовательность, когда нужен быстрый, но убедительный аудит:

1. Откройте production-страницу в современном браузере.
2. Перечислите основные текстовые, UI- и state-паттерны.
3. Инспектируйте вычисленные цвета переднего плана и фона в DevTools.
4. Используйте встроенный color picker или панель доступности, чтобы посмотреть контрастность.
5. Принудительно включите hover, focus, active, visited и invalid состояния.
6. Проверьте текст поверх изображений и градиентов относительно худшего правдоподобного фона.
7. Проверьте нетекстовые части UI на соответствие требованию 3:1.
8. Запустите встроенный автоматический аудит как страховку, а не как весь аудит.
9. Фиксируйте failure по компонентам и tokens.
10. Исправляйте с запасом, а не едва переходя порог.

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