系统颜色关键字禁用——会导致文字消失、对比度失控且无障碍工具报错；应改用确定性颜色+媒体查询组合，并通过工具验证对比度。
不要用系统颜色关键字做无障碍适配——它们会让文字消失、对比度失控，且所有主流无障碍检测工具都会报错。
为什么ButtonFace和HighlightText在高对比度模式下不可靠
这些关键字看似能“跟随系统”，实际行为完全不可控：
- Chrome 把
ButtonText解析为深灰，Firefox 可能返回纯黑，Safari 在某些版本中直接忽略该值 - Windows 高对比主题下，
ButtonFace和ButtonText可能同时变黑 → 文字彻底不可见 - WCAG 要求对比度可验证，但你无法用 JavaScript 读取
ButtonFace的 RGB 值，也无法静态计算它与相邻色的比值 -
axe、WAVE、Lighthouse全部将含系统关键字的样式标记为 “contrast cannot be determined”
@media (forced-colors: active) 是唯一合法入口，但不是用来塞系统关键字的
这个媒体查询确实存在，但它只表示“用户启用了强制颜色模式”，不等于你可以放任 CanvasText 自由发挥：
- 必须配合
forced-color-adjust: none主动关闭浏览器对子元素的自动覆盖，否则你的color会被无视 - 只应在极少数原子级组件（如原生
<button>）中谨慎使用系统关键字，且必须做 fallback - 示例写法（非推荐，仅说明合规边界）：
@media (forced-colors: active) { .custom-button { forced-color-adjust: none; background-color: Canvas; color: ButtonText; } }
真正可行的替代路径：确定性颜色 + 媒体查询组合
放弃“让系统决定颜色”的幻想，转而用明确值响应可检测的偏好信号：
立即学习“前端免费学习笔记（深入）”；
- 用
@media (prefers-color-scheme: dark)切换--text-primary等 CSS 变量，而非依赖Window或Menu - 用
@media (prefers-contrast: high)单独提供高对比版本（如加粗边框、移除阴影、强制黑白），而不是指望GrayText会变亮 - 所有颜色对必须通过工具验证：比如用
calculateContrast()函数或 WebAIM Contrast Checker，确保isLargeText ? 3.0 : 4.5 - 语义化命名（如
--color-text-emphasis）比外观名（如--color-blue-600）更能支撑无障碍迭代
最常被忽略的一点：系统颜色关键字不是“过时技术”，而是设计系统里一个明确的禁用项。它的危险性不在于兼容性差，而在于它把对比度控制权交给了不可观测、不可测试、不可回滚的底层实现——这对需要稳定交付无障碍体验的产品来说，是不可接受的风险敞口。
