HIFDocs
HIF / Документация / Цветовые системы

Цвет и темы

Статус: нормативная основа и инженерный справочник

Версия: 0.1

Этот документ определяет, как HIF специфицирует, выводит, реализует и проверяет цветовые системы. Цвет одновременно является светом, материалом, восприятием, информацией, идентичностью и значением реализации. Представление цвета как списка шестнадцатеричных литералов исключает условия, при которых он имеет смысл.

Прикладная реализация: HIF Colour Lab создаёт и проверяет палитры по ограничениям этого документа. Его результат является поддержкой решения и материалом реализации, а не сертификатом соответствия.

1. Область действия и руководящие принципы

Соответствующая HIF цветовая система MUST:

  • начинаться с требований к коммуникации, задаче и среде;
  • отличать измеренный цвет от внешнего вида и названного цвета;
  • назначать семантику независимо от текущих цветовых значений;
  • сохранять смысл без опоры только на цвет;
  • ставить пользовательские и платформенные настройки контраста выше выражения бренда;
  • объявлять цветовые пространства, опорные белые точки, gamut и политику преобразования;
  • покрывать каждое состояние, режим, тему, носитель и поддерживаемый класс дисплеев;
  • предоставлять трассируемые tokens вместо неуправляемых литералов;
  • проверяться в отрисованном виде, а не утверждаться по листу palette;
  • сохранять происхождение, лицензию и историю изменения каждого внешнего материала.

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

2. Цвет — отношение человека и физической среды

2.1. Зрение и адаптация

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

Проектирование и оценка SHOULD учитывать:

  • luminance дисплея, уровень чёрного, засветку и окружающее освещение;
  • хроматическую адаптацию и окружающее поле;
  • размер, spatial frequency и длительность стимула;
  • одновременный контраст и локальный фон;
  • возрастные изменения, нарушения зрения и варианты цветового зрения;
  • калибровку дисплея, обработку операционной системой и угол обзора;
  • различие излучаемого, отражённого и прошедшего света.

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

2.2. Колориметрия

Колориметрия CIE представляет спектральный стимул через трёхстимульные значения для определённого стандартного наблюдателя и источника света. Цветовая спецификация для обмена MUST указывать достаточно следующих параметров, чтобы быть однозначной:

цветовая модель или цветовое пространство
координаты и alpha
передаточные функции
RGB primaries, где применимо
опорная белая точка и адаптация
наблюдатель и источник света, где применимо
диапазон кодирования и bit depth
ICC profile или эквивалентное условие вывода
rendering intent или политика gamut mapping

Колориметрическое равенство не является полной моделью внешнего вида, читаемости, предпочтения или смысла. Перцептивная равномерность Lab, LCH, Oklab или OkLCH — инженерное приближение, а не утверждение, что равные численные шаги одинаково заметны в каждом контексте.

2.3. Аддитивные и субтрактивные контексты

Дисплеи создают цвет преимущественно аддитивным смешением излучаемых основных цветов. Печать и пигментированные объекты изменяют падающий свет посредством поглощения, рассеяния и отражения; процессная печать обычно управляется через CMYK-сепарации, краски, материал и output profile.

Значения RGB и CMYK MUST NOT преобразовываться копированием процентов каналов. Производство для печати MUST определять:

  • процесс вывода и ICC characterization/profile;
  • материал, набор красок, total area coverage и политику black generation;
  • источник света для просмотра и условия цветопробы;
  • spot colours и допуски, если их требует соответствие бренду;
  • политику overprint, transparency и trapping;
  • доступное нецветовое представление, когда смысл критичен.

Экранная имитация печати является soft proof, а не результатом приёмки тиража.

3. Политика цветовых пространств

3.1. Обязательные различия

HIF различает:

  • device-dependent RGB: значения, интерпретируемые через определённое устройство или profile;
  • sRGB: базовое цветовое пространство веба и резервный цветовой охват для вывода;
  • Display P3: более широкий RGB gamut с белой точкой D65, доступный на совместимых платформах;
  • CIE XYZ: независимый от устройства трёхстимульный эталон;
  • CIE Lab/LCH: приближённо перцептивные декартовы/полярные пространства, привязанные к опорной белой точке;
  • Oklab/OkLCH: приближённо перцептивные пространства, созданные для улучшенного поведения hue и lightness в современных цветовых вычислениях;
  • CMYK/spot channels: координаты процесса вывода, а не универсальные координаты внешнего вида.

