可视化可访问性与配色

引言

「可访问性」在可视化领域常被当成合规任务——加个 aria-label、把色板换成色盲友好就算交差。这只触及了问题的表层。真正的问题在于：图表是一种视觉编码，任何依赖单一视觉通道的设计，都会把无法接收该通道的用户排除在外。约 8% 的男性有某种色觉缺陷，色盲友好不是边缘需求；而对比度不足、没有文本替代、无法键盘操作，同样会把低视力用户、屏幕阅读器用户、以及只能在强光下看手机的用户挡在门外。

难点在于可访问性与视觉表现力之间的张力。色盲友好色板的选择空间比「好看」的色板小得多，冗余编码会增加视觉噪声，文本替代需要额外维护。多数团队的做法是牺牲可访问性换美观——这恰恰是错的：可访问性做对了，图表对所有人都更清晰，包括色觉正常的人。

本文按「障碍类型 → 配色 → 冗余编码 → 语义替代 → 交互 → 测试」的顺序展开。关于色彩感知的底层原理（明度、色相、对比的感知机制）已在 视觉编码与感知原理 中详述，本文聚焦可访问性的具体约束与实现手段，不重复感知科学的基础内容。

目录

1. 四类障碍与可访问性基线
2. 色觉缺陷的类型与人群比例
3. 色盲友好的分类色板
4. 对比度与 WCAG 标准
5. 连续色阶：viridis 与单色相
6. 冗余编码：不靠颜色也能读懂
7. 纹理、形状与直接标注
8. ARIA、语义化与数据表替代
9. 键盘导航与焦点管理
10. 深色模式与高对比模式
11. 国际化、字体与本地化
12. 可访问性测试与工具链

1. 四类障碍与可访问性基线

可访问性要覆盖的障碍不止色盲，四类各有对应的设计约束：

合规基线是 WCAG 2.2 的 AA 级。与可视化最相关的三条：1.4.3 对比度（正文文本至少 4.5:1，大文本 3:1）、1.4.11 非文本对比（图表元素与背景至少 3:1）、1.1.1 非文本内容（图形需要有等价的文本替代）。这三条是所有图表的最低门槛。

一个常见的误解是「可访问性只对残障用户有意义」。实际上：高对比度让图表在投影仪、强光下都更清晰；冗余编码让图表在黑白打印时仍然可读；文本替代让图表能被搜索引擎与 AI 索引。这些收益对所有用户成立。把可访问性当作「额外负担」的团队，往往也在做一批经不起黑白打印的脆弱图表。

2. 色觉缺陷的类型与人群比例

色觉缺陷源于视网膜视锥细胞的感光色素缺失或变异。三种视锥分别对长（L）、中（M）、短（S）波敏感，对应红、绿、蓝三色。

红绿色盲（红/绿两类合计）占绝大多数。对可视化的直接影响是：任何用红绿区分正负、用红黄绿表示告警级别的设计，都会把约 8% 的男性用户排除。红绿在色觉缺陷者眼中可能都是黄褐色，亮度接近时完全无法区分。

关键洞察是「色相难分，但明度可分」。红色盲者看红色偏暗、绿色偏亮，所以只要保证配色在明度上有差异，即使色相不可分辨，图形仍可区分。这是色盲友好配色的核心原则：不要只靠色相区分，要让每个颜色在明度上也拉开差距。

# 用相对亮度判断两色是否在明度上可分
def rel_luminance(rgb):
    def channel(c):
        c = c / 255
        return c / 12.92 if c <= 0.03928 else ((c + 0.055) / 1.055) ** 2.4
    r, g, b = (channel(x) for x in rgb)
    return 0.2126 * r + 0.7152 * g + 0.0722 * b

def contrast_ratio(c1, c2):
    l1, l2 = sorted([rel_luminance(c1), rel_luminance(c2)], reverse=True)
    return (l1 + 0.05) / (l2 + 0.05)

3. 色盲友好的分类色板

分类色板（categorical palette）用于区分无序类别。设计规则有四条。

规则一：控制在 6 色以内。超过 6 个类别时，任何色板都难以保证两两可分，此时应改用冗余编码（直接标注、小倍数图、形状区分）而非继续加颜色。

规则二：色相与明度双重区分。经典的 Okabe-Ito 色板是公认的色盲友好方案，8 色在明度上均匀分布：

