AI 无障碍评审让界面被看见也能被读懂一、无障碍不是上线前的检查表前端无障碍常被放到项目末尾处理补几个aria-label调一下颜色对比跑一次扫描工具。但真正可用的无障碍体验应该从设计阶段开始。信息层级、交互顺序、键盘焦点、错误提示和动态反馈都需要提前规划。AI 可以帮助发现问题但不能替代设计和工程的基础意识。AI 无障碍评审的价值是把截图、DOM 结构和规则检查结果结合起来生成更容易理解的问题清单。比如它可以说明某个图标按钮没有可读名称某段浅色文字在当前背景下对比不足某个弹窗打开后焦点没有进入内容区。问题越具体修复越快。二、评审流程规则扫描和语义解释结合flowchart TD A[页面 DOM] -- B[自动规则扫描] C[页面截图] -- D[视觉语义分析] B -- E[AI 汇总] D -- E E -- F[问题清单] F -- G[研发修复] G -- H[键盘与读屏验证]规则扫描擅长发现确定性问题例如表单缺少 label、图片缺少 alt、按钮没有可访问名称、颜色对比低于标准。AI 擅长解释这些问题对用户意味着什么并识别规则工具不一定能判断的语义问题例如卡片层级混乱、错误提示离输入框太远、Toast 消失过快。输入给 AI 的内容要包含上下文。只给一张截图模型可能不知道哪个元素可点击只给 DOM又看不到视觉层级。更好的方式是提供截图、关键 DOM 片段、自动扫描结果和页面用途。这样 AI 才能生成可执行建议。三、代码示例图标按钮必须有可读名称下面示例展示一个常见修复只显示图标的按钮需要提供明确的可访问名称。import { Search } from lucide-react; export function SearchButton() { return ( button typebutton aria-label搜索订单 Search size{18} aria-hiddentrue / /button ); }aria-label不应写成“按钮”或“图标”。它要描述操作结果例如“搜索订单”“关闭弹窗”“清空筛选”。如果页面上有多个相同图标按钮还要区分上下文。可访问名称是读屏用户理解界面的入口不是为了通过扫描工具。焦点管理同样重要。弹窗打开时焦点应进入弹窗关闭时焦点应回到触发按钮键盘 Tab 不应跑到遮罩层背后的页面。AI 可以提醒焦点问题但实际验证仍需要键盘操作和读屏测试。四、落地策略把无障碍纳入组件库无障碍最好在组件库层面解决。按钮、输入框、弹窗、下拉菜单、Tabs、Toast、表格等基础组件都应内置语义、焦点和键盘交互。业务页面如果每次自己补无障碍质量很难稳定。设计规范中也要标注无障碍要求。颜色 Token 应提供对比检查表单组件应定义错误提示位置动效组件应支持减少动态效果图标使用应区分装饰图标和功能图标。AI 评审可以基于这些规范判断而不是每次重新解释。最后要建立抽样验证。自动扫描和 AI 评审能覆盖一部分问题但真实读屏体验仍需要人工测试。尤其是复杂表格、拖拽排序、分步表单和富文本编辑器应安排键盘和读屏路径验证。无障碍不是额外负担它是界面质量的一部分。五、总结AI 无障碍评审适合把规则扫描、截图语义和修复建议整合起来但无障碍质量仍依赖组件库、设计规范和人工验证。让界面被看见也要让它能被读懂、被操作、被理解。这才是前端体验的底线。