屏幕阅读器读得乱源于HTML结构未按逻辑流编写，它读DOM顺序而非视觉布局；错误使用CSS定位、aria-hidden、tabindex及忽略语义结构均会破坏可访问性。
屏幕阅读器读得乱，往往不是它坏了，而是HTML结构没按逻辑流写
屏幕阅读器不是“读页面”，而是读DOM树的顺序。这个顺序默认等于HTML源码书写顺序，而不是CSS渲染后的位置。如果你用float、position: absolute或flex-direction: row-reverse把视觉顺序调乱，但HTML里还是从上到下写导航→主内容→侧边栏，屏幕阅读器就会先读侧边栏再读导航——用户根本找不到入口。
常见错误现象包括：键盘Tab焦点跳转无规律、屏幕阅读器朗读标题后直接跳到页脚、表单控件和label被隔开导致无法关联。
- 检查工具链：用浏览器开发者工具的“Accessibility”面板看“Accessibility Tree”，对比它和你写的HTML顺序是否一致
- 禁用CSS验证逻辑流：临时在DevTools中禁用所有CSS（右键→“Disable styles”），观察元素是否仍按预期顺序排列
- 避免用
tabindex="1"或更高值强行干预顺序——它会打断自然流，且不同浏览器解析不一致
为什么aria-hidden="true"不能随便加，尤其对容器元素
aria-hidden="true"会让整个子树从可访问性树中移除，但它不阻止键盘焦点进入——这是最常踩的坑。比如给一个弹窗外层div加了aria-hidden="true"，但里面仍有button或input，键盘用户仍能Tab进去，屏幕阅读器却完全沉默，造成“能操作但听不见”的诡异状态。
使用场景很明确：仅用于纯装饰性、非交互、且不影响语义结构的节点（如图标字体span、背景图案div）。
立即学习“前端免费学习笔记（深入）”；
- 模态框遮罩层（overlay）应设
aria-hidden="true"，但模态框本体必须设aria-hidden="false"或不设该属性 - 隐藏的导航菜单（
display: none或visibility: hidden）无需加aria-hidden——CSS隐藏已天然排除在可访问性树外 - 动态插入的内容（如加载中的提示）若暂不可操作，优先用
aria-busy="true"而非aria-hidden
tabindex值选错，比不加还危险
tabindex="-1"和tabindex="0"用途截然不同，混用会导致键盘导航断裂。前者只允许JS主动聚焦（如模态框打开后focus()到关闭按钮），后者让元素进入Tab流——但前提是它本身是可交互的。给div加tabindex="0"却不配role，屏幕阅读器会把它当普通文本块朗读，用户按Enter也没反应。
性能影响常被忽略：大量tabindex="0"会拉长Tab路径，残障用户需按数十次才能到达主内容。
- 按钮、链接、表单控件天然可聚焦，无需加
tabindex - 自定义组件（如
div模拟的开关）必须同时满足：加tabindex="0"+ 设role="switch"+ 同步管理aria-checked - 禁用状态的控件（
disabled属性）自动退出Tab流，此时加tabindex="0"无效且误导
表格和列表的逻辑顺序容易被CSS“骗”
表格用display: grid重排行列、列表用flex-direction: column-reverse倒序显示，视觉上没问题，但<th scope="col">和<code><li>的DOM顺序没变——屏幕阅读器仍按原始顺序读，结果表头和数据错位、列表项编号反着报。
这不是浏览器bug，是语义与呈现分离的必然结果。可访问性依赖的是HTML结构，不是渲染结果。
- 复杂表格必须用
headers属性显式绑定数据单元格和多个表头ID，不能只靠视觉对齐 - 倒序列表（如评论最新在前）应在HTML里真实倒序写，而非用CSS翻转；否则屏幕阅读器读出“第5条评论”时，用户看到的是第一条
- 用
aria-live更新动态列表时，新条目应插入DOM开头（而非末尾），才能让aria-live="polite"按预期播报
逻辑阅读顺序不是“写完HTML再补可访问性”，而是从第一行标签就开始的决策。最容易被忽略的点是：当你为视觉效果妥协结构时，其实已经默认放弃了键盘用户和屏幕阅读器用户——而他们往往就是最需要稳定、可预测信息流的人。