// Okabe-Ito 色盲友好色板（含明度差异）
const okabeIto = [
  '#0072B2',  // 蓝
  '#E69F00',  // 橙
  '#009E73',  // 青绿
  '#CC79A7',  // 品红
  '#D55E00',  // 朱红
  '#56B4E9',  // 天蓝
  '#F0E442',  // 黄
  '#000000',  // 黑
];

规则三：避免红绿对、避免纯色相差异。红-绿、绿-棕、蓝-紫都是高危组合。若业务语义必须用红绿（如涨跌），则必须叠加形状或标注。

规则四：在灰度下验证。把色板转成灰度，若相邻色仍能区分，则对色觉缺陷者基本可用。这是最快速的检验方法：

# 用 ImageMagick 把图表转灰度，检查是否仍可区分
magick chart.png -colorspace Gray -separate -average chart-gray.png

别用「色盲模拟」代替设计。模拟工具（如 Chrome DevTools 的 Rendering 面板可模拟 protanopia/deuteranopia/tritanopia）用来验证，不是用来设计——先按明度原则设计，再用模拟器检查盲区。

4. 对比度与 WCAG 标准

对比度是 WCAG 的硬指标，计算公式基于相对亮度：

对比度 = (L1 + 0.05) / (L2 + 0.05)
其中 L 为相对亮度，L1 为较亮者

要求分三档：正文文本 4.5:1（AA）、大文本（≥18pt 或 ≥14pt 粗体）3:1、非文本图形元素 3:1（AA）。图表里的坐标轴标签、图例文字、数据标签都算文本，必须满足 4.5:1；线条、柱子、边界等图形元素满足 3:1。

常见违规：浅灰的网格线与轴标签（#cccccc 对白底只有约 1.6:1）、浅色的图例文字、半透明的 tooltip 背景。网格线可以低对比（它属于辅助元素，非文本对比要求不强制），但轴标签必须达标——它是读图的必需信息。

// 校验一组配色对白底的对比度
const pairs = [
  { name: '轴标签', fg: '#666666', bg: '#ffffff' },
  { name: '主文字', fg: '#1a1a1a', bg: '#ffffff' },
  { name: '线色-蓝', fg: '#0072B2', bg: '#ffffff' },
  { name: '线色-黄', fg: '#F0E442', bg: '#ffffff' },   // 危险：黄对白底约 1.3:1
];
for (const p of pairs) {
  const ratio = contrastRatio(hexToRgb(p.fg), hexToRgb(p.bg));
  console.log(p.name, ratio.toFixed(2), ratio >= 4.5 ? 'AA' : ratio >= 3 ? '图形级' : '不合格');
}

亮黄色是最典型的陷阱：它在深色背景上清晰，在白色背景上几乎不可见（对比度约 1.3:1）。任何色板都要针对具体的背景色验证，不能脱离背景谈「好看」。

5. 连续色阶：viridis 与单色相

连续色阶（sequential）用于编码连续量。三类色阶的可访问性差异极大。

彩虹色阶（jet/rainbow）是明确的反模式。它的明度非单调——从蓝到青明度上升、到黄达到峰值、再到红又下降——这会在数据中产生并不存在的边界（如青色与黄色之间看起来像有一条分界），且对色觉缺陷者完全不可读。唯一适用场景是「需要离散分辨」的地形/热力伪彩，且必须配等值线。

感知均匀色阶是正解。viridis、magma、inferno、plasma、cividis 都是为感知均匀设计的——相同的数据差值对应相同的视觉差异，且明度单调递增，因此在灰度与色盲模拟下都保持可读。

import { interpolateViridis, interpolateCividis, interpolateBlues } from 'd3-scale-chromatic';

const color = scaleSequential(interpolateViridis).domain([0, maxValue]);
// cividis 专为色觉缺陷优化，是 deuteranopia 下表现最好的方案
const colorBlindSafe = scaleSequential(interpolateCividis).domain([0, maxValue]);

发散色阶（diverging）用于有中心点的数据（如增长率相对 0、温差相对基准）。它必须以中性色为中心、两端对称，且中性色要在明度上是极值（通常是浅灰或白）。RdBu、BrBG 是常用方案，但红-蓝发散对红绿色盲者仍可读（红蓝可分辨），而红-绿发散则不可用。

单色相渐变（如从浅蓝到深蓝）是最保守也最安全的选择——它天然明度单调，色觉缺陷下完全可读，只是色相区分度低（不适合叠加多个系列）。

6. 冗余编码：不靠颜色也能读懂

冗余编码（redundant encoding）是可访问性的第一原则：同一信息用两个以上的视觉通道表达，任一通道失效时其余仍能传递信息。

