禁用的表单控件（如 disabled 的 、
在无障碍测试中，常遇到这样的疑问：当一个输入框被设置为 disabled（例如 ），按 Tab 键时焦点无法到达该元素——这是否为缺陷？答案是否定的。HTML 规范明确规定，disabled 表单控件不属于可聚焦的“tabbable”元素，因此不会出现在 Tab 键顺序流（tab order）中。这是有意为之的设计，目的是防止用户尝试与不可交互的控件进行无效交互。
但这并不意味着禁用控件对辅助技术“不可见”。屏幕阅读器（如 NVDA、JAWS、VoiceOver）仍能通过以下方式访问它们：
- ✅ DOM 顺序导航：使用方向键（↓ / ↑）逐个遍历页面内容，禁用元素会被朗读（如 “Value, edit text, disabled”）；
- ✅ 元素快捷键导航：
- 按 E（NVDA/JAWS）跳转到下一个表单控件（含 disabled 元素）；
- 按 X 跳转到下一个复选框（包括禁用状态）；
- 按 R 跳转到下一个单选按钮（包括禁用状态）；
- ✅ 虚拟光标/浏览模式：在 VoiceOver（macOS/iOS）或 NVDA 浏览模式下，禁用控件仍会作为可读内容被包含在语义树中。
⚠️ 注意事项：
- 不要为禁用控件添加 tabindex=”0″ 强行使其可 Tab 聚焦——这违反无障碍原则，会导致键盘用户陷入“可聚焦却不可操作”的困惑状态，且可能破坏焦点管理逻辑；
- 若需让用户感知禁用原因，应通过 aria-describedby 关联说明性文本（如 +
当前不可编辑：权限不足
）；
- 禁用的复选框/单选按钮同样遵循相同规则：不参与 Tab 流，但支持屏幕阅读器语义导航；若完全隐藏（如 display: none 或 aria-hidden=”true”），则既不可 Tab 也不可被读取——这通常不是预期行为。
✅ 正确实践示例：
邮箱已由系统自动填写，不可修改
总结：Tab 键跳过 disabled 元素不是缺陷，而是规范要求；真正的无障碍重点在于确保禁用控件语义完整、上下文可理解、状态可感知。开发者应优先完善 aria-* 属性、提供清晰的禁用说明，并避免通过 tabindex 破坏原生语义逻辑。