如何通过HTML的aria-disabled属性实现元素的禁用显示？

本文共计1210个文字，预计阅读时间需要5分钟。

aria-disabled 是 ARIA 属性，仅用于向辅助技术（如屏幕阅读器）传达视觉上禁用但 DOM 元素本质上未禁用的状态。它不会阻止用户交互，也不会影响浏览器的原生行为——如点击、键盘聚焦、表单提交等。

常见误用场景：给 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" 几乎无意义——它不等价于移除禁用，也不触发任何启用逻辑，应直接移除该属性

哪些元素必须配合 JavaScript 才能真正禁用

像 div、span、a、li 这类非表单元素，没有原生 disabled 属性，想模拟禁用状态时，aria-disabled 是必要但不充分的条件。

必须同步做以下几件事，否则禁用只是“说说而已”：

立即学习“前端免费学习笔记（深入）”；

• 添加 aria-disabled="true"，让屏幕阅读器感知状态
• 设置 tabindex="-1" 阻止键盘聚焦（默认这些元素不可聚焦）
• 用 CSS 加 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 对焦点和语义的影响

aria-disabled 不改变元素是否可获得焦点，也不影响其在 DOM 中的语义层级。它的唯一作用是通知辅助技术：“这个控件当前不可用”。但浏览器不会因此跳过它，键盘 Tab 仍可能停在上面（除非你加了 tabindex="-1" 或移除了 tabindex="0"）。

• 若元素有 tabindex="0" 且设 aria-disabled="true"，它依然可被 Tab 到——这是严重可访问性缺陷
• 某些旧版 NVDA 或 JAWS 在遇到 aria-disabled="true" 的 role="button" 时，会读作“按钮，已禁用”，但不会自动跳过；而原生 button[disabled] 会被完全忽略（不进焦点环、不读）
• aria-disabled 对搜索引擎、SEO、自动化测试工具基本无影响，它们只看实际交互能力，不看 ARIA 声明

React/Vue 中容易漏掉的副作用

在组件库或封装按钮时，开发者常把 aria-disabled 当成“禁用开关”，却忘了它不联动事件绑定。比如 React 中写：

<MyButton aria-disabled={isDisabled} onClick={handleClick} />

如果 MyButton 内部没检查 aria-disabled 并主动禁用 onClick，那 isDisabled === true 时点击照样执行。

• Vue 的 v-bind 动态绑定 aria-disabled 同样不自动阻止 @click，需在方法内加守卫：if (props.disabled) return
• 使用 role="switch" 或 role="checkbox" 时，aria-disabled 必须和 aria-checked 等状态同步更新，否则屏幕阅读器会读出矛盾信息
• 服务端渲染（SSR）中若初始就设 aria-disabled="true"，但客户端 JS 还没加载，用户可能短暂看到“已禁用”却仍能点——这种竞态需要预设 CSS 或服务端也做交互拦截

真正可靠的禁用，永远建立在行为控制之上，而不是靠一个属性“声明”出来。