表格排序按钮需同时设置 aria-sort 和 tabindex="0"，初始值为 none，点击时动态更新为 ascending/descending/none；筛选框须用 aria-labelledby 关联对应表头 ID；跨行跨列表头必须用 headers 属性显式绑定；tbody 更新应保留焦点与编辑态。
表格排序按钮必须带 aria-sort 和 tabindex
只给 <th> 加 onclick 是不够的。屏幕阅读器需要知道当前列是否可排序、处于什么状态（升序/降序/未排序），否则用户会误以为点击无效或功能缺失。
常见错误是漏掉 tabindex="0"，导致键盘用户无法用 Tab 键聚焦到表头；或者只写 aria-sort="ascending" 却没在状态切换时同步更新，造成语义与实际行为脱节。
-
<th scope="col" tabindex="0" aria-sort="none">姓名</th>—— 初始状态必须设为none，不能留空或缺省 - 每次点击后，要动态更新
aria-sort值："ascending"→"descending"→"none" - 视觉箭头图标（如 ▲ ▼）只是辅助，不能替代
aria-sort；屏幕阅读器不读图标，只读这个属性 - 避免用
role="button"包裹<th>——<th>本身已是可交互语义元素，加 role 会覆盖原生columnheader角色
筛选输入框必须用 aria-label 或 aria-labelledby 关联列头
把 <input type="search"> 塞进 <td> 里只是第一步。如果没声明它“筛选的是哪一列”，屏幕阅读器只会读“搜索框”，用户根本不知道该输什么。
最常踩的坑是给整行 <tr> 加 role="search" —— 这直接破坏表格结构，触发 aria-requires-children 报错，且让所有后续单元格失去行列上下文。
立即学习“前端免费学习笔记（深入）”；
- 正确做法：给对应列头
<th>加id，比如<th id="city-header" scope="col">城市</th> - 筛选框用
aria-labelledby="city-header"，而不是笼统的aria-label="筛选" - 如果筛选框在
<thead>里，确保它和<th>同级或嵌套在<td>中，别塞进<th>里——<th>只管表头文本，不承载控件 - 输入框需支持
Enter提交，且失焦时自动触发筛选（防抖后），避免用户反复按回车
复杂表头（rowspan/colspan）必须用 headers 显式绑定
只要出现合并单元格，scope 就失效。屏幕阅读器无法推断“这个 <td> 同时属于‘2026年Q1’和‘销售额’两个表头”，结果就是只读出数值，不读上下文。
很多人以为视觉对齐=语义对齐，但 DOM 顺序和视觉位置完全无关。headers 绑定只认 ID 字符串，不看 CSS 或表格布局。
- 给每个参与跨行/跨列的
<th>加唯一id：<th id="q1-header" colspan="2">2026年Q1</th>，<th id="sales-header" scope="col">销售额</th> - 对应数据单元格写：
<td headers="q1-header sales-header">120万</td> - 多个 ID 用空格分隔，不能用逗号或其它符号
- 不要试图用 JavaScript 动态生成 headers 值——DOM 渲染完成前就得存在，否则屏幕阅读器初始化时就读不到
排序/筛选后 tbody 更新必须保留焦点与编辑态
用 innerHTML = newRows 替换整个 <tbody> 看似简单，但会清空所有已聚焦的输入框、销毁事件监听器、重置滚动位置。键盘用户正在编辑某行，筛选后光标突然消失，体验直接断裂。
真正麻烦的不是 DOM 操作本身，而是状态管理：你得记住谁在编辑、哪行有 dirty 数据、上次筛选条件是什么——这些全靠手动维护，自动化工具几乎帮不上忙。
- 只替换
<tbody>的子节点，用DocumentFragment批量插入，避免频繁重排 - 筛选后若某行被隐藏，检查该行是否有
document.activeElement是其内部<input>，有的话执行.blur() - 排序后保持原聚焦行的视觉位置（比如第3行仍显示在视口中间），必要时调用
scrollIntoView({ block: 'nearest' }) - 所有状态变量（如
isAsc、sortBy、filterValues）必须独立于 DOM 存储，不能靠 class 名或 data 属性临时存取
