STATUS IS UP网站优化 Wiki
13启用
设计与用户体验 / 启用

深色模式的可访问性:对比、选择与测试

将深色模式作为经过测试的界面选项来实现:在发布前保持可读对比、可见焦点、可用图像、原生控件和用户覆盖选项。

深色模式的可访问性:对比、选择与测试 — 可视化指南
阅读
8 分钟
来源
8
重新验证
2027-03-27
已审阅
兼顾可访问性意识的前端审查者并负责发布管理
简短回答

从决策开始。

把深色模式实现为完整主题,而不是颜色反转。为每一个有意义的表面和状态定义语义颜色令牌(token),使用操作系统偏好作为初始主题,并在产品需要时提供可访问的手动选择。在用户阅读、登录、搜索、提交表单和购买的页面上测试两种主题。只有当关键交互仍然可感知且可操作时,主题才算就绪。

作为基于 WCAG 的基线,普通文本和作为文本的图像需要至少 4.5:1 的对比度;大号文本可以使用 3:1。可识别的控件、必需状态和有意义的图形需要相对于相邻颜色达到 3:1。保持键盘焦点可见,声明兼容的浏览器配色方案,并检查 forced-colors 模式。自动化检查能找到候选问题,但必须由人工在真实流程中执行验证。

可视化指南

把工作看作一个系统。

使用此地图在执行具体策略前将文章中的决策联系起来。

SIU启用
01从用户选择与令牌系统开始
02在渲染后的主题中测量对比度
03保护键盘焦点、表单和状态更改
04处理图像、嵌入资产与浏览器提供的 UI
01

从用户选择与令牌系统开始

使用 prefers-color-scheme 将系统设置作为默认。如果提供切换开关,使用可键盘操作的控件并带有可访问名称,同时以编程方式公开当前激活的选择。在该浏览器上下文中,让手动选择具有优先权;不要承诺它会跟随用户到另一台设备或私密会话。

按角色命名颜色,而非外观:画布(canvas)、表面(surface)、文本(text)、次要文本(muted text)、边框(border)、链接(link)、重色/强调(accent)、错误(error)、成功(success)、焦点(focus)和禁用(disabled)。在两种主题中映射每个角色。这可防止仅为明亮主题设置的灰色渗入深色模式,并使修复可复用。深色并非天然更具无障碍性或人人偏好;它只是另一种需要保证可用性的体验。

主题优先级

记录一个顺序,例如先是已保存的选择,其次是系统偏好,这样团队就能测试出相同结果。

组件清单

包含 hover、focus、selected、invalid、disabled、loading、empty 和 visited-link 等状态,而不仅是默认状态。

02

在渲染后的主题中测量对比度

WCAG 2.2 Success Criterion 1.4.3 将普通文本和作为文本的图像的最低对比度定为 4.5:1,大号文本为 3:1。不要四舍五入:4.499:1 不满足 4.5:1。细体在视觉上可能比其计算颜色显得弱,因此使用更厚实的字重或额外的间距。

检查每个渲染后的前景色与相邻背景色。文本叠加在照片、渐变、半透明面板或视频上时背景会变化,单一令牌计算无法证明其可读性。使用不透明后备、足够的覆盖层或不同的布局位置,然后在真实视口下检查。

控件与图形

根据 WCAG 2.1 Success Criterion 1.4.11,识别活动控件、必需状态或有意义图形所需的视觉信息相对于相邻颜色需要达到 3:1。

不仅仅是色相

配合颜色变化使用文本、图标、图案、位置或其他明确提示;错误和已选状态不应依赖细微的色调差异来传达。

03

保护键盘焦点、表单和状态更改

在两种主题中通过 Tab 遍历。焦点必须在链接、按钮、输入框、菜单、对话框、自定义控件和主题切换控件上可见。除非在每个表面和状态上都已测试替代方案,否则不要移除浏览器的 outline。偏移的边框(offset outline)通常比模糊的光晕更清晰。