// 颜色 + 形状 + 线型三重编码，任一失效仍可区分
const series = [
  { name: '华东', color: '#0072B2', symbol: 'circle',   dash: 'solid' },
  { name: '华南', color: '#E69F00', symbol: 'square',   dash: 'dashed' },
  { name: '华北', color: '#009E73', symbol: 'triangle', dash: 'dotted' },
];

三种冗余手段。形状：散点图用不同 symbol（圆、方、三角、菱形），折线图用不同数据点符号。线型：实线、虚线、点线，对折线图特别有效。直接标注：把系列名标在线的末端或柱子旁，彻底摆脱图例与颜色的依赖——这是最彻底也最推荐的方案，因为它让读者不必在颜色与图例之间来回对照。

直接标注的额外收益是降低了认知负荷：读者不需要「先看图例找颜色，再回图里找对应线」的两步操作，而是一眼看到标签。这与 数据可视化原理与图表选型 里「减少图例往返」的结论一致。

热力图与地图的冗余编码更棘手。连续色阶加数字标注（在格子内显示数值）是标准做法，但格子小时数字放不下。此时可提供数值表格替代（见第 8 节）或支持悬浮读数。

图例与直接标注的取舍也值得权衡。图例的优势是省空间、适合系列多的情况；直接标注的优势是不依赖颜色记忆、可访问性更好。经验规则是：系列 ≤4 个时优先直接标注，系列多到标注会重叠时退回图例，并保证图例项本身可访问（可聚焦、可点击切换、有对比度达标的文字）。两者的组合是常见折中：主要系列直接标注，次要系列用图例收纳。

冗余编码还有一个隐性成本——增加了视觉元素。三重编码（颜色 + 形状 + 线型）在系列只有两三条时完全没问题，但系列到七八个时，形状与线型的组合空间会被用尽（可区分的符号与线型各只有几种），且视觉噪声上升。这也是「分类色板控制在 6 色以内」的另一个理由：超过这个数量，冗余编码本身也会失效，此时正确的做法是拆分图表或改用小倍数图。

7. 纹理、形状与直接标注

纹理填充（pattern fill）是色盲友好的另一条路径：用斜线、点阵、网格等纹理区分区域，颜色只是辅助。

<svg>
  <defs>
    <pattern id="diagonal" width="8" height="8" patternTransform="rotate(45)"
             patternUnits="userSpaceOnUse">
      <line x1="0" y1="0" x2="0" y2="8" stroke="#0072B2" stroke-width="2" />
    </pattern>
    <pattern id="dots" width="8" height="8" patternUnits="userSpaceOnUse">
      <circle cx="4" cy="4" r="2" fill="#E69F00" />
    </pattern>
  </defs>
  <rect x="0" y="0" width="100" height="80" fill="url(#diagonal)" />
  <rect x="110" y="0" width="100" height="80" fill="url(#dots)" />
</svg>

纹理的代价是视觉噪声。它适合面积图、地图、柱状图这类大块填充，不适合折线与散点（线条上叠纹理不可读）。纹理密度要控制——过密会让色块看起来像灰色。

直接标注是把系列名或数值标在图形元素旁边，不依赖图例。折线图在线末端标注、柱状图在柱顶标注、饼图在扇区上标注。标注位置要避免重叠——这在自动布局里是个难点，简单场景可以手工指定，复杂场景需要碰撞检测。

对于小屏幕与移动端，直接标注比图例更实用：图例占据垂直空间，而移动端空间本就紧张。把标注压在线上，是空间利用率最高的方案。

8. ARIA、语义化与数据表替代

屏幕阅读器读不到 Canvas。Canvas 是位图，内部没有任何可访问的 DOM 结构。SVG 稍好——它的图形是 DOM 节点，但若不加语义，读屏软件只会念出一串无意义的 path。因此图表必须提供等价的文本/表格替代。

最低要求是给图表容器一个描述性的 aria-label 与 role：

<figure role="group" aria-labelledby="chart-title" aria-describedby="chart-desc">
  <h3 id="chart-title">2026 年各区域销售额</h3>
  <div id="chart-canvas" role="img"
       aria-label="柱状图：华东 1284 万居首，华南 962 万，华北 741 万，西南 508 万"></div>
  <figcaption id="chart-desc">
    华东地区销售额最高，达 1284 万元，是西南地区的 2.5 倍。
  </figcaption>
</figure>

aria-label 要包含关键结论而非罗列所有数据——读屏用户听完一长串数字也无法形成洞察。更好的做法是提供一个可展开的 <table> 作为完整替代：

