tabindex="-1"仅移除元素在tab键导航流中的位置，不阻止点击、不改变视觉状态、不屏蔽屏幕阅读器；空格/enter无响应是因为原生交互逻辑（如按钮的空格触发）被移除且未手动补全事件监听。
tabindex="-1" 不是防止元素被键盘聚焦，而是让它“可被脚本聚焦，但不进 Tab 流”——按 Tab 键跳过它，element.focus() 却能成功聚焦。
为什么加了 tabindex="-1" 后 Tab 键跳过了，但空格/Enter 没反应？
这是最典型的误用现象：给一个 <button></button> 或 <a></a> 加 tabindex="-1"，再测试键盘操作，发现按 Tab 跳过了，按空格也不触发点击。
- 原因在于：原生可聚焦元素（如
button、a[href]、input）默认就在 Tab 流中；加tabindex="-1"是主动把它踢出去，但没动它的交互逻辑 —— 它依然能点、能提交、能响应click，只是 Tab 键再也碰不到它 - 空格/Enter 没反应，往往是因为你删掉了原本由浏览器自动绑定的事件响应（比如按钮对空格键的
keyup响应），又没手动补上keydown或keyup监听 - 正确做法：如果目标是“临时禁用”，该用
disabled；如果目标是“不让 Tab 进来，但代码里要 focus 它”，才用tabindex="-1，且必须确保它本身语义正确、事件监听完整
哪些元素真该设 tabindex="-1"？
只在非原生可聚焦、又需要程序化接管焦点的容器或占位元素上用 —— 它不是修饰符，是“焦点入口开关”。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 模态框根容器：
<div role="dialog"> 本身不可聚焦，加 <code>tabindex="-1"后才能.focus()，把键盘焦点拉进弹层 - 下拉菜单的外层
<div class="dropdown">：它不该被 Tab 到，但展开后需 <code>.focus()到第一个选项，此时容器本身设tabindex="-1"是合理起点 - 锚点定位目标：
<section id="faq"></section>这类语义化但不可聚焦的块级元素，加tabindex="-1"才能用document.getElementById('faq').focus()滚入视口并触发读屏 - 绝对不要给
input、select、button加tabindex="-1"：它们默认可聚焦，加了反而可能让辅助技术识别异常，且破坏表单提交行为 - 现代方案：
element.focus({preventScroll: true})可禁用滚动，但 Safari 当前仍不支持该选项 —— 传入对象参数会静默失败（焦点仍能设上，但没报错） - 兼容写法需检测支持性：
if ('preventScroll' in FocusOptions.prototype) { element.focus({preventScroll: true}); } else { element.focus(); } - 注意：
preventScroll不解决元素隐藏问题 —— 若元素display: none或visibility: hidden，focus()本身就会失败，无论是否带参数
focus() 调用后页面突然滚动，怎么稳住？
调用 element.focus() 默认会强制滚动使元素进入视口，这在固定头部、长列表或侧边栏场景下极易引发界面“跳闪”。
真正容易被忽略的点是：tabindex="-1" 从不改变元素的视觉状态、不阻止点击、不屏蔽屏幕阅读器，它只动了一件事——Tab 键的路径。想控制其他行为，得靠 disabled、inert、aria-hidden 或 CSS 配合，不能指望一个属性包打天下。
