视觉用户看一眼就能知道“第二列是金额、第三行是北京”，屏幕阅读器如果没有正确表头语义，只会连续读一串数字。可访问表格的核心不是多加 ARIA，而是用正确结构表达数据之间的行列关系。
01 只有真实二维关系的数据才应该使用 Table
W3C Tables Tutorial 明确区分数据表和布局表。表格用于让行列关系本身传递信息，不应用于排列卡片和页面布局。
错误使用 Table 会让辅助技术把纯视觉布局误读成数据关系。
02 视觉粗体不是表头，HTML th 才建立语义
设计稿第一行加灰底和粗体只告诉视觉用户“这是 Header”。开发需要使用 th，并根据简单表格关系设置 scope="col" 或 scope="row"。
这样屏幕阅读器在读取数值时才能同时关联对应表头。
03 复杂多级表头需要提前设计关系
例如“2025 / Q1 / 收入”三层表头，如果只是视觉合并单元格，很容易失去机器可理解关系。
复杂表格可能需要 id/headers 等方式建立关联。设计阶段就应避免无意义跨列和过度嵌套，必要时拆分表格。
04 Caption 或清楚标题能说明这张表“讲的是什么”
页面同时有多张表时，只有“数据表 1”并不够。标题应该描述对象和时间，例如“2026 年第二季度各地区销售额”。
Carbon 当前也建议 Data Table 有清楚 title 和 description，说明数据共同点和用途。
05 排序必须同时有视觉和程序状态
可排序列不能只在鼠标 Hover 时出现小箭头。键盘用户需要能聚焦并通过 Enter/Space 操作。
Carbon 无障碍指南使用 aria-sort 表达当前排序状态，设计也应提供持续可见的已排序指示。
06 行内控件要进入正常 Tab 顺序
表格里的链接、Checkbox、Menu、展开按钮都是正常交互，应支持键盘。
如果每行有十个可聚焦控件，键盘成本会非常高，这也是减少行内操作、使用批量操作的重要理由。
07 响应式转换也要保留数据语义
移动端把 Table 改成卡片后，不能只靠视觉位置表达字段。每个值仍需有清楚标签。
如果横向滚动保留表格，则确保表头、焦点和滚动容器都可操作。
08 自动无障碍测试无法替代真实读表任务
工具可以发现缺少 th 等问题，但很难判断一个 30 列表格是否实际可理解。
最终仍需要键盘和屏幕阅读器测试典型任务：找到某行、比较两列、排序、选择并执行操作。
09 复杂表头优先考虑简化信息结构，而不是继续堆 ARIA
多层合并单元格、横纵双向分组虽然可以通过更复杂的关联方式表达，但理解成本会同时上升。只要业务允许，把一个超级表拆成几个主题表，往往对所有用户都更友好。
无障碍不是在复杂设计完成后补属性，它也可以促使团队重新审视信息是否本来就过度复杂。
10 导出和可视化切换也要保留数据语义
高频企业用户可能在表格、图表和 CSV 之间切换。页面中的颜色、图标和缩写如果导出后失去含义，就会影响协作。
因此关键字段名称、单位和状态应有清晰文本表达，视觉强化只是辅助。
常见问题
表头做粗体就算无障碍吗？
不算。需要使用正确 HTML 表头语义建立行列关联。
简单表格需要 ARIA 吗？
通常原生 table/th/scope 就能提供良好语义，不要无必要增加复杂 ARIA。
表格一定需要 Caption 吗？
上下文已经非常明确时不一定，但多表格或独立表格有清楚标题会更易理解。
排序图标需要一直显示吗？
至少当前已排序状态应持续可见，并有程序化 aria-sort。
移动端卡片化会破坏表格无障碍吗？
不会必然破坏，但需要重新为每个值提供明确标签和阅读顺序。
相关服务与进一步咨询
链接复制成功
