禁用的表单控件（如 `disabled` 的 ``、`
在 Web 无障碍实践中，disabled 属性的核心语义是「不可交互、不可编辑、不可提交」。因此，浏览器会主动将该元素从Tab 键顺序（tabindex order） 中移除——这是完全符合预期的设计，而非缺陷。例如以下代码：
<input class="value" type="text" disabled id="value" value="已锁定金额">
该输入框不会被 Tab 键聚焦，但屏幕阅读器（如 NVDA、JAWS 或 VoiceOver）仍能通过以下方式访问它：
- 向下/向上方向键：逐个遍历 DOM 节点（阅读模式下按 ↓ 键可线性扫描所有可读内容）；
-
结构导航快捷键：
- NVDA/JAWS：按 E 键跳转到下一个编辑字段（包括 disabled 输入框）；
- VoiceOver（macOS）：使用 Ctrl + Option + Right Arrow 在元素间移动，或启用「Web 转子」选择「表单控件」类别后浏览；
- ARIA 属性增强（可选）：若需更明确传达状态，可补充 aria-disabled="true"（虽非必需，但可提升兼容性）：
<input class="value" type="text" disabled aria-disabled="true" id="value" value="已锁定金额" aria-label="订单总额（只读）">
⚠️ 注意事项：
- ❌ 不要为 disabled 元素设置 tabindex="0" 或 tabindex="1" —— 这会破坏语义一致性，导致键盘用户可聚焦却无法操作，违反 WCAG 2.1 SC 2.1.1（键盘）和 SC 4.1.2（名称、角色、值）；
- ✅ 若业务逻辑要求用户「感知但不可编辑」，优先使用 readonly + aria-readonly="true" 替代 disabled（此时元素仍可 Tab 聚焦，且保持只读语义）；
- ✅ 对于禁用的复选框/单选按钮（<input type="checkbox|radio" disabled>），同样不参与 Tab 导航，但屏幕阅读器可通过结构导航识别其 name、checked 状态及 disabled 属性，从而播报类似「已选中，禁用」的信息。
✅ 总结：disabled 元素跳过 Tab 焦点不是缺陷，而是规范行为；无障碍测试应验证屏幕阅读器能否准确播报其标签、值与禁用状态，而非强制其接收 Tab 焦点。真正的缺陷是缺失关联 <label>、未提供上下文说明，或错误地用 CSS pointer-events: none 模拟禁用却未添加 disabled 属性。
