禁用控件无需被tab聚焦，关键在于保障其名称、角色、值三要素齐备且语义正确；需配label或aria-label、aria-describedby说明原因，并确保value属性初始存在。
禁用的表单控件（如 disabled 的 <input>、<button></button>）本身**不需要也不应该被 Tab 键聚焦**，这是规范行为而非缺陷；真正的问题在于：用户能否感知它“存在”、知道它“为什么不可用”、理解它“值是什么”。
disabled 元素为何在屏幕阅读器里“消失”了？
不是 disabled 导致不可见，而是语义缺失让辅助技术无从读起。常见断点：
-
label缺失或for/id不匹配——屏幕阅读器根本不知道这个输入框叫什么 - 父容器加了
aria-hidden="true"或 CSSdisplay: none/visibility: hidden——整块内容被辅助技术树直接剔除 -
disabled元素没绑定label，又没设aria-label——读屏只报“编辑框”，不报字段名和值 - 值是动态注入的（如 JS 填入），但 DOM 中没初始
value属性——读屏只读空字符串
如何让 disabled 控件既“不可操作”又“可感知”？
核心是三要素齐备：**名称（Name）、角色（Role）、值（Value）**。原生 disabled 已隐含 aria-disabled="true"，无需重复添加。
- 必须配
<label for="xxx">配置值</label>，且for="xxx"与<input id="xxx">完全一致（大小写、连字符、空格都不能差） - 若 label 不能显示文字，用
aria-label="配置值"替代，但别覆盖原意（例如不要只写aria-label="已禁用"） - 用
aria-describedby指向解释性文本，比如：<div id="reason">邮箱由系统自动填写，不可修改</div>，再在 input 上写aria-describedby="reason" - 确保
value属性在 HTML 中就存在（哪怕 JS 后续会改），否则 TalkBack/NVDA 可能完全跳过该节点
视觉禁用样式 + 无障碍提示必须同步
灰阶、低透明度等视觉反馈只是辅助，不能替代语义。容易被忽略的关键点：
- 禁用状态的 CSS 样式（如
opacity: 0.5）不能搭配pointer-events: none——后者会阻断屏幕阅读器的结构导航键（如 NVDA 的 E 键）识别 - 不要用
::after伪元素添加“（已锁定）”字样——它不在 DOM 中，无法被读屏访问 - 如果设计要求隐藏 label 文字，用
clip-path: inset(100%)或绝对定位缩微，**绝不用display: none或visibility: hidden** - 对
type="checkbox"或type="radio"组合，禁用整个<fieldset></fieldset>并配<legend></legend>，比单独禁用每个控件更可靠
最常漏掉的是：禁用控件的“上下文解释”没进 DOM，或者解释文本没用 aria-describedby 关联。只要值、名称、原因三者都固化在 HTML 结构里，即使它不能 Tab 进去，屏幕阅读器用户也能准确说出“配置值，已禁用，当前值为 100，原因：由系统自动填写”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
