tabindex="0" 是表单焦点顺序的默认安全基线,表单控件默认隐式拥有该值,无需手动添加;显式设置正数 tabindex 会导致顺序错乱,负数仅用于编程聚焦;非交互元素需设 tabindex="0" 并处理键盘事件;Safari 中 dialog.showModal() 无法自动围住焦点,须手动聚焦、拦截 Tab 键并管理嵌套焦点;表单验证失败后应可靠重定向焦点至首个错误字段;非模态浮层不应使用原生 ,而应采用 role="dialog" + inert 等更可控方案。

tabindex="0" 是表单焦点顺序的默认安全基线
表单控件(<input>、<button></button>、<select></select>、带 href 的 <a></a>)默认就拥有隐式 tabindex="0",无需手动添加。只要 HTML 结构顺序与视觉/逻辑顺序一致,Tab 键自然按 DOM 顺序流转,这是最稳定、最无障碍的方案。
常见错误是给所有表单元素硬加 tabindex="1"、tabindex="2" 等正数——浏览器只取最小正整数生效,其余被忽略;且一旦插入新字段或调整结构,整个顺序就错乱,屏幕阅读器可能跳过中间项。
-
tabindex="-1"仅用于需要编程聚焦但不参与 Tab 流的场景,比如错误提示区域、模态框关闭后需还原的触发按钮 - 非交互元素(如
<div>、<code><span></span>)若需键盘可访问,必须显式设tabindex="0",并配套处理Enter和Space键事件,否则用户“跳到了却没反应”,等同于不可用 - 避免用 CSS
order或float打乱视觉顺序却不调整 DOM 顺序——焦点仍按源码走,造成导航断层 - 打开后立即用
requestAnimationFrame(() => firstFocusable.focus())聚焦首个可聚焦元素(不能等 CSS 动画结束) - 监听
keydown拦截Tab和Shift+Tab,在对话框内手动循环焦点(别依赖:focusable,浏览器不支持该伪类) - 关闭前缓存触发源(如
open-btn),关闭后检查它是否仍存在且可聚焦,再调用.focus() - 确保错误字段本身可聚焦:已渲染、未被
inert或aria-hidden="true"屏蔽、CSS 未禁用交互(如pointer-events: none) - 用
requestAnimationFrame延迟聚焦,避开 Vue/React 的异步 DOM 更新周期 - 配合
aria-invalid="true"和aria-describedby关联错误文案,让屏幕阅读器主动播报错误内容,而非仅移动光标 - 若错误提示是
<div> 类容器,需设 <code>tabindex="-1"并在聚焦后滚动视口使其可见(element.scrollIntoView({ block: 'nearest' }))非模态浮层不该用
侧边栏、实时预览面板、下拉菜单这类非阻断式组件,硬套
<dialog></dialog>+show()会破坏无障碍:它不创建遮罩、不拦截 Tab、不响应 Esc,Safari 还会错误宣告 “模态已开启”,导致屏幕阅读器逻辑混乱。更稳妥的替代方案:
- 用
<div role="dialog" tabindex="-1"> 替代原生 <code><dialog></dialog>,语义正确且行为可控 - 开关背景交互用
inert属性(比aria-hidden更现代、更可靠,支持焦点隔离) - 若必须保留
<dialog></dialog>标签,打开后立刻调dialog.focus(),然后马上执行document.body.focus(),否则焦点卡在空节点上 - 拖拽、缩放、最小化等交互需求,
<dialog></dialog>原生不支持,强行封装只会增加语义冗余和兼容负担
焦点管理真正的复杂点不在“怎么跳”,而在于“跳不出去”和“跳不回来”——前者要围住,后者要记牢。DOM 结构、浏览器差异、框架生命周期、辅助技术解析逻辑,四者交叠处最容易漏掉一环。
- 用
dialog.showModal() 在 Safari 中无法自动围住焦点
Safari(含 iOS/macOS 全版本)对 <dialog></dialog> 的焦点管理存在严重缺陷:showModal() 调用后,Tab 键仍会逃逸到页脚、导航栏甚至 ,aria-modal="true" 完全失效。这不是体验问题,而是焦点流未被真正拦截。
必须手动补三件事:
立即学习“前端免费学习笔记(深入)”;
嵌套 <dialog></dialog> 时更需分层管理:每层独立维护可聚焦元素列表,打开新层前暂停上一层的 trapTabKey 监听器,关闭子层后还原父层上次离开时的焦点位置,而非简单调 parentDialog.focus()。
表单验证失败时的焦点重定向容易被忽略
提交失败后把焦点移到第一个错误字段,不是锦上添花,而是无障碍刚需。但直接调 element.focus() 可能失败——如果该元素被 display: none、visibility: hidden 或 inert 阻塞,或尚未完成渲染(如动态插入的错误提示块)。
可靠做法:



















