Tailwind 本身不自动提供高对比度无障碍样式，需配合 @ariakit/tailwind 插件、OKLCH 相对颜色及语义 token 才能实现“改一个变量，全系统自动满足 WCAG AAA 对比度”。
直接结论：Tailwind 本身不自动提供高对比度无障碍样式，但配合 @ariakit/tailwind 插件 + OKLCH 相对颜色 + 显式语义 token，才能真正实现「改一个变量，全系统自动满足 WCAG AAA 对比度」的效果。
为什么 tailwind.config.js 里配色 ≠ 高对比度保障
Tailwind 默认的 colors 配置（比如 blue-500: '#3b82f6'）只是静态色值，不感知文字大小、背景亮度或用户系统偏好。即使你手动挑了“看起来够深”的蓝色，text-blue-500 在 bg-gray-100 上的对比度可能只有 3.2:1 —— 不满足 WCAG AA（4.5:1）要求，更别说 AAA（7:1）。
常见错误现象：
- 暗色模式下按钮文字发灰、看不清
- disabled 状态用 opacity-50 后对比度跌破阈值
- 用 gray-400 做辅助文字，在浅底上实际只有 2.8:1
- WCAG 对比度计算依赖相对亮度（luminance），不是简单“深色+浅色”就能达标
- Tailwind v4 的 JIT 引擎不会主动校验或修正你的类组合是否合规
- 仅靠
dark:前缀切换色值，无法保证深色模式下文字与背景的对比度反向提升
用 @ariakit/tailwind 实现自动高对比度
它把颜色逻辑从“写死色值”变成“声明意图”，再由插件在 OKLCH 色彩空间里动态推导出符合对比度要求的派生色。
关键步骤：
立即学习“前端免费学习笔记（深入）”；
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
- 在
@theme中只定义语义基础色，比如--color-primary: #2563eb（不用管它在深/浅背景上是否够显眼） - 给容器加
ak-layer ak-layer-canvas类，插件会根据--color-canvas自动算出该层下所有文字、边框、焦点环的对比度安全色 - 所有文本用
ak-text，按钮用ak-button，它们内部已内置最小对比度逻辑（例如小号文字强制用更深的黑色） - 避免手动写
text-gray-700或bg-white—— 这些会绕过相对颜色链，导致对比度失控
示例：同一按钮在浅色/深色画布下，ak-button ak-button-primary 渲染出的边框、文字、悬停态，全部由插件实时计算，确保始终 ≥ 4.5:1（正文）或 ≥ 7:1（标题/小字）。
必须避开的三个兼容性坑
@ariakit/tailwind 依赖 Tailwind v4 的新机制，旧项目迁移时容易卡住：
-
@import "@ariakit/tailwind"必须放在@import "tailwindcss"之后，否则插件的 CSS 变量注入失败 - 若用 Vite，需确认
tailwind.config.js的content字段包含所有含ak-类的模板路径，否则 JIT 不编译这些工具类 - OKLCH 色彩函数（如
oklch(from var(--color-primary) l c h)）在 Safari 15.6+ 和 Chrome 112+ 才稳定支持；旧浏览器会回退到 HSL 计算，虽仍可用但对比度精度略降
验证是否生效：打开 DevTools → Elements → 查看元素 computed 样式中是否有 color: oklch(...) 或 background-color: oklch(...)。没有，说明插件未正确加载或主题变量未被识别。
最易被忽略的一点：相对颜色只在「声明了 ak-layer 的 DOM 子树内」生效。如果你在某个组件里漏掉了 ak-layer，哪怕只有一层嵌套没包住，里面所有 ak-text 都会退化成默认色，对比度立刻失效。