<details>
  <summary>查看数据表</summary>
  <table>
    <caption>2026 年各区域销售额（万元）</caption>
    <thead><tr><th scope="col">区域</th><th scope="col">销售额</th></tr></thead>
    <tbody>
      <tr><th scope="row">华东</th><td>1284</td></tr>
      <tr><th scope="row">华南</th><td>962</td></tr>
    </tbody>
  </table>
</details>

表格替代是一举多得的设计：它满足可访问性要求，也让需要精确数值的用户（而图表只给近似）能拿到数据，还改善了 SEO。把表格默认折叠（<details>）以免视觉用户被干扰。

9. 键盘导航与焦点管理

交互式图表（可下钻、可筛选、可框选）必须支持键盘操作。

三条规则。其一，所有可交互元素可 Tab 到达。筛选器、图例项、数据点若可点击，就要可聚焦。其二，焦点可见。outline: none 而不用替代样式是明确的可访问性缺陷——焦点样式可以用 :focus-visible 只对键盘用户显示。

/* 只对键盘导航显示焦点环，鼠标点击不显示 */
.chart-legend-item:focus-visible {
  outline: 2px solid #2f6fed;
  outline-offset: 2px;
}

其三，方向键导航数据点。对可聚焦的数据系列，用左右方向键在数据点间移动，配合 aria-live 播报当前点的值：

let cursor = 0;
svg.addEventListener('keydown', (e) => {
  if (e.key === 'ArrowRight') cursor = Math.min(cursor + 1, data.length - 1);
  if (e.key === 'ArrowLeft') cursor = Math.max(cursor - 1, 0);
  announce(`${data[cursor].label}: ${data[cursor].value}`);
});
function announce(text) {
  const live = document.getElementById('sr-live');
  live.textContent = '';                 // 清空以强制重新播报
  requestAnimationFrame(() => { live.textContent = text; });
}

aria-live="polite" 的隐藏区域是播报动态变化的常用手段。清空再设置是为了让相同内容也能触发播报——否则屏幕阅读器会忽略未变化的内容。

焦点顺序要与视觉顺序一致。若图例在视觉上位于图表上方，但 DOM 顺序里排在 canvas 之后，键盘用户的 Tab 顺序就会与视觉阅读顺序冲突。DOM 顺序决定焦点顺序，CSS 只应调整视觉呈现，不要用 order 或绝对定位制造「视觉顺序与 DOM 顺序不一致」的布局。

触控目标尺寸同样属于可访问性范畴：WCAG 2.2 的 2.5.8 要求触控目标至少 24×24 CSS 像素（AAA 建议 44×44）。图表里的图例项、数据点、下钻按钮在移动端往往小于这个尺寸，导致误触——这与 仪表盘与数据大屏设计 里移动端「触控目标 44px」的要求一致。

10. 深色模式与高对比模式

深色模式不是把浅色主题反相，配色需要重新设计。

问题一，饱和度。浅色背景上的高饱和色搬到深色背景会显得刺眼（同时对比效应），应降低饱和度、提高明度。问题二，对比度方向。深色背景上的文字要满足 4.5:1 同样需要验证，#ffffff 对纯黑是 21:1（过高，反而刺眼），通常用 #e0e0e0 级别的浅灰。

// 同一色板在浅色/深色主题下的两套值
const palette = {
  light: { bg: '#ffffff', fg: '#1a1a1a', series: ['#0072B2', '#E69F00', '#009E73'] },
  dark:  { bg: '#1a1a1a', fg: '#e0e0e0', series: ['#4DA3D6', '#F0B429', '#34C08A'] },
};

问题三，系统级高对比模式。Windows 高对比模式与 prefers-contrast: more 媒体查询会让用户覆盖颜色。图表应通过 CSS 变量响应这些偏好，而不是把颜色写死在 canvas 里——Canvas 绘制的内容无法被系统高对比模式覆盖，这是 Canvas 相对 SVG 的又一劣势。

