Как проверить, что цветные уведомления и статусы доступны всем пользователям

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

Почему цвет нельзя считать единственным носителем смысла

По разным оценкам, дальтонизм той или иной степени встречается у заметной доли мужчин и у меньшей доли женщин. Чаще всего страдает различение красного и зелёного — а именно эта пара чаще всего используется для статусов «ошибка» и «успех». Кроме того, цветовое восприятие ухудшается при ярком солнце на экране смартфона, при низкой яркости, у пользователей с возрастными изменениями зрения, а также у всех, кто смотрит интерфейс на дешёвом мониторе с плохой цветопередачей.

Отсюда базовый принцип, закреплённый в стандарте WCAG (Web Content Accessibility Guidelines): цвет не должен быть единственным визуальным способом передачи информации. Если статус различим только по оттенку — часть аудитории его не увидит. Это касается не только точек и бейджей, но и выделения текста цветом, подсветки обязательных полей, индикации выбранных элементов в календаре или графике.

Что именно проверять: три уровня

1. Контраст цвета с фоном

Даже хорошо различимый для вас цвет может быть недостаточно контрастным. WCAG задаёт числовые ориентиры коэффициента контрастности:

• 4,5:1 — минимум для обычного текста (примерно до 18 пунктов или 14 пунктов жирного);
• 3:1 — минимум для крупного текста и для графических элементов, которые несут смысл: иконок статусов, границ полей, индикаторов;
• для текста в неактивных (disabled) элементах требование контраста не применяется, но полностью «слепить» его всё равно не стоит.

Коэффициент контрастности — это расчётная величина на основе относительной яркости цветов. Её не нужно вычислять вручную: существуют бесплатные онлайн-инструменты (например, WebAIM Contrast Checker) и встроенные проверки в браузерных инструментах разработчика, где достаточно указать два цвета — текста и фона.

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

2. Дублирование информации нецветовыми средствами

Пройдитесь по каждому цветовому сигналу и спросите: что ещё, кроме цвета, отличает это состояние? Допустимые дублирующие механизмы:

• текст — подпись «Ошибка», «Успешно отправлено», «Ожидает оплаты»;
• иконка — галочка, крестик, восклицательный знак, песочные часы или спиннер;
• форма и расположение — рамка вокруг поля, сдвиг, размер, заполненность индикатора;
• паттерн — штриховка, пунктир, разный стиль линии на графиках;
• анимация — пульсация, но с осторожностью и с уважением к настройке «уменьшить движение».

Хорошая проверка: переведите скриншот интерфейса в оттенки серого (в большинстве операционных систем есть режим «оттенки серого» или «светофильтры»). Если после обесцвечивания вы всё ещё безошибочно определяете каждый статус — дублирование работает. Если два статуса сливаются в одно серое пятно — они различаются только цветом.

3. Доступность для скринридеров и клавиатуры

Пользователь с программой экранного доступа не видит ни цвет, ни иконку. Ему нужен смысл в разметке. Проверьте:

• статусные сообщения озвучиваются автоматически (для веба — роль status или alert из ARIA, для нативных платформ — соответствующие механизмы объявлений);
• иконки без текста имеют текстовую альтернативу или корректную подпись доступности;
• декоративные цветовые элементы скрыты от скринридера, чтобы не засорять озвучку;
• к уведомлению можно добраться с клавиатуры, если оно интерактивно (например, содержит кнопку «Повторить»);
• ошибки в формах связаны с полями, чтобы при фокусе на поле пользователь слышал, что именно не так.

Пошаговый порядок проверки

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

1. Составьте инвентарь цветовых сигналов. Выпишите все места, где цвет передаёт смысл: статусы заказов, тосты, бейджи, валидация форм, индикаторы на графиках, подсветка в календарях и таблицах.
2. Проверьте контраст каждого сочетания. Возьмите цвета из дизайн-системы или кода и прогоните через контрастный калькулятор. Зафиксируйте значения в документации, чтобы не пересчитывать каждый раз.
3. Включите режим оттенков серого. Пройдите основные пользовательские сценарии: оформление заказа, отправка формы, просмотр статуса. Убедитесь, что состояния различимы.
4. Проверьте симуляцию дальтонизма. В браузерных инструментах разработчика (например, в Chrome DevTools есть эмуляция нарушений зрения) включите протанопию и дейтеранопию и посмотрите те же экраны. Особое внимание — парам «красный/зелёный».
5. Пройдите сценарий со скринридером. На компьютере — VoiceOver (macOS) или NVDA (Windows), на телефоне — VoiceOver (iOS) или TalkBack (Android). Отправьте форму с ошибкой и убедитесь, что ошибка объявляется без поиска её глазами.
6. Проверьте масштабирование. Увеличьте текст до 200% и включите системный тёмный режим. Уведомления не должны терять контраст, обрезаться или перекрывать друг друга.
7. Задокументируйте результат. Отметьте проблемные места, приоритезируйте их по частоте использования экрана и серьёзности последствий (ошибка оплаты важнее неудачной анимации бейджа).

