tabindex="0"是使非原生元素进入Tab流的唯一合理方式,需同步添加role、keydown监听和:focus样式;tabindex="-1"用于动态聚焦,禁用正整数tabindex,聚焦顺序应由DOM结构决定。

tabindex="0" 是让非原生元素进 Tab 流的唯一合理方式
原生可聚焦元素( 但加了 它让元素不能被 Tab 键触达,但能被 常见错误是:模态框打开后调用 关键操作点: 它不是“提前排队”,而是把所有正数元素强行插到 Tab 流最前面,并按数值升序排列。结果往往是:用户从顶部开始 Tab,突然跳到页脚的 把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件(幻灯片风格)。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本,并且希望生成演示用的 HTML 时触发。支持任意内容来源:iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区,并通过企微直接发送给用户。触发词示例:帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。 更麻烦的是动态场景: 键盘导航的预期路径,本质是用户阅读/操作的逻辑流:筛选区按钮应在筛选结果上方,提交按钮应在表单底部。这不是靠 容易被忽略的细节:、、)默认就在 Tab 流里,加 tabindex="0" 不仅多余,还可能干扰 SSR 或框架 hydration 一致性。只有 这类语义容器需要手动加入时才用它。tabindex="0" 并不等于“能用了”——必须同步做三件事:
role 属性,比如 role="button",否则屏幕阅读器读作“无角色元素”keydown,对 Enter 和空格键(' ')都做响应,并调用 e.preventDefault() 防止空格滚动页面:focus-visible 或至少 :focus 样式,否则键盘用户完全看不到焦点在哪tabindex="-1" 是动态聚焦的唯一安全入口
element.focus() 主动聚焦。这是模态框、折叠面板、下拉菜单等场景的核心机制。modal.querySelector('button').focus() 失败,控制台没报错,焦点也没动——大概率因为那个按钮是 tabindex="-1",导致 .focus() 无效。
tabindex="-1",其他保持默认aria-hidden="true" 同时用——前者允许聚焦,后者告诉读屏软件忽略,两者冲突focus({ preventScroll: true }) 在 Safari 中不支持,传对象参数会静默失败;生产环境建议先检测:if ('preventScroll' in FocusOptions.prototype)
正整数 tabindex(如 1、2、999)必须禁用
tabindex="1" 按钮,再按一次又回到顶部的另一个 tabindex="1" —— 完全脱离视觉和语义顺序。
tabindex="1",浏览器只保留第一个,其余降级为 tabindex="0",顺序不可控真正可控的聚焦顺序靠 DOM 位置 + tabindex="0"
tabindex “拖拽”出来的,而是靠 HTML 结构本身表达的。
CSS order 或 flex-direction: column-reverse 改变视觉顺序时,DOM 顺序不变 → 键盘导航和读屏仍按原始 DOM 走,必须同步调整 HTML 结构visibility: hidden 或 opacity: 0 的元素不会自动退出 Tab 流,需手动加 tabindex="-1" 或 aria-hidden="true"
display: none 的元素自动脱离焦点流,但 JS 调用 .focus() 会静默失败,哪怕有 tabindex="-1"
document.activeElement 检查当前焦点,比肉眼 Tab 测试更可靠,尤其在异步渲染后
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!










