aria-disabled不能替代disabled属性:它仅向辅助技术传达禁用状态,不阻止交互、不改变行为;原生表单元素必须用disabled,自定义控件需配合tabindex="-1"、CSS和JS事件拦截才能真正禁用。
aria-disabled 是 ARIA 属性,仅用于向辅助技术(如屏幕阅读器)传达“视觉上禁用但 DOM 元素本身未真正禁用”的状态。它不会阻止用户交互,也不会影响浏览器原生行为——点击、键盘聚焦、表单提交照常发生。如果你能用原生 disabled 属性,就绝不要用 aria-disabled。
常见误用场景:给 div 或 span 加 aria-disabled="true" 却没手动禁用鼠标事件和键盘响应,导致屏幕阅读器说“已禁用”,但用户仍可点击或按回车触发操作。
button 元素)需同时设置:aria-disabled="true" + tabindex="-1" + pointer-events: none(CSS)+ 手动拦截 click 和 keydown
button、input、select 等原生表单控件,直接用 disabled 属性即可,aria-disabled 不仅多余,还可能与 disabled 冲突导致读屏行为异常aria-disabled="false" 几乎无意义——它不等价于移除禁用,也不触发任何启用逻辑,应直接移除该属性像 div、span、a、li 这类非表单元素,没有原生 disabled 属性,想模拟禁用状态时,aria-disabled 是必要但不充分的条件。
必须同步做以下几件事,否则禁用只是“说说而已”:
立即学习“前端免费学习笔记(深入)”;
aria-disabled="true",让屏幕阅读器感知状态tabindex="-1" 阻止键盘聚焦(默认这些元素不可聚焦)pointer-events: none 拦截鼠标,或在 JS 中 event.preventDefault() + stopPropagation()
keydown(尤其是 Enter/Space),避免键盘意外触发cursor: not-allowed)同步反馈示例片段:
<div role="button" aria-disabled="true" tabindex="-1">删除项目</div>
这行 HTML 本身完全不防交互——必须配 JS 绑定事件拦截,否则用户一按回车就删了。
aria-disabled 不改变元素是否可获得焦点,也不影响其在 DOM 中的语义层级。它的唯一作用是通知辅助技术:“这个控件当前不可用”。但浏览器不会因此跳过它,键盘 Tab 仍可能停在上面(除非你加了 tabindex="-1" 或移除了 tabindex="0")。
tabindex="0" 且设 aria-disabled="true",它依然可被 Tab 到——这是严重可访问性缺陷aria-disabled="true" 的 role="button" 时,会读作“按钮,已禁用”,但不会自动跳过;而原生 button[disabled] 会被完全忽略(不进焦点环、不读)aria-disabled 对搜索引擎、SEO、自动化测试工具基本无影响,它们只看实际交互能力,不看 ARIA 声明在组件库或封装按钮时,开发者常把 aria-disabled 当成“禁用开关”,却忘了它不联动事件绑定。比如 React 中写:
<MyButton aria-disabled={isDisabled} onClick={handleClick} />
如果 MyButton 内部没检查 aria-disabled 并主动禁用 onClick,那 isDisabled === true 时点击照样执行。
v-bind 动态绑定 aria-disabled 同样不自动阻止 @click,需在方法内加守卫:if (props.disabled) return
role="switch" 或 role="checkbox" 时,aria-disabled 必须和 aria-checked 等状态同步更新,否则屏幕阅读器会读出矛盾信息aria-disabled="true",但客户端 JS 还没加载,用户可能短暂看到“已禁用”却仍能点——这种竞态需要预设 CSS 或服务端也做交互拦截真正可靠的禁用,永远建立在行为控制之上,而不是靠一个属性“声明”出来。