HSL и HSV MAY использоваться как средства авторинга, когда их взаимодействие понятно, но MUST NOT считаться перцептивно равномерными пространствами palette. Их равные численные шаги не создают равных воспринимаемых шагов.

3.2. Рабочие и выходные цветовые пространства

Каждый продукт MUST объявлять:

ЗадачаОбязательное объявление
Авторинг/выводРабочее пространство и формула/версия
Обмен tokensКаноническая сериализация и точность
Базовый вебЗначения sRGB для каждого обязательного токена
Широкий цветовой охватНеобязательные значения P3 и правила применения и резервного варианта
ИзображенияВстроенный профиль и правила преобразования и экспорта
ПечатьНазванный output intent/profile и цветопроба
Проверка различияМетрика, параметры и допуск

OkLCH RECOMMENDED для контролируемого вывода palette, поскольку lightness, chroma и hue можно изменять с меньшим количеством нежелательных взаимодействий, чем в HSL. Это не устраняет необходимость расчёта контраста, gamut mapping и визуального тестирования.

3.3. Alpha и композитинг

Цвет с alpha не имеет окончательного внешнего вида до композитинга. Контраст MUST рассчитываться по полученным отрисованным foreground и background, включая:

  • каждый backdrop сквозь полупрозрачные слои;
  • gradients, изображения и видео;
  • blend- и filter-эффекты;
  • antialiasing и отрисовку текста;
  • overlays состояний disabled, hover, focus и selected.

Полупрозрачный семантический foreground SHOULD заменяться непрозрачным вычисленным token, когда требуется предсказуемый контраст. Opacity MUST NOT быть единственным способом обозначения disabled или unavailable.

4. Gamut и mapping

4.1. Контракты gamut

Каждый цвет palette MUST классифицироваться как:

  • допустимый в базовом цветовом охвате sRGB;
  • улучшенный в Display P3 с указанным резервным вариантом sRGB;
  • специфичный для вывода и недоступный в обязательном носителе; или
  • недопустимый для данного контракта доставки.

Цвет с широким охватом MUST быть прогрессивным улучшением. Резервный вариант MUST сохранять роль, иерархию, контраст и различия состояний; он не обязан сохранять максимальную chroma.

4.2. Правила mapping

Clipping каналов может изменять hue и отношения цветов. Преобразование MUST использовать объявленный детерминированный mapping, подходящий содержанию и носителю. Для отдельных CSS-цветов следуйте текущим требованиям gamut mapping из CSS Color, реализованным поддерживаемыми user agents. Для изображений и печати выбирайте rendering intent в зависимости от необходимости сохранить отдельные колориметрические значения или отношения внутри изображения.

Запись mapping MUST содержать:

исходное и целевое пространства
алгоритм и версия реализации
адаптация белой точки
rendering intent
число или mask цветов вне gamut
максимум и распределение цветового различия
утверждённые исключения

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

5. Архитектура palette

5.1. Четыре слоя

измеренные или выбранные исходные цвета
→ primitive scales
→ semantic roles
→ component tokens
→ отрисованные сочетания и состояния

Primitive names вроде azure.60 MAY описывать шкалу. Код продукта и компонентов MUST использовать semantic roles вроде colour.text.primary или colour.status.danger.background.

5.2. Вывод primitive scale

Генератор шкалы MUST принимать как минимум:

  • seed hue или набор anchors;
  • целевые позиции lightness;
  • политику chroma по lightness и gamut;
  • политику neutral axis;
  • базовый и расширенный gamuts;
  • минимальное соседнее перцептивное различие;
  • точность округления и сериализации.

Рекомендуемая процедура:

  1. установить набор ролей и требуемые пары контраста;
  2. выбрать нейтральные и хроматические anchors в рабочем пространстве;
  3. определить монотонно упорядоченные цели lightness;
  4. ограничить chroma так, чтобы каждый результат приемлемо отображался в обязательные gamuts;
  5. решить критические пары foreground/background до декоративного применения;
  6. проверить соседние шаги объявленной метрикой цветового различия;
  7. использовать симуляции вариантов цветового зрения как диагностику;
  8. отрисовать реальные компоненты в каждом состоянии и режиме;
  9. корректировать систему, а не отдельные failing swatches;
  10. зафиксировать вычисленные значения с алгоритмом, версией и свидетельствами.

