很多团队把无障碍理解成“给图片加alt”。真正影响使用的还有：菜单只能鼠标Hover、弹窗无法关闭、表单错误读不到、焦点跳到页面背后。
更可靠的原则是优先使用原生HTML行为，在确实需要自定义组件时再补充ARIA和键盘逻辑。
01 语义HTML是第一层
按钮用button，链接用a，标题按内容层级，表单控件有label。原生元素自带许多键盘和辅助技术行为。
用div模拟按钮会把点击、键盘、焦点和名称全部变成开发责任。
02 所有功能都应可用键盘完成
用户应能Tab到交互控件、看到焦点、按Enter或Space操作，并用Esc关闭合适的弹层。
焦点顺序跟随视觉和DOM逻辑，避免正tabindex制造不可维护顺序。
网页无障碍开发检查
| 区域 | 基本要求 | 常见错误 |
|---|---|---|
| 导航 | 可跳过重复内容、菜单键盘可用 | Hover唯一入口 |
| 标题 | 层级表达内容结构 | 按字号乱用H标签 |
| 图片 | 按用途写Alt或空Alt | 关键词堆砌、文件名 |
| 表单 | 标签、错误关联、说明清楚 | 仅颜色提示、占位代替标签 |
| 弹窗 | 焦点进入、限制、关闭后返回 | 焦点留在背景或丢失 |
| 动态内容 | 必要时通知状态变化 | 加载完成读屏无反馈 |
| 颜色 | 文本与组件有足够对比 | 浅灰小字、只靠颜色 |
03 ARIA不能修复错误结构
ARIA用于补充角色、名称、状态和关系，不应把所有div包装成复杂控件。
自定义Combobox、Tabs和Tree等组件需遵循成熟交互模式并测试辅助技术。
04 表单错误要能被找到和理解
错误与字段关联，说明具体问题和修复方式；提交后把焦点或摘要引导到错误。
必填、格式和帮助文本不能只靠红色或图标表达。
05 动态界面管理焦点与通知
单页应用路由变化、异步保存、Toast和加载结果，需要让读屏用户知道发生了什么。
通知不要过度，频繁播报会造成干扰。
06 自动检测与人工测试结合
自动工具能发现部分语义、对比和属性问题，无法判断文案是否准确、焦点是否合理、流程是否可用。
至少做键盘走查、读屏抽测、缩放和高对比测试，并邀请真实用户参与重要系统。
常见问题
加ARIA就能通过无障碍吗？
不能。应先使用正确HTML和交互，ARIA只是补充。
所有图片都要写Alt吗？
有信息的图片需要合适Alt，纯装饰图片应使用空Alt避免噪音。
隐藏内容读屏会读到吗？
取决于隐藏方式。视觉隐藏和从辅助技术树移除不是同一件事。
自动检测工具能覆盖多少问题？
只能发现一部分，键盘、语义理解和真实任务仍需人工测试。
无障碍会限制视觉设计吗？
会提供必要约束，但清楚层级、可读性和一致交互通常也改善所有用户体验。
链接复制成功
