必须直接替换嵌套表格而非修复：因其导致屏幕阅读器无法建立父子表头关系、scope/headers失效、键盘导航卡死；根本原因是dom解析逻辑断层，非渲染问题。
直接替换掉嵌套表格，别修它。历史遗留框架里用 <table> 套 <code><table> 的结构，本质是语义坍塌——屏幕阅读器无法建立父子表头关系，<code>scope 失效，headers 属性失效，连键盘导航都会在子表内部卡死。
为什么嵌套表格会让可访问性彻底失效
不是渲染问题，是解析逻辑断层。浏览器能画出两层表格，但辅助技术依赖 DOM 结构推导数据关系。当一个 <td> 里塞进完整 <code><table>，父表的 <code><th scope="col"> 就再无法“覆盖”到子表的 <code><td> 上；子表自身又缺少独立 <code><caption></caption> 和 <thead>，变成一堆无上下文的单元格。
<ul>
<li>常见错误现象：NVDA 连续读出“空、空、空”，JAWS 在子表第一行后跳过整块内容</li>
<li>键盘 Tab 导航会跳过子表内部所有 <code><input>，因为它们被判定为“非表格数据流的一部分”
aria-labelledby 或 headers 指向子表内 ID 时，多数屏幕阅读器直接忽略——不报错，也不生效必须保留原结构？那就强制注入语义锚点
如果 CMS 输出不可改、邮件模板受限、或第三方 iframe 内容无法控制，只能做最小干预。核心是让子表“自证身份”，切断对父表语义的依赖。
- 每个嵌套
<table> 必须带 <code><caption></caption>，且文本要说明用途，比如<caption>订单 #12345 的明细项</caption> - 子表必须有
<thead>，哪怕只有一行，且每列 <code><th> 显式加 <code>scope="col" - 禁用所有
colspan/rowspan，它们在嵌套中会放大定位偏差 - 给子表加
role="region"和唯一aria-label，例如aria-label="嵌套明细表格"，让屏幕阅读器把它当独立区块处理 - 把原嵌套结构外层
<table> 改为 <code><div role="table">，每个 <code><tr> 改为 <code><div role="row">，<code><td> 和 <code><th> 改为 <code><div role="cell"> 或 <code><div role="columnheader"> <li>用 CSS Grid 控制列宽和对齐：<code>display: grid; grid-template-columns: 1fr 2fr 1fr;，子区域用grid-column: span 3拉满宽度 - 关键：保留所有
<caption></caption>、<thead>、<code>scope和headers，只是换掉了容器标签——语义全在，渲染由 Grid 接管 - 测试重点：用 Chrome DevTools 的 Accessibility 面板检查
rowheader和gridcell角色是否正确暴露
用 CSS Grid 替代的实操迁移路径
真正可行的解法不是“修表格”，而是用现代布局接管渲染权，同时保持 HTML 表格语义不变——即视觉上仍是表格样式，DOM 结构却可访问。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
最常被忽略的一点：即使你用了 role="table"，也必须手动实现键盘导航支持（ArrowRight/Left 移动单元格，Enter 编辑），否则键盘用户依然卡住。这不是可选项，是可访问性的硬门槛。