Равные шаги lightness являются начальной моделью, а не достаточной шкалой. Почти чёрные и почти белые шаги, малые marks и low-chroma neutrals требуют проверки в отрисованном виде.

5.3. Набор семантических ролей

Как минимум определите парные роли foreground/background и border для:

  • canvas, base, raised, overlay и inverse surfaces;
  • primary, secondary, disabled и inverse text;
  • links и visited links, если история раскрывается;
  • accent и focus;
  • selection и current item;
  • статусов information, success, warning, danger и neutral;
  • controls в состояниях rest, hover, active, focus-visible, selected, disabled, read-only, invalid, busy и unavailable;
  • категорий, последовательностей и расхождений data visualisation;
  • code, syntax и diff content, где поддерживается.

Семейства статусов MUST различать:

семантика статуса
× уровень emphasis
× foreground/background/border/icon
× состояние взаимодействия
× цветовой режим
× режим контраста

5.4. Нейтральные цвета

«Серый» сам по себе не является семантически нейтральным. Neutral scale MAY быть хроматической, но её hue bias MUST NOT заставлять поверхность выглядеть как несущую статус. Нейтральные цвета MUST сохранять устойчивую иерархию при обычных вариациях дисплеев и замене forced colours.

6. Контраст и статус стандартов

6.1. WCAG 2.2

WCAG 2.2 является W3C Recommendation и используется HIF как нормативная базовая линия web, если Product Profile не принимает более строгое требование. Применяйте точную область действия и исключения:

  • обычный текст: не менее 4.5:1 по Success Criterion 1.4.3;
  • large-scale text: не менее 3:1 по 1.4.3;
  • enhanced level: 7:1 для обычного и 4.5:1 для крупного текста по 1.4.6;
  • несущие информацию компоненты UI и графические объекты: не менее 3:1 относительно соседних цветов по 1.4.11;
  • цвет MUST NOT быть единственным визуальным средством передачи информации или запроса реакции по 1.4.1.

Для conformance используйте алгоритм WCAG по относительной luminance sRGB и contrast ratio. Не заменяйте его значением lightness Lab/Oklab, оценкой design tool, eyedropper скриншота или APCA.

Оценивайте фактические размер и weight шрифта, а не названия tokens вроде «large». Текст поверх gradients или изображений MUST проходить порог в наименее благоприятной обязательной области либо иметь надёжный backplate.

6.2. APCA и WCAG 3

APCA — развивающаяся модель контраста, связанная с исследованиями будущих рекомендаций по доступности. На дату этого документа WCAG 3.0 является рабочим проектом W3C, а не рекомендацией W3C. Ни APCA, ни проект WCAG 3 MUST NOT представляться как замена соответствию WCAG 2.2.

Команда MAY экспериментально рассчитывать APCA, если фиксирует:

  • алгоритм и версию;
  • исследовательский вопрос;
  • размер, weight, polarity и контекст текста;
  • отличия от решения по WCAG 2.2;
  • план human evaluation;
  • ненормативный статус результата.

Когда стандарты созреют, HIF MUST пересмотреть свидетельства и выполнить явную миграцию; молчаливая замена порогов запрещена.

6.3. За пределами попарных коэффициентов

Коэффициенты conformance не доказывают читаемость. Проверяйте:

  • typeface, size, weight и rendering;
  • блики, низкую и высокую luminance;
  • тонкие strokes и малые icons;
  • spatial separation и crowding;
  • polarity и продолжительный просмотр;
  • различие между состояниями и между control и окружением;
  • когнитивную интерпретацию и нецветовые cues.

7. Варианты цветового зрения

Дизайн MUST оставаться управляемым и понятным при релевантных ограничениях красно-зелёного, сине-жёлтого и low-chroma различения. Симуляторы являются диагностическими преобразованиями, а не доказательством того, что каждый наблюдатель видит симуляцию.

Для каждого существенного различия предоставьте один или несколько независимых cues:

  • label или value;
  • shape или icon;
  • line style, texture или pattern;
  • position или grouping;
  • direct annotation;
  • постоянный текст состояния.

Не кодируйте две независимые переменные только близкими hues. Для категориальных данных проверяйте попарное различие при фактическом размере mark и на фактическом фоне. Для статуса проверяйте понимание, а не только различие.

8. Режимы и темы

8.1. Измерения

Сохраняйте независимыми:

  • light/dark colour scheme;
  • повышенный, пониженный или custom contrast;
  • forced colours;
  • brand;
  • platform;
  • density;
  • environmental mode;
  • data-visualisation scheme.

