如何确保禁用表单元素在无障碍访问中仍可被屏幕阅读器识别

禁用的表单控件（如 `disabled` 的 ``、``、`` 或 ``）默认不

接收 tab 键焦点，这是符合 html 规范与 wcag 实践的正确行为；但屏幕阅读器用户仍可通过其他导航方式（如方向键或语义快捷键）定位并获取其状态信息。

在 Web 无障碍（a11y）测试中，一个常见误区是认为所有可见控件都必须能通过 Tab 键聚焦。实际上，HTML 标准明确规定：disabled 属性会使元素既不可交互，也不参与顺序键盘导航（即不进入 Tab 序列）。例如以下代码：

该输入框将被浏览器自动排除在 tabindex 流之外——这是预期且合规的行为，不应视为缺陷。

✅ 正确理解：

• ✅ disabled 元素不接收 Tab 焦点 → 符合规范（HTML Living Standard § 6.7.3）
• ✅ 屏幕阅读器（NVDA、JAWS、VoiceOver）仍可读取其标签、值和 disabled 状态（需配合 或 aria-label）
• ✅ 用户可通过屏幕阅读器专属导航方式访问：
  • 向下箭头键（↓）：逐个遍历 DOM 节点（虚拟光标模式）
  • E 键（Elements List）：快速跳转到下一个表单控件（NVDA/JAWS 默认）
  • B 键：跳至按钮，C 键：跳至复选框，R 键：跳至单选按钮（支持语义导航的屏幕阅读器）

⚠️ 注意事项：

• ❌ 不要为 disabled 元素添加 tabindex="0" —— 这会破坏语义一致性，导致键盘用户可聚焦却无法操作，违反 WCAG 2.1 SC 2.1.1（Keyboard）。
• ✅ 若需让“只读但可见”的内容参与 Tab 导航，请改用 readonly + tabindex="0"（适用于文本输入），并确保视觉样式明确传达其不可编辑性。
• ✅ 对于禁用的复选框/单选按钮，务必确保其 关联正确（使用 for/id 或嵌套），以便屏幕阅读器准确播报“已禁用”状态（现代读屏会自动朗读 disabled）。

? 总结：
Tab 键跳过 disabled 表单控件不是缺陷，而是规范实现。无障碍验收重点应转向：

1. 控件是否具备清晰的语义标签（ 或 aria-label）；
2. 是否正确暴露 disabled 状态（无需额外 ARIA，原生属性已足够）；
3. 是否提供替代导航路径（如结构化列表、标题跳转）以保障信息可达性。
   真正的可访问性，不在于“所有元素都能 Tab 到”，而在于“所有用户都能可靠地发现、理解并响应界面状态”。