<td>和<th>默认不可聚焦，需显式设tabindex="0"并确保有交互能力（如contenteditable或子表单控件）；原生表格不支持按行Tab，须JS接管；复杂交互推荐role="grid"但弃用原生语义；Safari对空单元格等场景存在兼容问题。
tabindex在和
上默认无效，必须显式设置
HTML规范里，<td>和<th>本身不是可聚焦元素，即使加了tabindex="0"，在部分浏览器（尤其是旧版Safari和IE）中仍可能跳过。真正生效的前提是：该单元格有交互能力或明确的焦点语义。常见做法是给单元格加contenteditable="true"，或包裹一个<button>/<input>，或直接设tabindex="0"并确保CSS未禁用焦点（比如outline: none但没配focus样式会导致视觉丢失，不影响逻辑）。
实操建议：
- 优先用
tabindex="0"而非tabindex="-1"——后者只支持JS主动.focus()，不参与Tab键自然循环
- 避免对整行
<tr>设tabindex：多数屏幕阅读器不识别<tr>为焦点容器，且键盘焦点落在行上后无法自然进入单元格
- 若表格用于数据展示而非交互，别强行加
tabindex——会破坏语义，反而降低可访问性
实现“按行Tab、回车进编辑”的焦点流需手动接管
原生Tab键默认按DOM顺序遍历所有可聚焦元素，不会自动“按行”切换。想让焦点从第1行第1列→第1行第2列→…→第1行末→第2行第1列，必须用JS拦截keydown事件，检测Tab键并计算下一个目标单元格。
关键点：
立即学习“前端免费学习笔记（深入）”；
- 用
event.preventDefault()阻止默认Tab行为，否则焦点会跳到页面其他可聚焦元素
- 通过
document.activeElement定位当前单元格，再用rowIndex/cellIndex推算下个位置；注意跨行时要校验table.rows[row].cells[col]是否存在
- 回车键（
Enter）通常用来激活编辑态，此时应把焦点转移到单元格内的<input>或触发contenteditable，而不是继续Tab循环
- Shift+Tab反向循环时，别简单倒序遍历——要按视觉行优先逻辑逆推，否则容易跳到表头或空单元格
aria-activedescendant配合role="grid"才是合规方案
如果表格承载的是类似电子表格的交互（如Excel式编辑），WAI-ARIA推荐用role="grid"替代原生<table>，并用aria-activedescendant管理焦点状态。此时<td>需改为role="gridcell"，且整个网格只有一个可聚焦容器（如tabindex="0"的<div role="grid">），所有单元格本身不可聚焦。
这样做能绕过浏览器对<td>的聚焦限制，同时满足屏幕阅读器的网格导航逻辑（Ctrl+Alt+方向键等）。但代价是完全放弃原生表格语义，需手动补全所有ARIA属性（aria-rowindex、aria-colindex、aria-selected等）。
注意：
-
role="grid"不能套在<table>上——二者语义冲突，会导致读屏器混乱
- 移动端对
role="grid"支持不稳定，iOS VoiceOver常降级为线性阅读，别依赖其方向键导航
- 若只是简单表单表格（每行一个
<input>），坚持用原生<table>+tabindex更轻量可靠
Chrome/Firefox/Edge对tabindex="0"的支持已稳定，但Safari仍存边界问题
当前主流Chromium内核和Firefox已能正确将tabindex="0"的<td>纳入Tab顺序，但Safari（尤其macOS 13/iOS 16之前）在以下场景会跳过：
- 单元格为空白（无文本、无子元素、
innerHTML为空字符串）
- 父
<tr>设置了display: contents（破坏表格渲染树）
- 表格被
overflow: hidden裁剪，且单元格不在视口内（Safari不预判可聚焦性）
临时缓解方式：给单元格加min-width: 1px和min-height: 1em，或插入零宽空格；但根本解法仍是用contenteditable或子元素承载焦点。
最易被忽略的一点：焦点循环逻辑一旦涉及多层嵌套（如表格在shadow DOM里，或被transform缩放），各浏览器对tabindex的解析差异会突然放大——务必在真实设备上验证Tab路径，别只信DevTools的焦点模拟。
HTML规范里，<td>和<th>本身不是可聚焦元素，即使加了tabindex="0"，在部分浏览器（尤其是旧版Safari和IE）中仍可能跳过。真正生效的前提是：该单元格有交互能力或明确的焦点语义。常见做法是给单元格加contenteditable="true"，或包裹一个<button>/<input>，或直接设tabindex="0"并确保CSS未禁用焦点（比如outline: none但没配focus样式会导致视觉丢失，不影响逻辑）。
实操建议：
- 优先用
tabindex="0"而非tabindex="-1"——后者只支持JS主动.focus()，不参与Tab键自然循环 - 避免对整行
<tr>设tabindex：多数屏幕阅读器不识别<tr>为焦点容器，且键盘焦点落在行上后无法自然进入单元格 - 若表格用于数据展示而非交互，别强行加
tabindex——会破坏语义，反而降低可访问性
实现“按行Tab、回车进编辑”的焦点流需手动接管
原生Tab键默认按DOM顺序遍历所有可聚焦元素，不会自动“按行”切换。想让焦点从第1行第1列→第1行第2列→…→第1行末→第2行第1列，必须用JS拦截keydown事件，检测Tab键并计算下一个目标单元格。
关键点：
立即学习“前端免费学习笔记（深入）”；
- 用
event.preventDefault()阻止默认Tab行为，否则焦点会跳到页面其他可聚焦元素 - 通过
document.activeElement定位当前单元格，再用rowIndex/cellIndex推算下个位置；注意跨行时要校验table.rows[row].cells[col]是否存在 - 回车键（
Enter）通常用来激活编辑态，此时应把焦点转移到单元格内的<input>或触发contenteditable，而不是继续Tab循环 - Shift+Tab反向循环时，别简单倒序遍历——要按视觉行优先逻辑逆推，否则容易跳到表头或空单元格
aria-activedescendant配合role="grid"才是合规方案
如果表格承载的是类似电子表格的交互（如Excel式编辑），WAI-ARIA推荐用role="grid"替代原生<table>，并用aria-activedescendant管理焦点状态。此时<td>需改为role="gridcell"，且整个网格只有一个可聚焦容器（如tabindex="0"的<div role="grid">），所有单元格本身不可聚焦。
这样做能绕过浏览器对<td>的聚焦限制，同时满足屏幕阅读器的网格导航逻辑（Ctrl+Alt+方向键等）。但代价是完全放弃原生表格语义，需手动补全所有ARIA属性（aria-rowindex、aria-colindex、aria-selected等）。
注意：
-
role="grid"不能套在<table>上——二者语义冲突，会导致读屏器混乱 - 移动端对
role="grid"支持不稳定，iOS VoiceOver常降级为线性阅读，别依赖其方向键导航 - 若只是简单表单表格（每行一个
<input>），坚持用原生<table>+tabindex更轻量可靠
Chrome/Firefox/Edge对tabindex="0"的支持已稳定，但Safari仍存边界问题
当前主流Chromium内核和Firefox已能正确将tabindex="0"的<td>纳入Tab顺序，但Safari（尤其macOS 13/iOS 16之前）在以下场景会跳过：
- 单元格为空白（无文本、无子元素、
innerHTML为空字符串）
- 父
<tr>设置了display: contents（破坏表格渲染树）
- 表格被
overflow: hidden裁剪，且单元格不在视口内（Safari不预判可聚焦性）
临时缓解方式：给单元格加min-width: 1px和min-height: 1em，或插入零宽空格；但根本解法仍是用contenteditable或子元素承载焦点。
最易被忽略的一点：焦点循环逻辑一旦涉及多层嵌套（如表格在shadow DOM里，或被transform缩放），各浏览器对tabindex的解析差异会突然放大——务必在真实设备上验证Tab路径，别只信DevTools的焦点模拟。
当前主流Chromium内核和Firefox已能正确将tabindex="0"的<td>纳入Tab顺序，但Safari（尤其macOS 13/iOS 16之前）在以下场景会跳过：
- 单元格为空白（无文本、无子元素、
innerHTML为空字符串） - 父
<tr>设置了display: contents（破坏表格渲染树） - 表格被
overflow: hidden裁剪，且单元格不在视口内（Safari不预判可聚焦性）
临时缓解方式：给单元格加min-width: 1px和min-height: 1em，或插入零宽空格；但根本解法仍是用contenteditable或子元素承载焦点。
最易被忽略的一点：焦点循环逻辑一旦涉及多层嵌套（如表格在shadow DOM里，或被transform缩放），各浏览器对tabindex的解析差异会突然放大——务必在真实设备上验证Tab路径，别只信DevTools的焦点模拟。
