AI 无障碍评审：让界面被看见，也能被读懂
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 type="button" aria-label="搜索订单"> <Search size={18} aria-hidden="true" /> </button> ); }aria-label不应写成“按钮”或“图标”。它要描述操作结果，例如“搜索订单”“关闭弹窗”“清空筛选”。如果页面上有多个相同图标按钮，还要区分上下文。可访问名称是读屏用户理解界面的入口，不是为了通过扫描工具。
焦点管理同样重要。弹窗打开时，焦点应进入弹窗；关闭时，焦点应回到触发按钮；键盘 Tab 不应跑到遮罩层背后的页面。AI 可以提醒焦点问题，但实际验证仍需要键盘操作和读屏测试。
四、落地策略：把无障碍纳入组件库
无障碍最好在组件库层面解决。按钮、输入框、弹窗、下拉菜单、Tabs、Toast、表格等基础组件都应内置语义、焦点和键盘交互。业务页面如果每次自己补，无障碍质量很难稳定。
设计规范中也要标注无障碍要求。颜色 Token 应提供对比检查，表单组件应定义错误提示位置，动效组件应支持减少动态效果，图标使用应区分装饰图标和功能图标。AI 评审可以基于这些规范判断，而不是每次重新解释。
最后要建立抽样验证。自动扫描和 AI 评审能覆盖一部分问题，但真实读屏体验仍需要人工测试。尤其是复杂表格、拖拽排序、分步表单和富文本编辑器，应安排键盘和读屏路径验证。无障碍不是额外负担，它是界面质量的一部分。
五、总结
AI 无障碍评审适合把规则扫描、截图语义和修复建议整合起来，但无障碍质量仍依赖组件库、设计规范和人工验证。让界面被看见，也要让它能被读懂、被操作、被理解。这才是前端体验的底线。