html无障碍本身不会提升屏幕阅读体验，关键在语义真实、结构合理；role="button"需配合tabindex="0"、键盘事件及状态属性，否则屏幕阅读器只读“button”却无响应。
HTML无障碍本身不会“提升”屏幕阅读体验，反而可能让屏幕阅读器更难理解内容——关键不在加不加 ARIA，而在语义是否真实、结构是否合理。
为什么 role="button" 会让屏幕阅读器读错
用 <div> 加 <code>role="button" 模拟按钮，但没处理 Enter/Space 键响应、没设 tabindex="0"、也没同步 aria-pressed 状态时，屏幕阅读器只读出“button”，用户按下去却没反馈，甚至触发不了逻辑。
- 真实按钮优先用
<button></button>：浏览器原生支持焦点、键盘交互、状态映射 - 仅当必须用非标准元素时，才补全三要素：
tabindex="0"+ 键盘事件监听 + 状态属性（如aria-pressed或aria-expanded） - 绝对不要给原生
<button></button>再加role="button"：会覆盖原生语义，部分读屏可能重复播报
alt="" 和不写 alt 有本质区别
不写 alt 时，多数屏幕阅读器会把图片当成“图像”朗读文件名或路径（尤其本地开发环境），或直接跳过但报“未知图形”，造成信息断层；而 alt="" 是明确声明“该图无文字等效内容”，读屏会静默跳过，符合 WCAG “装饰性图片”要求。
- 纯装饰图：用
alt=""，且确保 CSS 背景图不承载关键信息 - 图标按钮（如放大镜图标）：需结合
aria-label或隐藏文本，不能只靠alt="" - 图表/信息图：必须提供等效文字描述，放在
<figure><figcaption></figcaption></figure>或紧邻的段落中
表单控件没配 <label></label>，屏幕阅读器就只能瞎猜
没有显式关联的 <input>，屏幕阅读器通常只报“编辑框”或“复选框”，不读提示文字。哪怕用了 placeholder，也不等于 <label></label>——placeholder 会在输入时消失，且部分屏幕阅读器默认不读它。
- 首选显式绑定：
<label for="email">邮箱地址</label><input id="email"> - 嵌套方式也有效：
<label>手机号<input type="tel"></label>（无需for/id） - 避免仅靠
aria-label：它会完全替代标签文本，无法被翻译、无法被 CSS 隐藏控制，且在多语言场景易出错
aria-hidden="true" 不是“视觉隐藏”的万能开关
aria-hidden="true" 会直接从可访问树中移除元素及其所有子节点，屏幕阅读器彻底“看不见”。但它不是用来“隐藏视觉上多余的内容”的万能开关。
- 可以安全使用：
<img src="icon.svg" aria-hidden="true">（纯装饰图标，已有相邻文字说明） - 绝对不能藏：
<div aria-hidden="true"><button>删除</button></div>→ 按钮完全不可访问 - 轮播图的“上一张/下一张”箭头按钮，用
display: none或visibility: hidden更安全；若用aria-hidden="true"，必须同步确保焦点管理逻辑不把键盘用户卡在死区
最常被忽略的是焦点顺序与视觉顺序不一致的问题——比如用 CSS order 或 flex-direction: row-reverse 打乱 DOM 顺序，会导致键盘用户 Tab 时跳转路径混乱，而屏幕阅读器仍按 DOM 顺序朗读。
