Tailwind CSS 不自动提供无障碍表单组件，但可通过 focus-visible、ARIA 属性、语义 HTML 等构建 WCAG 2.1 合规表单；需避免 outline: none，确保 label 关联、错误态可读、原生控件增强而非替换，并全程键盘与屏幕阅读器验证。
直接说结论：Tailwind CSS 本身不自动提供无障碍表单组件，但通过正确组合状态前缀、语义 HTML 结构和 ARIA 属性，你能快速构建符合 WCAG 2.1 标准的表单控件 —— 关键不在“用什么类”，而在“怎么配”。
focus-visible 和 focus-within 怎么选？别让键盘用户看不到焦点
很多项目只写 focus:ring-2 focus:ring-blue-500，结果键盘 Tab 切换时焦点环在鼠标悬停后就消失了，违反 WCAG 2.4.7（焦点可见性）。focus-visible 才是现代做法。
- 用
focus-visible:ring-2 focus-visible:ring-blue-500 focus-visible:ring-offset-2替代裸focus:，它只在键盘导航时触发，不影响鼠标用户 -
focus-within适合包裹容器（如div class="relative focus-within:ring-2"），当内部 input 获焦时高亮整个字段组，提升可感知性 - 禁用
outline: none或focus:outline-none—— 它会彻底抹掉焦点样式，屏幕阅读器+键盘用户将无法定位当前控件
错误态必须带 aria-invalid 和 role="alert"
光靠 border-red-500 text-red-600 不够。视觉错误提示对屏幕阅读器不可见，用户可能完全不知道输入失败。
- 给 input 加
aria-invalid="true"（验证失败时动态设置），并确保aria-describedby指向错误消息 ID - 错误消息元素用
role="alert"+aria-live="polite"，保证变化能被读出 - 不要只改颜色 —— 同时加图标（如
text-red-500的 SVG）、边框粗细变化（border-2）、甚至轻微抖动动画（animate-shake）增强多感官反馈
label 和 input 怎么关联才真正无障碍？
用 for/id 关联是最基础也最容易漏的点。很多团队用 flex flex-col 布局后就以为“视觉对齐=语义正确”，其实不是。
立即学习“前端免费学习笔记（深入）”；
- 每个
input必须有唯一id，对应label的for属性；aria-labelledby是备选，非首选 - 复选框/单选按钮组必须用
fieldset+legend包裹，不能只靠div+h3 - 隐藏 label（如仅靠 placeholder 提示）是反模式 ——
placeholder不是 label，且在输入后消失，屏幕阅读器不会重复播报 - 若 UI 确实不能显示 visible label（如搜索框），至少用
aria-label或aria-labelledby补足
select、checkbox 这些“难搞”的原生控件怎么处理？
浏览器对 select、input[type="checkbox"] 的默认样式限制极多，强行覆盖易破坏无障碍支持。正确解法是“增强而非替换”。
-
select：用appearance-none移除默认箭头，但保留原生select元素本身 —— 不要用 div + ul 模拟，否则键盘无法操作、ARIA 不生效 - 自定义 checkbox/radio：用
sr-only隐藏原生控件，用伪元素或 SVG 绘制视觉层，但必须把checked、disabled、aria-checked等状态同步到 wrapper 上 - 文件上传控件：别隐藏
input[type="file"]后用 button 模拟 —— 至少保留它，并用sr-only+ 视觉 button +aria-controls关联 - 所有自定义控件都需手动实现
Enter/Space键激活、Tab导航、Arrow键切换等行为，否则只是“看起来像”
最常被忽略的点：无障碍不是加几个 class 就完事，而是要验证整个交互链路 —— 键盘能否完整操作？屏幕阅读器能否准确播报状态变化？错误是否在首次提交后立即可感知？建议每次加完表单组件，关掉显示器，纯靠键盘和 VoiceOver/NVDA 走一遍流程。
