动态内容对比度必须渲染后实时验证，WCAG要求所有JS插入、AJAX加载、表单反馈等状态下的文本与背景组合≥4.5:1，否则视障用户会瞬间失读；需用MutationObserver监听新增节点，结合getComputedStyle与WCAG亮度公式计算，并覆盖伪元素、第三方SDK、暗黑模式等易漏场景。
动态内容的对比度必须在渲染后实时验证，不能只验初始 HTML；WCAG 要求所有状态（包括 JS 插入、AJAX 加载、表单反馈）下的文本与背景组合都 ≥ 4.5:1，否则视障用户会瞬间失读。
动态插入文案的对比度怎么测
浏览器 DevTools 的颜色拾取器只能测静态样式，对 JS 动态插入的内容（如 document.createElement("p") 后 append 的提示文字、innerHTML 注入的错误信息）无效。必须等 DOM 渲染完成后再测：
- 用
setTimeout(() => { /* 测色逻辑 */ }, 0)或MutationObserver监听新增节点 - 对每个新插入的文本节点，用
window.getComputedStyle(el).color和window.getComputedStyle(el.parentElement).backgroundColor获取实际色值 - 调用 WebAIM Contrast Checker 的 API 或本地实现 Luminance 计算（公式：L = 0.2126×R + 0.7152×G + 0.0722×B），再套用对比度公式 (L1 + 0.05) / (L2 + 0.05)
- 特别注意伪元素生成的内容：
::before里content: "⚠";若没设color，会继承父级，但可能被 CSS 继承链意外覆盖
第三方 SDK 注入内容的对比度风险
广告 banner、客服浮窗、埋点 SDK 自动插入的提示条，常使用默认浅灰文字（如 #999）配浅色背景（如 #f9f9f9），实测对比度仅约 2.3:1 —— 这类内容根本不在你写的 CSS 里，却直接违反 WCAG。
- 用 Chrome 的 Rendering 面板开启
Emulate vision deficiencies → grayscale，快速识别哪些动态区域“糊成一片” - 检查 Lighthouse 报告中的
color-contrast失败项，它会给出具体路径，例如#chat-widget > .message:last-child .text - 禁止依赖
color: currentColor或color: inherit渲染第三方内容，必须显式重置：#third-party-container * { color: #333 !important; background-color: #fff !important; } - 若无法控制第三方样式，用
filter: contrast(1.3)强制提升，但需加isolation: isolate防止父层叠上下文截断
暗黑模式下动态内容的对比度翻车点
很多人只改了 body 背景色，却忘了动态插入的 toast、tooltip、validation message 仍用原亮色模式的深色文字，在深背景上直接不可读。
立即学习“前端免费学习笔记（深入）”；
- 监听
prefers-color-scheme变化时，不仅要更新 CSS 变量，还要遍历所有已存在的动态节点并重设color - 避免写死
color: #333，改用 CSS 变量：color: var(--text-primary);，并在@media (prefers-color-scheme: dark)中定义--text-primary: #e0e0e0; - 表单错误提示最危险：
.error-message在亮色模式用#d32f2f，切换暗色模式后必须同步改为#ff8a80并验证其与深背景的对比度（至少 4.5:1） - Canvas 动态绘制的文字也得响应主题：
ctx.fillStyle = getComputedStyle(document.documentElement).getPropertyValue('--text-primary');
真正难的不是写对一行 color，而是确保每次 appendChild、insertAdjacentHTML、textContent 更新后，对比度都仍在安全线之上——这需要把验证逻辑嵌进组件生命周期，而不是靠人工抽检。
