是，嵌套表格易导致屏幕阅读器读错顺序，根本原因是子表格缺失语义结构（如thead、scope）或父表未明确作用域，需补全语义标签并绑定caption，同时避免tr内嵌交互元素引发事件冲突。
嵌套表格会让屏幕阅读器读错顺序吗
会，而且非常容易。根本原因不是“用了嵌套”，而是子表格缺失语义结构或父表未明确作用域。屏幕阅读器依赖 <thead>、<code><th scope="col"> 和 <code>role 属性推断行列关系，一旦子表格里只有 <tr><td> 这种裸结构，它就会把子表行当成主表的普通数据行读，甚至跳过整个子表。
<ul><li>子表格必须包含 <code><thead>（哪怕只有一行），且其中每个 <code><th> 都要带 <code>scope="col"
<th> 若对应含子表的列，应加 <code>aria-label 说明“点击展开明细”之类，避免仅靠视觉暗示
<tr> 或 <code><td> 加 <code>tabindex="0"——这会让键盘焦点落在非交互区域，干扰阅读器线性遍历
为什么嵌套表格的复选框会被标记为“交互式控件嵌套”
因为很多人把 <input type="checkbox"> 直接塞进可点击的 <tr> 里，而没切断事件传播链。Axe 工具报错不是反对“有复选框”，而是反对“用户点击复选框时，<code>tr 的 click 事件也触发”。这种双重响应对键盘用户和屏幕阅读器来说是不可预测的。
- 删掉
<tr> 上的 <code>onclick、tabindex和role="row"（除非你用 JS 手动管理焦点） - 把复选框放在
<td> 里，并确保该 <code><td> 不再包裹其他交互元素（如按钮、链接） <li>如果必须支持整行点击选中，改用 <code>label包裹复选框，样式上撑满<td>，而不是监听 <code>tr子表格的
caption有用吗？怎么写才不被忽略有用，但默认会被屏幕阅读器跳过——除非你显式把它和子表格绑定。HTML5 允许每个
<table> 有且只有一个 <code><caption></caption>，但它不会自动关联到父表上下文，也不会被读作“子表标题”，除非加id并在父<td> 中引用。 <ul> <li>子表格的 <code><caption id="cap-1">技术部人员明细</caption>必须存在，且不能省略 - 包裹子表格的
<td> 要加 <code>aria-labelledby="cap-1"，否则阅读器只读“表格”，不读标题 - 避免用
<caption></caption>做装饰性文字（如“点击查看”），它只用于描述表格内容目的
替代方案比修复嵌套更值得优先考虑
不是所有“看起来像表中表”的场景都真需要嵌套 <table>。现代可访问性标准下，<code><details>/<summary></summary></details> + <table> 组合的兼容性和语义清晰度远高于纯嵌套表格，尤其在移动端和键盘导航中。<p><span>立即学习</span>“<a href="https://pan.quark.cn/s/cb6835dc7db1" style="text-decoration: underline !important; color: blue; font-weight: bolder;" rel="nofollow" target="_blank">前端免费学习笔记（深入）</a>”；</p>
<ul>
<li>
<code><details></details> 默认可折叠，自带 aria-expanded 和焦点管理，屏幕阅读器能自然识别“有子内容”
<details><summary>展开明细</summary><table>...</table></details>，然后给 <summary></summary> 加 aria-controls 指向子表 IDdisplay: none 切换——用 aria-hidden="true" + inert 属性，确保阅读器彻底跳过隐藏内容<caption></caption> 和父 <td> 之间没有显式关联，以及整行点击逻辑与内部表单控件的事件冲突。这两点不处理，其他优化基本白做。</td>
