Палитра задаёт характер, но не должна прятать смысл
Представим список заявок: рядом с одной зелёная точка, рядом с другой — оранжевая. Автору макета всё понятно. Посетителю приходится догадываться: заявку приняли, проверили или уже выполнили? Дело не только в восприятии цвета, но и в отсутствии объяснения. Критерий WCAG 1.4.1 требует не использовать цвет как единственный способ передачи информации. Практический первый шаг — найти места, где изменение оттенка меняет значение, и записать это значение обычными словами. Декоративный градиент может оставаться декорацией; статус оплаты — нет. Так обсуждение начинается с задачи человека, а не с выбора более яркой краски.
Ошибка должна объяснять, что исправить
Красная рамка вокруг поля показывает, где возникла трудность, но не сообщает, как её устранить. В условной форме записи полезнее написать возле даты: «Выберите дату позже сегодняшней». Дополнительный значок помогает заметить сообщение, однако не заменяет текст. Обязательные поля тоже не стоит выделять только цветом: слово «обязательно» или заранее объяснённый символ устраняет двусмысленность. Сообщение об ошибке нужно программно связать с соответствующим полем. Видимая подсказка и передача информации вспомогательным технологиям решают разные задачи. Скрытое доступное описание не помогает зрячему посетителю, который не различает выбранные оттенки и не использует экранную программу чтения.
Назовите состояние, а не только подсветите его
В карточке заказа цветная точка может сопровождаться словами «Ожидает подтверждения». Когда состояние меняется, меняется и надпись: «Подтверждено». Человеку больше не требуется помнить легенду цветов. Если обновление происходит без загрузки страницы, команда отдельно проверяет, сообщается ли оно вспомогательным технологиям подходящим способом. Не каждое косметическое изменение требует срочного объявления. У переключателя или выбранного варианта должны совпадать видимый признак и программное состояние. Сообщение в верхней части страницы не исправляет элемент управления, который технически продолжает считаться невыбранным. Проверять нужно целую последовательность действий, включая обратное переключение.
График — не головоломка с цветной легендой
На воображаемом графике обращений из двух каналов серии можно отличать не только синей и зелёной линиями, но и маркерами разной формы, а названия поставить рядом с самими линиями. При пересечениях далёкая легенда заставляет взгляд постоянно перемещаться между обозначением и данными. Главный вывод полезно сформулировать под графиком, точные значения — предоставить в доступной таблице. Штриховка может различать области, но большое количество узоров создаёт лишний шум. Выбирайте столько признаков, сколько действительно нужно для конкретного сравнения. Новая палитра сама по себе не делает изображение графика доступным для всех способов восприятия.
Контраст помогает увидеть; подпись помогает понять
Более тёмный зелёный лучше заметен на светлом фоне, но не объясняет, что обозначает зелёный. Контраст и смысл нужно проверять отдельно. WCAG 1.4.11 посвящён контрасту значимой нетекстовой информации. На практике это повод проверить нужные границы, индикаторы и важные части графики, а не автоматически рисовать обводку у каждого элемента. Для текста существуют отдельные требования. Значок может отлично выделяться и оставаться непонятным; ясная надпись может быть слишком бледной. Исправление одной проблемы не устраняет вторую. Особенно внимательно стоит смотреть на состояния, которые появляются только после действия и поэтому отсутствуют на основном дизайнерском макете.
Проверяйте путь пользователя, а не только картинку
Временно переведите макет в оттенки серого и попробуйте найти ошибку, выбранный тариф и выполненную задачу. Это полезная быстрая проверка зависимости от цвета, но не доказательство соответствия WCAG и не точная имитация всех особенностей зрения. Затем пройдите реальный сценарий клавиатурой, проверьте названия и состояния элементов, читаемость сообщений и необходимые контрасты. Попросите человека, который впервые видит интерфейс, объяснить обозначения без подсказок. Перед передачей в разработку запишите правило компонента: какие слова, знак и программное состояние сопровождают каждый результат. Такое описание позволяет сохранить понятность и после изменения фирменной палитры.