纯前端实现可访问颜色选择器：色彩空间、实时对比度与键盘操作

颜色选择器看起来是拖动一块渐变区域，实际要同时处理颜色模型、数值格式、键盘操作和文本对比度。如果只提供一个 Canvas 调色板，触摸和鼠标用户能选色，键盘用户却无法调整；如果只保存十六进制字符串，透明度和色彩空间信息又会丢失。

一、明确内部颜色模型

先把颜色统一成一种内部表示，再按界面需要转换为 HEX、RGB 或 HSL。内部用归一化通道和 alpha 能减少解析差异；展示时再格式化和取整。转换函数应独立测试，避免每次输入都在不同组件里重复实现。

const color = {
  r: 0.18,
  g: 0.42,
  b: 0.86,
  a: 1,
};

HSL 适合做色相、饱和度和明度控件，但不适合直接计算视觉亮度。判断文字是否清楚时，应在 sRGB 线性空间中计算相对亮度，而不是比较原始 RGB 数值。

二、提供键盘可操作的控制

颜色平面和色相条都应提供等价输入。优先使用原生 range 或数字输入框，让方向键、Page Up、Page Down 和直接输入都能工作。自定义二维色板必须说明方向键行为，并提供单独的可聚焦控制点，不能要求用户按住鼠标拖拽。

每个控件都要有明确名称，例如“色相”“饱和度”“透明度”，并在值变化时播报可读结果。不要只把当前颜色写成一个十六进制色块，读屏用户需要知道通道值和最终颜色名称。

三、实时对比度反馈

选择文字色或背景色时，实时显示与目标背景的对比度。先用实际算法计算，再提示是否达到普通文本和辅助文本的常见阈值。颜色预览必须同时包含选中颜色上的文字样例，不能只看纯色块。

function relativeLuminance(rgb) {
  const linear = rgb.map((value) => (
    value <= 0.04045
      ? value / 12.92
      : ((value + 0.055) / 1.055) ** 2.4
  ));
  return 0.2126 * linear[0] + 0.7152 * linear[1] + 0.0722 * linear[2];
}

对比度提示不应只靠红绿颜色区分。使用“通过”“未通过”的文字，并说明当前比值和参照背景，用户才能判断需要调整哪一端。

四、色域边界和格式转换

从 P3 或其他广色域输入转换到 sRGB 时，部分颜色可能超出可显示范围。转换后要检查数值是否被裁切，并在产品需要时提示“该颜色包含超出 sRGB 的成分”。不要悄悄修改用户保存的原始值。

HEX 适合紧凑展示，但不天然表达 alpha；八位 HEX、rgba 和现代颜色函数的解释也不同。解析输入时限制格式和精度，输出时避免浮点数无限小数。用户手动输入的非法颜色应返回字段错误，而不是把控件重置成黑色。

五、状态更新不要抖动

拖动色板会连续产生大量值。界面可以即时预览，但持久化要防抖；发送分析日志或保存主题时只提交最后一个稳定值。外部同步更新颜色时，先判断是否正在拖拽，避免远端值把当前指针操作打断。

六、透明度和背景棋盘

alpha 不是颜色亮度，也不应和明度滑杆混在一起。透明颜色需要棋盘背景辅助观察，但棋盘不能影响最终导出值。提供“无效值”“完全透明”等文本状态，确保无法看到棋盘的用户仍能理解当前 alpha。

七、与主题和设计令牌衔接

选出的颜色最终要进入设计令牌或主题。保存时记录格式、色彩空间和来源，例如“用户选择”“品牌预设”“自动生成”。预览模式和编辑模式分开，应用新主题前先整体检查页面，而不是只检查色块本身。

八、测试重点

覆盖 HEX、RGB、HSL 往返转换、透明通道、边界值、色域裁切、键盘调整、非法输入、对比度计算、拖拽防抖和外部同步冲突。对颜色转换使用性质测试，对交互使用键盘和读屏测试，能覆盖颜色选择器最容易遗漏的两类问题。

九、小结

可访问颜色选择器需要统一的内部模型、原生或键盘等价控件、实时且可读的对比度反馈，以及对色域和格式转换的明确边界。视觉调色板只是入口，能否准确输入、理解和恢复颜色，才是组件真正可用的标准。