«Тёмный бренд» не является dark mode. High-contrast theme не является более насыщенной brand palette.

8.2. Dark mode

Тёмная тема MUST проектироваться как новый набор отношений, а не инверсия. Она SHOULD:

  • контролировать максимальную luminance и блики больших областей;
  • сохранять иерархию без опоры только на shadows;
  • снижать chroma там, где высокая chroma расплывается на тёмном окружении;
  • избегать догмы чистых чёрного/белого, если другие значения тестируются лучше;
  • сохранять знакомые значения статусов без требования одинаковых координат;
  • повторно проверять images, syntax, charts, elevation и disabled states;
  • объявлять color-scheme или платформенные эквиваленты, где поддерживается.

8.3. Forced colours и пользовательский контраст

В режиме web forced-colours цвета автора обычно заменяются цветами user agent и системы. Компоненты HIF MUST:

  • использовать native semantics и system colour keywords, где уместно;
  • сохранять видимые focus, boundaries, selection и state;
  • не использовать background images как единственный signifier;
  • применять forced-color-adjust: none только для ограниченного элемента, который самостоятельно реализует эквивалентное доступное отображение;
  • тестировать пользовательские palettes, а не только стандартную high-contrast theme производителя.

forced-colors: active не обязательно означает «больше контраста»; это означает принудительную пользовательскую palette. Не выводите предпочтения сверх контракта media query.

8.4. Матрица состояний

Каждая интерактивная роль MUST иметь проверенную матрицу:

СостояниеПоверхностьСодержаниеГраницаДополнительный cue
Restsemantic baseчитаемоеобнаружимое, где нужноlabel/shape
Hoverразличимоестабильноенеобязательный emphasispointer не является доказательством
Activeнемедленный откликчитаемоеяснаяmotion/geometry MAY дополнять
Focus-visibleлюбаячитаемоепостоянный focus indicatorнезависим от hover
Selected/currentразличимаячитаемоестабильнаяprogrammatic state и/или mark
Disabledнеактивнаяпри необходимости всё ещё понятноебез ложного focussemantic disabled state
Invalidstatus surfaceerror textstatus boundarytext/icon, не только красный
Busyстабильный контекстprogress/statusбез ложного завершенияprogrammatic busy state

Сочетания вроде focused+selected+invalid MUST быть специфицированы. Матрица MUST тестироваться в каждом поддерживаемом режиме; вывод состояний через фиксированную opacity недостаточен.

9. Цвет в data visualisation

Выбирайте palette по семантике данных:

  • qualitative для неупорядоченных категорий;
  • sequential для упорядоченной величины;
  • diverging для значимого отклонения вокруг определённого центра;
  • cyclic для периодических значений, где концы соединяются;
  • highlight для контекста и одного или нескольких focal values.

Требования:

  • порядок lightness MUST соответствовать упорядоченным данным, если lightness передаёт величину;
  • центр diverging MUST соответствовать реальному аналитическому reference;
  • qualitative colours MUST оставаться различимыми при фактическом размере mark;
  • missing, filtered, estimated и out-of-range values требуют явных ролей;
  • legends MUST использовать те же порядок и symbols, что и plot;
  • direct labels предпочтительны, когда сокращают поиск;
  • избыточные shape, line style, pattern или text MUST нести критические различия;
  • размер palette MUST ограничиваться доказанным различением, а не набором цветов бренда;
  • WCAG non-text contrast применяется к несущей информацию графике в своей области действия.

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

10. Изображения, медиа и печать

Raster и vector assets MUST иметь:

  • встроенный или явно назначенный colour profile;
  • определённый путь преобразования/экспорта;
  • утверждённый резервный вариант базового цветового охвата;
  • проверки alpha edges и compositing;
  • print proofing, если печать является выходом;
  • альтернативное представление, когда цвет несёт информацию.

Brand spot colours MUST фиксировать физический reference, условие измерения, допустимое цветовое различие, классы материала/процесса и полномочия утверждения. Одно экранное hex-значение не является спецификацией spot colour.

11. Контракт tokens и реализации

11.1. Слои tokens

colour.primitive.*
colour.semantic.*
colour.component.*

Каждый semantic colour token MUST фиксировать:

