aria-disabled="true"仅向辅助技术传达禁用状态，不改变视觉样式，需配合css（如[aria-disabled="true"]{opacity:.5;cursor:not-allowed}）实现灰化效果；键盘仍可聚焦（勿设tabindex="-1"），js必须拦截click和keydown事件并校验aria-disabled值以阻止交互。
aria-disabled="true" 本身不改变视觉，必须配 CSS
aria-disabled="true 只是往辅助技术里塞一条状态提示，浏览器不会自动灰化、变指针或降低透明度。如果你只写这个属性，按钮看起来和正常时一模一样。
要让它“看起来禁用”，得靠 CSS 显式控制：
- 用
[aria-disabled="true"]选择器匹配元素，别用:disabled（它对非原生控件无效） - 至少设置
opacity: 0.5或filter: grayscale(0.7)+cursor: not-allowed - 避免仅靠
color: #999，对比度不足可能不满足 WCAG AA 标准
想键盘可聚焦，就不能设 tabindex="-1"
原生 button 默认可被 Tab 键聚焦；加了 aria-disabled="true" 后，只要不手动破坏，它依然能进 Tab 流——这是“软禁用”的关键前提。
常见错误是顺手加上 tabindex="-1"，以为这样更“规范”，结果直接把键盘用户挡在外面：
-
tabindex="-1"= 可脚本聚焦（.focus()），但不在 Tab 顺序中 - 真要保留聚焦能力，就别碰
tabindex，让元素保持默认可聚焦状态 - 如果元素本身不可聚焦（比如
div），才需要tabindex="0"激活它，再配aria-disabled="true"
点击和回车仍会触发，JS 必须守卫
视觉上灰了、键盘能 tab 进去、屏幕阅读器读出“已禁用”——但用户按回车或鼠标点一下，事件照样走完。这不是 bug，是 aria-disabled 的设计本意。
所以 JS 层必须做守卫：
- 监听
click和keydown（捕获 Enter/Space） - 检查
el.getAttribute('aria-disabled') === 'true'，不是el.ariaDisabled（后者是布尔值，false可能来自未设属性） - 匹配到就
evt.preventDefault(); evt.stopPropagation(); - 别只拦
click，keydown漏掉会导致键盘用户误操作
原生 button 上混用 disabled 和 aria-disabled 是危险操作
如果你在 <button disabled aria-disabled="true"></button> 这样写，读屏器可能重复播报“按钮，已禁用”，甚至报“状态冲突”。
真正需要“视觉禁用但键盘可聚焦”的场景，通常只出现在两类地方：
- 表单步骤导航中，当前步未完成，按钮不能点但需让用户知道“这里有个按钮，等你填完就能用”
- 第三方组件封装了
button，但没暴露disabledprop，你只能从外层加aria-disabled
这两种情况都绕不开手动拦截 + CSS + 状态同步。别指望一个属性搞定所有事。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