Типичные ошибки и как их исправить

Ошибка	Чем опасна	Как исправить
Ошибка в форме подсвечена только красной рамкой	Пользователь с нарушенным цветовосприятием не понимает, какое поле заполнено неверно	Добавить текстовое сообщение рядом с полем, иконку и связать сообщение с полем для скринридера
Статусы в таблице различаются только цветом точки	Строки визуально сливаются, статус невозможно определить	Добавить текстовую метку статуса или различимые иконки
Бледно-жёлтый текст предупреждения на белом фоне	Контраст ниже минимума, текст плохо читается даже при нормальном зрении	Затемнить текст или использовать цветную подложку с тёмным текстом, проверив коэффициент
Тост появляется и исчезает, скринридер его не объявляет	Пользователь не узнаёт о результате действия вообще	Использовать роль status/alert или нативный механизм объявлений, увеличить время показа
Красный и зелёный графики без других различий	Линии неразличимы при дейтеранопии	Добавить разные стили линий, маркеры, подписи напрямую на графике
Смысл передан только словами «зелёное поле — успешно»	Формулировка бесполезна для незрячих пользователей и при печати	Описывать состояние по смыслу: «оплата подтверждена», а не по цвету

Особые случаи, о которых забывают

Тёмная тема и системные настройки

Если приложение поддерживает тёмную тему, контраст нужно проверять для обоих вариантов отдельно. Цвет, который давал 5:1 на белом фоне, на тёмном может упасть ниже порога. То же касается режимов повышенной контрастности и инверсии: проверьте, что уведомления не становятся невидимыми или, наоборот, кричащими.

Уведомления вне экрана приложения

Системные push-уведомления отображаются средствами операционной системы, и их базовую доступность обеспечивает платформа. Но вы управляете заголовком и текстом уведомления. Убедитесь, что смысл передан текстом, а не предполагается, что пользователь «увидит красный баннер» — в шторке уведомлений цвета могут отображаться иначе или не отображаться вовсе.

Печать и сохранение в PDF

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

Анимация и движение

Пульсирующий индикатор привлекает внимание, но у части пользователей вызывает дискомфорт. Уважайте системную настройку «уменьшить движение» и не делайте анимацию единственным признаком состояния.

Чек-лист для быстрой самопроверки

• Каждый цветовой сигнал дублируется текстом, иконкой, формой или паттерном.
• Контраст текста — не ниже 4,5:1, значимых графических элементов — не ниже 3:1.
• В режиме оттенков серого все статусы различимы.
• При эмуляции протанопии и дейтеранопии красные и зелёные элементы не сливаются.
• Скринридер объявляет появление важных уведомлений автоматически.
• Иконки статусов имеют текстовые альтернативы, декоративные элементы скрыты.
• Ошибки в формах связаны с полями и озвучиваются при фокусе.
• Интерфейс проверен в светлой и тёмной теме, при масштабе 200% и в режиме уменьшенного движения.
• Цвет никогда не упоминается в тексте как единственный ориентир («нажмите зелёную кнопку»).

Если условия такие — действуйте так

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

Вы получили жалобу, что пользователь не различает статусы. Начните с режима оттенков серого и эмуляции дальтонизма на конкретном экране из жалобы — так вы за минуты воспроизведёте проблему. Затем добавьте дублирующий признак, не трогая цвет: чаще всего достаточно текстовой метки.

Вы поддерживаете большой существующий продукт. Не пытайтесь исправить всё сразу. Составьте инвентарь цветовых сигналов, отсортируйте по частоте экранов и цене ошибки (платежи, безопасность, потеря данных — в первую очередь) и исправляйте по приоритету.

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

С чего начать прямо сегодня

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

Материал носит информационный характер. Конкретные требования к доступности зависят от юрисдикции, типа продукта и применимых стандартов: перед финальными решениями сверяйтесь с актуальными версиями WCAG, локальным законодательством о доступности и, при необходимости, с профильным специалистом по доступности интерфейсов.