идентификатор и описание
значение по режиму, gamut и платформе
ожидаемые пары foreground/background
разрешённые компоненты и запрещённые применения
минимальное требование WCAG
требование нецветовой подсказки
резервный вариант и сопоставление принудительных системных цветов
источник, алгоритм и версию
владельца и дату пересмотра

Token aliases MUST быть ацикличными и типобезопасными. Build MUST завершаться ошибкой при отсутствующих значениях режима, неразрешённых aliases, неверном синтаксисе, gamut вне контракта или известной ошибке контраста.

11.2. Пример доставки CSS

:root {
  color-scheme: light dark;
  --colour-surface-base: #ffffff;
  --colour-text-primary: #1f2328;
  --colour-focus: #0969da;
}

@media (prefers-color-scheme: dark) {
  :root {
    --colour-surface-base: #0d1117;
    --colour-text-primary: #f0f6fc;
    --colour-focus: #58a6ff;
  }
}

@media (forced-colors: active) {
  :focus-visible {
    outline: 2px solid Highlight;
  }
}

Этот пример иллюстрирует только архитектуру. Его значения не являются универсальной palette HIF и не устанавливают conformance компонента.

12. Детерминированный алгоритм выбора

Для каждой обязательной semantic role:

  1. укажите информацию, действие или отношение поверхностей;
  2. перечислите режимы, состояния, носители и требуемые пары;
  3. установите нормативные ограничения контраста и нецветового cue;
  4. выберите anchor рабочего пространства, согласованный с брендом и конвенцией;
  5. сначала решите lightness критических пар;
  6. ограничьте chroma и hue по gamut, статусу и попарному различию;
  7. выведите базовые sRGB и необязательные расширенные значения;
  8. запустите автоматические проверки синтаксиса, gamut, контраста и token graph;
  9. отрисуйте полную матрицу состояний на реальном содержании и фоне;
  10. проверьте zoom, forced colours, варианты цветового зрения и поддерживаемые устройства;
  11. проверьте интерпретацию с репрезентативными людьми для consequential uses;
  12. зафиксируйте значения, алгоритм, исключения, свидетельства и владельца.

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

12.1. Жёсткие условия и оценка выразительности

Механизм выбора MUST отделять условия отклонения от целей предпочтения. Некорректный синтаксис, неразрешённые токены, выход за установленный цветовой охват, недостаточный обязательный контраст, отсутствие нецветовой подсказки и неразличимые существенные состояния являются жёсткими нарушениями. Оценка выразительности MUST NOT компенсировать такие нарушения.

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

HIF не устанавливает универсальную «оценку приятности», предельную цветность OkLCH или соотношение площадей 60–30–10. Продукт MUST зафиксировать правила визуального акцента и проверить их на репрезентативных композициях и с участием людей. Каноническими входными данными генератора и реестром выпуска служит шаблон профиля цветовой системы.

13. Приёмочные тесты

13.1. Автоматические

  • Каждый цвет разбирается в объявленном пространстве.
  • Каждый обязательный token разрешается для каждого режима, платформы и gamut.
  • Графы aliases полны и ацикличны.
  • Базовые значения находятся в sRGB или имеют утверждённый mapping.
  • Обязательные пары foreground/background проходят объявленные пороги WCAG 2.2.
  • Пары состояний проходят продуктовые пороги различимости.
  • Lightness вычисленной шкалы монотонен, где это указано.
  • Внешние assets содержат ожидаемые profiles и provenance.
  • Скриншоты покрывают все сочетания state/mode/theme.

13.2. Ручные и human tests

  • Focus, selection, errors и disabled states остаются различимыми.
  • Смысл сохраняется в greyscale и релевантной диагностике вариантов цветового зрения.
  • Forced-colour и пользовательские palettes сохраняют структуру и работу.
  • Dark mode не имеет неприемлемых бликов, ореолов и потерянного elevation.
  • Текст поверх media проходит порог в каждой обязательной позиции.
  • Charts сохраняют порядок, различение категорий и смысл missing data.
  • Проверены репрезентативные устройства, окружающие условия и print proofs.
  • Люди могут определить существенные статус и действие без названий цветов.

13.3. Свидетельства релиза

Запись релиза MUST называть test inputs, rendering engines, устройства, настройки дисплея, profiles, алгоритмы, версии стандартов, failures, exceptions и residual risks. Изображения palette или одного автоматического отчёта недостаточно.

14. Источники

Все источники являются англоязычными оригинальными исследованиями, стандартами или официальными спецификациями. Дата обращения: 30 июля 2026 года.