WCAG 2.2 中的 Focus Appearance 是 AAA 级别的准则,不代表站点达到 AA。它是一个有用的目标:指示区域至少与 2 CSS 像素周长等大,并且聚焦与未聚焦像素之间有 3:1 的对比。此外还要验证错误、必填、已选和不可用状态保留其含义。

表单检查

分别测试输入提示、已输入值、标签、帮助文本、错误文本、无效边框、复选框标记、单选选择和提交状态。

支付与敏感流程

对于结账或其他受监管流程,使用支付提供商的沙箱并在适当情况下取得合格的无障碍和安全评审。该段是教育性建议,不构成合规或安全评估。

04

处理图像、嵌入资产与浏览器提供的 UI

在两种主题中检查徽标、插图、截图、图表、图标和烘焙在图像中的文本。重复使用的明亮徽标可能会在深色模式下消失,图表图例即使周围 HTML 合格也可能失败。提供与用途匹配的资源或稳定背景。传达说明、状态或数据的图像必须保持可理解性。

声明对浅色和深色方案的支持,然后为所选主题样式化页面内容。color-scheme 属性能使浏览器的画布、滚动条、表单控件和其他浏览器 UI 与主题对齐。将相应的元数据尽早放在文档中。嵌入的 SVG 可以响应父方案;对第三方 iframe 和小部件端到端地进行测试。

优先使用原生控件

偏好语义化的 HTML 控件。forced-color 行为依赖原生语义,而不是向通用元素添加 ARIA 角色来伪造语义。

资产验收

检查已下载、已缓存、加载缓慢和加载失败的图像状态,尤其是文本或操作提示位于媒体之上时。

05

尊重 forced-colors 并将发布作为一个系统来测试

forced-colors 模式应用有限的用户选择调色板,例如 Windows High Contrast。浏览器可能替换颜色、移除阴影并添加文本背板(backplates)。不要阻止用户覆盖。对在组件中失去边界或含义的情况做有针对性的修复,例如用真实边框替代曾由阴影承担的可用性提示。仿真无法代表所有设备、浏览器、扩展、缩放级别或辅助技术组合。

在发布前在浅色、深色和 forced-colors 设置下运行路由与交互矩阵。Chrome DevTools 可以模拟这两种情况;使用它来加速审查,然后手工导航优先流程。扫描器能发现候选问题但不能单独确定可访问性。SIU 对关键主题资产和交互做预检、记录发布门槛,并保留经过测试的回滚路径以应对严重的呈现回归;这不是停机监测。

覆盖矩阵

包含着陆页、导航、搜索、账户访问、表单、错误页、已认证屏幕和材料转换流程等。

发布证据

保存已测试的 URL、浏览器版本、设置、例外、负责人和回滚触发条件,以便从事实出发启动修复工作。

行动 / 验证

你的实用待办指南。

  1. 01

    列出承载主题的表面清单

    列出共享组件和关键路线,包括交互和验证状态。

    验证: 每一项都有明亮和深色的负责人或被明确废弃。
  2. 02

    定义语义令牌

    将文本、表面、链接、边框、错误和焦点等角色在两种主题中映射为具体数值。

    验证: 无生产组件依赖未经说明的仅适用于明亮主题的字面颜色。
  3. 03

    设定可预测的主题优先级

    将系统偏好作为默认,并在提供时让手动选择可访问且一致地应用。

    验证: 有文档化的测试展示系统亮色、系统暗色与每种手动选择的预期结果。
  4. 04

    检查文本与 UI 对比度

    测量每个主题中的渲染文本、控件、状态标记和有意义图形的对比度。

    验证: 普通文本达到 4.5:1,适用 WCAG 条件时大号文本与必需的非文本视觉信息达到 3:1。
  5. 05

    键盘测试焦点与表单

    使用 Tab、Shift+Tab、Enter、Space 和 Escape 按需导航所有优先流程。

    验证: 在两种主题中焦点位置、错误提示、选择与提交结果保持可见且可理解。
  6. 06

    检查媒体与原生控件

    检查图像资产、嵌入内容、滚动条、输入以及可用时的自动填充相关呈现。

    验证: 没有关键标签、图例、操作或原生控件与其渲染背景冲突。
  7. 07

    执行 forced-colors 模式

    模拟 forced-colors 并仅对失去可用性或含义的元素做有针对性的回退。

    验证: 关键控件仍有可识别的边界或标签,键盘焦点仍然明显。
  8. 08

    结合自动化与人工检查

    运行对比或无障碍工具,然后手动审查工具无法判断的任务路径。

    验证: 发现项经人工决策分级;工具输出不得作为合规结论。
  9. 09

    为发布设定门槛并准备修复

    记录已测试的构建、优先 URL、例外、负责人和可逆的部署或回滚选项。

    验证: 团队能识别已知良好的主题构建与触发回滚的条件。
