aria-disabled="true" 不允许聚焦，因规范要求其从键盘焦点流中移除，强行聚焦会导致无障碍体验断裂；正确做法是用 css 灰化 + aria-busy="true" + 事件拦截替代。
不能允许聚焦。aria-disabled="true" 的设计本意就是“视觉禁用 + 语义禁用”，但又不阻断交互——如果你需要它可聚焦，说明你根本没理解它的用途，或者你真正想要的是别的东西。
aria-disabled="true" 为什么不能聚焦
规范明确要求：当元素处于 aria-disabled="true" 状态时，它应当从键盘焦点流中移除。浏览器和屏幕阅读器都按此逻辑处理。强行加 tabindex="0" 或 tabindex="-1" 后调用 .focus()，会导致：
- 键盘用户 Tab 到一个“已禁用”却能聚焦的元素，无法操作，体验断裂
- 读屏器读出“按钮，已禁用”，但焦点停在上面，用户困惑“那我该按什么？”
- 部分读屏器（如 NVDA）会直接跳过
aria-disabled="true"元素，无论 tabindex 值是多少
你真正想实现的，其实是“视觉灰化但保持可操作”
这不是 aria-disabled 的场景，而是“临时不可用但需保留焦点路径”的典型需求。正确做法是：
- 去掉
aria-disabled="true"，改用 CSS 控制灰化：[data-state="pending"] { opacity: 0.5; pointer-events: none; } - 用
aria-busy="true"表明“正在处理中”，读屏器会播报“忙”而非“禁用” - 保留原生可聚焦能力（比如 button 本身就有），不加任何 tabindex
- JS 中拦截 click/keydown，避免重复提交，但不阻止聚焦
哪些情况真需要“禁用但可聚焦”？几乎不存在
无障碍标准里没有“禁用但可聚焦”的合法模式。如果你遇到以下情形，大概率是设计或交互逻辑出了问题：
- 分页组件中“下一页”按钮灰化但希望键盘用户能 Tab 到它——应改为始终启用，点击时拦截并提示“已是最后一页”
- 表单提交按钮在 loading 状态下灰化——用
aria-busy="true"+aria-label="提交中，请稍候"，而不是aria-disabled - 自定义树节点展开图标禁用时还想被聚焦——说明这个图标不该是焦点目标，焦点应落在父级可操作容器上
真正容易被忽略的点：禁用状态的本质不是“不让用户看见”，而是“当前上下文下无意义”。如果一个控件需要被聚焦、被感知、被解释，那它就不该被标记为禁用——哪怕只是视觉上灰掉。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
