用现成框架比从零写无障碍更可靠，但必须关闭默认“美观优先”配置，显式启用或补全ARIA、键盘焦点、对比度三类支持；选框架时须查源码验证tabindex、role/aria属性、WCAG对比度值是否真实实现，而非仅看宣传文案。
直接说结论：用现成框架比从零写无障碍更可靠，但必须关闭默认“美观优先”配置，显式启用或补全ARIA、键盘焦点、对比度三类支持。
选框架时重点看这三处代码
不是看宣传页写的“支持无障碍”，而是查源码里是否真有这些实现：
-
tabindex是否被自动加到非button/a的交互元素上（比如div模拟的开关、下拉项） - 组件是否默认带
role和aria-属性（例如role="navigation"、aria-expanded） - 默认配色在
tailwind.config.js或variables.scss里是否标注了 WCAG 对比度值（如text-gray-900/bg-gray-100组合是否 ≥4.5:1）
比如 Foundation Sites 的 dropdown 组件源码里有 this.$element.attr('aria-haspopup', 'true')；而某些轻量框架只改样式，不加 ARIA，就得自己补。
Bootstrap 5 默认不满足 WCAG，必须手动关掉两个开关
它默认禁用了键盘焦点轮廓（outline: 0），且表单控件没绑定 label for —— 这俩直接让屏幕阅读器和键盘用户卡住。
立即学习“前端免费学习笔记（深入）”；
- 在
bootstrap/scss/_reboot.scss里注释掉*:focus { outline: 0 !important; } - 所有
<input>必须配id，对应<label for="xxx"></label>，不能只靠form-control类 - 用
aria-invalid="true"+aria-describedby替代纯 CSS 错误提示（比如.is-invalid只改颜色，没语义）
否则即使用了 Bootstrap，screen reader 读不出错误信息，Tab 键也跳过输入框。
Tailwind CSS 要配对用工具，光靠 class 名不够
text-blue-800 和 bg-white 看似对比高，但实际对比度可能只有 3.2:1（低于 WCAG AA 要求的 4.5:1）。不能凭感觉选。
- 用 WebAIM Contrast Checker 验证每组文字/背景色组合
- 在
tailwind.config.js的theme.extend.colors里，把验证过的高对比色单独定义为accessibleBlue等语义名，避免重复试错 - 禁用
text-sm+ 浅灰文字（如text-gray-400）组合——小字号+低对比是常见失败点
框架本身不替你做判断，它只提供原子类；真正合规靠的是你主动验证并约束使用方式。
最后检查：键盘用户能不能不用鼠标走完全流程
这是最硬的验收标准，比任何配置都重要。打开页面后：
- 按
Tab键，焦点是否依次落在所有可操作元素上（按钮、链接、输入框、自定义组件） - 按
Enter或Space是否能触发点击行为（尤其对div模拟的按钮） - 抽屉菜单打开后，焦点是否被限制在菜单内（用
focus trap），关闭后是否回到触发按钮
很多框架只管“看起来能点”，不管“键盘能不能点进去”，这点必须亲手测，不能信文档。