讨论主题

比较各种权衡,而不是私有数据。

与团队或网站所有者社区一起使用这些提示。共享方法与经验,但切勿粘贴凭证、客户记录或非公开的基础设施细节。

  1. 01

    哪个组件暴露了最令人意外的亮色与暗色差异,你如何将其加入发布检查?

  2. 02

    当品牌色板变化时,你的设计师和开发者如何保持令牌、组件状态与图片资源的一致性?

  3. 03

    哪些轻量级的发布证据能帮助团队在不共享客户或账户数据的情况下解决主题回归?

热门 / 权威资源

打开来源材料。

W3C Web Accessibility InitiativeUnderstanding Success Criterion 1.4.3: Contrast (Minimum) ↗

解释 WCAG 的文本对比阈值、例外和测量注意事项。

已审阅 2026-09-27
W3C Web Accessibility InitiativeUnderstanding Success Criterion 1.4.11: Non-text Contrast ↗

用于评估控件、状态指示器和有意义图形的对比情况。

已审阅 2026-09-27
W3C Web Accessibility InitiativeUnderstanding Success Criterion 2.4.13: Focus Appearance ↗

提供本文作为设计目标引用的 AAA 级焦点尺寸与对比模型。

已审阅 2026-09-27
MDN Web Docsprefers-color-scheme CSS media feature ↗

展示浏览器如何公开用户请求的浅色或深色主题以及嵌入 SVG 的行为。

已审阅 2026-09-27
MDN Web Docscolor-scheme CSS property ↗

解释浏览器画布、原生控件、滚动条与相关 UI 的协调方式。

已审阅 2026-09-27
MDN Web Docsforced-colors CSS media feature ↗

详述浏览器覆盖、系统色、阴影、背板与作者可控的限制。

已审阅 2026-09-27
Chrome for DevelopersEmulate CSS media features ↗

提供在 DevTools 中演练浅色、暗色与 forced-colors 条件的步骤。

已审阅 2026-09-27
W3C Web Accessibility InitiativeEvaluating Web Accessibility Overview ↗

解释为何人工审核补充自动化无障碍工具的检测结果。

已审阅 2026-09-27

来源政策。 本文基于发布时读取的 W3C、MDN 和 Chrome 文档。WCAG 引用说明技术性准则,而非法律建议或认证。请在部署的体验中重新检查浏览器行为和辅助技术的结果。

快速说明

常见问题。

添加深色模式会自动让网站更具可访问性吗?

不会。深色模式可能会提高部分人的舒适度,但也可能引入不可读的文本、不可见的焦点和不清晰的状态。把它当作一个完整且独立测试的主题,而不是无障碍的捷径。

4.5:1 是深色模式所需的唯一对比度检查吗?

不是。4.5:1 的 WCAG 阈值适用于普通文本和作为文本的图像。大号文本的阈值为 3:1,而必需控件与有意义图形也需要相对于相邻颜色达到 3:1。焦点、图像和非颜色提示仍需检查。

每个网站都应该提供深色模式切换吗?

将系统偏好作为默认是一个实际的基线。手动切换在访客需要覆盖默认或返回所选主题时很有用,但它必须是可访问的、可预测的并经过测试。它是产品决策,而非本身就能证明无障碍合规。

Status Is UP Editorial Team · 可用性与运行时使能编辑团队

由 兼顾可访问性意识的前端审查者并负责发布管理 审阅。发布于 2026-09-27;更新于 2026-09-30。