Профиль цветовой системы

Статус: нормативный шаблон реализации

Версия: 0.1

Этот реестр используется для постановки задачи, создания, проверки и выпуска цветовой системы продукта. Он переводит требования HIF-COL-* и главы «Цвет и темы» в исполнимый контракт. Инструктивный текст можно удалить только после заполнения каждого обязательного поля или регистрации исключения.

1. Идентификация и полномочия

2. Контекст до выбора цвета

Зафиксируйте:

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

2.1. Обязательные семантические роли

Перечислите роли до ввода каких-либо цветовых значений.

Добавьте все роли продукта. Название цвета не является описанием смысла.

3. Правила выразительности и сдержанности

Этот раздел не позволяет бесконтрольной насыщенности стать визуальной системой. Это ограничения конкретного продукта, а не универсальная формула «60–30–10».

Для цвета высокой цветности MUST быть указана роль. Если две несвязанные области конкурируют на одном уровне акцента, сначала уменьшите площадь, цветность или заметность, а не добавляйте ещё один цвет.

4. Исходные цвета и права

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

5. Контракт цветового пространства и охвата

Каждый расширенный токен MUST разрешаться в утверждённое базовое значение.

6. Контракт построения

Генератор MUST рассматривать построение палитры как задачу оптимизации с ограничениями.

6.1. Жёсткие ограничения

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

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

6.2. Мягкие цели

Задайте порядок и вес целей для конкретного продукта:

Высокая оценка мягких целей MUST NOT компенсировать нарушение жёсткого ограничения.

6.3. Входные данные воспроизводимости

profile_id:
profile_version:
generator:
  name:
  version:
  source_revision:
working_space: oklch
baseline_gamut: srgb
enhanced_gamut:
seeds: []
lightness_targets: []
chroma_policy:
hue_policy:
neutral_policy:
contrast_pairs: []
distinction_constraints: []
rounding:
random_seed: null

Одинаковые входные данные и версия реализации MUST давать одинаковые выпущенные значения.

7. Выходные исходные шкалы

Для каждого семейства зафиксируйте опорные точки, направление светлоты, допустимое смещение цветового тона, границы цветности и назначение.

Исходные шкалы являются материалом реализации. Компоненты продукта MUST использовать семантические или компонентные токены.

8. Матрица обязательных пар

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

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

9. Режимы и матрицы состояний

Заполните независимо для:

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

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

10. Поставка токенов

Для обмена используйте цветовой формат Design Tokens Community Group 2025.10, если зафиксированное ограничение платформы не требует другого представления.

{
  "colour": {
    "semantic": {
      "text-primary": {
        "$type": "color",
        "$description": "Основной читаемый текст на базовой поверхности.",
        "$value": "{colour.primitive.neutral-90}"
      }
    }
  }
}

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

11. Реестр проверки

11.1. Автоматические свидетельства

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

11.2. Проверка готового представления и проверка с людьми

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

12. Исключения и остаточный риск

Исключение MUST NOT скрываться повторным созданием более привлекательной палитры или изменением весов оценки после проверки.

13. Решение о выпуске

Выпущенные профиль, версия генератора, канонические токены и свидетельства MUST версионироваться совместно.