HTML无障碍关键在语义真实与结构合理，而非滥用ARIA；role="button"需补全键盘交互、tabindex和状态属性；装饰图用alt=""，图标按钮需aria-label；表单必配label；须用真实读屏测试交互流。
HTML 无障碍不会“自动”提升屏幕阅读体验，反而可能因错误实现让屏幕阅读器更难理解内容——关键不在加不加 ARIA，而在语义是否真实、结构是否合理。
为什么 role="button" 会让屏幕阅读器读错？
当用 <div> 加 <code>role="button" 模拟按钮，但没处理 Enter / Space 键响应、没设 tabindex="0"、也没同步 aria-pressed 状态时，屏幕阅读器只读出“button”，用户按下去却没反馈，甚至触发不了逻辑。这不是“加了无障碍”，是制造了可访问性陷阱。
- 真实按钮优先用
<button></button>—— 浏览器原生支持焦点、键盘交互、状态映射 - 仅当必须用非标准元素时，才补全：键盘事件 +
tabindex+aria-pressed（如开关）或aria-expanded（如折叠面板） - 避免给
<button></button>再加role="button"—— 会覆盖原生语义，部分读屏可能重复播报
alt 属性为空字符串 alt="" 和不写 alt 有本质区别
不写 alt 时，多数屏幕阅读器会把图片当成“图像”朗读文件名或路径（尤其本地开发环境），或直接跳过但报“未知图形”，造成信息断层；而 alt="" 是明确声明“该图无文字等效内容”，读屏会静默跳过，符合 WCAG “装饰性图片”要求。
- 纯装饰图：用
alt=""，且确保 CSS 背景图不承载关键信息 - 图标按钮（如放大镜图标）：需结合
aria-label或隐藏文本，不能只靠alt="" - 图表/信息图：必须提供等效文字描述，放在
<figure><figcaption></figcaption></figure>或紧邻的段落中
表单控件没配 <label></label>，屏幕阅读器根本不知道这是什么
很多开发者用 placeholder 当标签，或靠视觉位置“暗示”输入框用途。但屏幕阅读器默认不读 placeholder，也不会根据上下文自动关联“上面那行字是标题”。结果就是用户聚焦到输入框，只听到“编辑文本”，毫无上下文。
立即学习“前端免费学习笔记（深入）”；
- 首选显式绑定：
<label for="email">邮箱地址</label><input id="email"> - 嵌套方式也有效：
<label>手机号<input type="tel"></label>（无需for/id） - 避免仅靠
aria-label：它会完全替代标签文本，无法被翻译、无法被 CSS 隐藏控制，且在多语言场景易出错
最常被忽略的一点：无障碍不是“加完 ARIA 就结束”，而是要持续用真实屏幕阅读器（NVDA + Firefox、VoiceOver + Safari）测试交互流——比如打开一个模态框后，焦点是否落在第一个可操作元素？关闭后焦点是否回到触发按钮？这些细节不跑一遍，代码再“合规”也等于没做。