@media (prefers-color-scheme: dark) { :root { --chart-bg: #1a1a1a; } }
@media (prefers-contrast: more) { :root { --chart-grid: #000; --chart-axis: #000; } }
@media (prefers-reduced-motion: reduce) { .chart * { animation: none !important; transition: none !important; } }

prefers-reduced-motion 必须尊重：前庭功能障碍用户会因动画不适。实时图表的持续动画尤其要在这个偏好下关闭。

11. 国际化、字体与本地化

可访问性延伸到语言与字体层面。

字体：中文图表要用包含完整字形的字体族（"PingFang SC"、"Microsoft YaHei"、"Noto Sans SC"），否则会出现方框（tofu）。衬线字体在小字号下可读性差，图表标签用无衬线。字号下限：轴标签 11px、正文 12px、移动端不低于 12px。

.chart { font-family: "Inter", "PingFang SC", "Microsoft YaHei", "Noto Sans SC", sans-serif; }

数字格式：千分位、小数点、货币符号因地区而异。用 Intl.NumberFormat 而非手写格式化：

new Intl.NumberFormat('zh-CN', { style: 'currency', currency: 'CNY' }).format(1284000);
// "¥1,284,000.00"
new Intl.NumberFormat('de-DE').format(1284000);   // "1.284.000"

时间与日历：月/日顺序、周起始日、甚至日历系统（如农历、佛历）都不同。文本方向：阿拉伯语、希伯来语是 RTL，图表布局需要镜像——轴的位置、图例的方向都要翻转。这需要用 CSS 逻辑属性（margin-inline-start 而非 margin-left）。

颜色语义的文化差异同样要注意：红色在西方表示「危险/下跌」，在中国股市表示「上涨」。不要硬编码颜色语义，把它作为可配置项。这与 仪表盘与数据大屏设计 里「语义色按业务含义而非数值方向着色」的结论一致。

12. 可访问性测试与工具链

可访问性必须进 CI，否则必然退化。

自动化工具：axe-core 能检测对比度、ARIA 属性、标签缺失等约 30% 的问题；Lighthouse 的 Accessibility 审计基于 axe；pa11y 可集成进 CI。它们检测不到的是语义质量——aria-label 内容是否准确、冗余编码是否到位，这些仍需人工。

# CI 里跑 axe 审计
npm i -D @axe-core/cli
npx axe https://example.com/dashboard --exit    # 有问题时非零退出

手动测试清单：

1. 把图表转灰度，是否仍可区分所有系列？
2. 用色盲模拟器（Chrome DevTools Rendering 面板）检查三类色盲。
3. 只用键盘能否完成所有交互（Tab、方向键、Enter）？
4. 打开屏幕阅读器（VoiceOver/NVDA）能否获得关键结论？
5. 浏览器缩放到 200% 时布局是否可用？
6. 强制高对比模式与 prefers-reduced-motion 下是否正常？

把可访问性纳入设计评审：在设计稿阶段就用灰度截图与色盲模拟过一遍，比开发完再返工成本低得多。这与仪表盘设计评审的「五秒测试」思路一致——用真实用户的视角检验，而非设计者的自我感觉。

权衡取舍

常见坑清单

1. 只用色相区分系列——红绿色盲无法分辨；叠加形状、线型或直接标注。
2. 彩虹色阶编码连续量——明度非单调制造虚假边界；改 viridis 或单色相。
3. 浅灰轴标签对白底——对比度不足 4.5:1，低视力用户读不到；加深到至少 4.5:1。
4. 亮黄色画在白底上——对比度约 1.3:1 几乎不可见；色板必须针对具体背景验证。
5. Canvas 无文本替代——读屏软件读不到任何内容；补 aria-label 与数据表。
6. outline: none 去掉焦点环——键盘用户失去位置感；用 :focus-visible 保留。
7. 深色模式直接反相——高饱和色刺眼、对比失衡；单独设计深色色板并验证。
8. 忽略 prefers-reduced-motion——前庭障碍用户不适；该偏好下关闭动画。
9. 硬编码货币/时间格式——跨地区显示错误；用 Intl API 本地化。
10. 硬编码颜色语义——红涨绿跌在中西方相反；把语义色做成可配置。

小结

可视化可访问性的核心是**「不依赖单一通道」**：颜色不可辨时靠形状与标注，图形不可见时靠文本与表格，鼠标不可用时靠键盘。这条原则下，色盲友好色板、冗余编码、数据表替代、键盘导航都是它的具体落实，而不是各自独立的合规项。

配色层面最关键的判断是明度优先：分类色板让每个颜色在明度上分层，连续色阶选明度单调的感知均匀方案（viridis、cividis），发散色阶用中性色居中。做到这一点，色觉缺陷用户的可用性自然成立，同时所有用户的读图体验都更清晰。

下一步可以回到视觉编码与感知原理，理解这些规则背后的感知机制；或在仪表盘与数据大屏设计里看语义色与主题系统如何落地；图表选型阶段的通道选择原则同样决定了可访问性的上限。