禁用的表单控件（如 disabled 的 、
在无障碍（a11y）测试中，一个常见误区是认为“所有可见控件都必须能被 Tab 键聚焦”。实际上，HTML 标准明确规定：disabled 属性会使元素既不可交互，也不可聚焦（包括 Tab 导航）。因此，以下代码的行为完全合规：
自动模式 通知已关闭
✅ 正确表现：
- Tab 键跳过这些元素（不获取焦点）；
- 屏幕阅读器（如 NVDA、JAWS、VoiceOver）仍能通过 结构导航（Structure Navigation） 发现它们：
- 按 ↓ / ↑ 键逐个遍历 DOM 节点；
- 按 E 键（NVDA/JAWS）跳转到下一个编辑字段（即使 disabled，也会朗读其标签和值）；
- 按 B 键跳转到按钮、C 键跳转到复选框等（取决于屏幕阅读器快捷键设置）。
⚠️ 关键注意事项：
- 必须提供清晰的视觉与语义反馈：禁用状态需通过样式（如低透明度、灰阶色）+ aria-disabled="true"（仅当使用自定义控件时）明确传达；原生 disabled 已隐含 aria-disabled="true"，无需重复添加。
-
确保关联标签（label）存在且正确绑定：
这样屏幕阅读器会朗读“配置值，已禁用，文本输入，100”。
-
避免错误替代方案：
❌ 不要移除 disabled 并用 tabindex="-1" + CSS 禁用交互——这破坏语义，且 tabindex="-1" 仍可能被意外聚焦；
❌ 不要为禁用元素添加 tabindex="0"——这违反规范，导致键盘焦点停驻却无法操作，引发 WCAG 2.1 2.1.1（键盘）和 4.1.2（名称-角色-值）失败。
? 缺陷修复建议：
- 若测试中发现禁用控件“完全不可被屏幕阅读器感知”，问题往往不在 disabled 本身，而在于：缺失
- 对于需要“只读但可聚焦”的场景（如展示型表单），应改用 readonly 属性（支持 Tab 导航，且保持语义为可读不可编辑）：
总结：disabled 元素不接收 Tab 焦点是标准、合理、无障碍友好的设计。真正的无障碍重点在于——让所有用户（无论是否使用键盘或屏幕阅读器）都能一致、准确地理解控件的存在、状态与含义。
