前端无障碍与键盘交互

无障碍设计让不同能力和不同设备上的用户都能理解并操作页面。语义结构、键盘行为和清晰反馈不仅服务于辅助技术，也能让普通用户在键盘操作、弱网和小屏环境下更顺畅。

一、优先使用原生语义元素

按钮负责触发操作，链接负责导航，表单控件负责输入。原生元素自带键盘行为和语义，通常比使用通用容器再补大量属性更可靠。

<button type="button">保存设置</button>

如果控件只是执行动作，不要用链接伪装按钮；如果需要跳转，也不要用没有导航行为的按钮代替链接。

二、为表单控件提供名称

可见标签应与输入框关联，错误提示也应能被辅助技术读取。占位文字会在用户输入后消失，不能代替持久标签。

<label for="display-name">显示名称</label>
<input id="display-name" name="displayName" autocomplete="name">

必填、格式和错误状态应以文字说明，不要只通过颜色区分。错误消息最好通过字段描述关系关联到对应控件。

三、确保完整的键盘操作

所有交互都应可以通过键盘到达和操作，焦点顺序应符合页面阅读顺序。自定义菜单、对话框和组合控件要实现明确的方向键、确认和退出行为。

:focus-visible {
    outline: 3px solid #2563eb;
    outline-offset: 2px;
}

不要为了视觉整洁移除焦点轮廓而不提供替代样式。模态对话框打开时应把焦点移入，关闭后将焦点还给触发它的控件。

四、正确使用 ARIA

ARIA 用来补充原生语义，不会自动赋予元素完整行为。给一个通用容器添加按钮角色后，仍需要实现键盘操作、焦点和禁用状态。优先选择语义正确的原生控件。

状态属性应随真实状态同步。例如展开按钮的展开属性、选项的选中状态不能只在初始渲染时设置。

五、控制动态内容和动画

加载结果、错误提示和操作完成状态可以使用适当的实时区域通知用户，但不要让每个细小变化都触发播报。动画应支持减少动态效果偏好的用户，避免持续闪烁或快速重复运动。

六、用多种方式检查

自动化工具能发现部分缺少标签、对比度和结构问题，但无法判断操作流程是否合理。还应手动验证键盘路径、焦点可见性、错误恢复和页面缩放；关键场景可配合屏幕阅读器检查。

七、焦点管理决定页面切换是否可理解

对话框打开后，焦点应进入对话框，并限制键盘顺序在对话框内容内；关闭时返回触发控件。路由切换后，将焦点移动到新页面标题或主内容起点，并更新文档标题。若只是视觉上切换页面，焦点仍停留在已卸载控件，键盘用户会失去上下文。

表单提交失败时，错误摘要可列出字段和原因，并提供能聚焦到对应控件的操作。不要把焦点自动来回跳动；用户修改一个字段后，应保留稳定的输入位置。

八、颜色、对比度和非文本状态

正文、辅助文字、边框和图标都要考虑对比度。禁用、选中、错误和必填状态不能只用颜色区分，还要配合文本、图标、形状或语义属性。焦点轮廓应在浅色、深色和高对比度环境中都能辨认。

动态内容更新可以通过实时区域通知，但通知频率要控制。一次请求导致几十个逐字变化时，重复播报会干扰用户；应选择总结性状态或关键结果。

九、键盘陷阱和自定义控件

自定义菜单、标签页和列表框需要符合各自的键盘模型。Tab 用于进出控件组，方向键可在组内切换；Escape 通常关闭临时层。实现前先确认原生按钮、选择框或单选组是否已经满足需求。

十、建立无障碍回归流程

自动工具可检查缺少名称、颜色对比和部分结构问题；手动测试仍需覆盖仅键盘操作、放大缩放、屏幕阅读器和错误恢复。核心组件的交互约定进入组件库后，每次变更都应回归焦点顺序和状态通知。

实施中的取舍与复核

无障碍交互从正确的原生语义开始。按钮执行动作，链接切换位置，表单控件提供标签；不应把普通容器加上可聚焦属性就当成可访问控件。自定义菜单、弹窗和组合框会引入焦点管理、方向键行为、关闭方式和读屏状态等额外责任，应优先使用平台原生能力，并用真实键盘和辅助技术验证实现。

焦点顺序应与视觉阅读顺序一致。打开对话框时将焦点移入合适位置，限制焦点不意外跑到背景；关闭后把焦点还给触发者，若触发项已不存在则选择合理后继位置。页面切换或异步加载后，焦点不应留在已卸载节点。仅靠自动聚焦可能打断读屏用户，应结合操作场景决定是否移动焦点，并避免每次状态更新都重置它。

键盘操作需要覆盖 Tab、Shift+Tab、Enter、空格、方向键和 Escape 等常见预期。自定义控件应防止按键默认行为造成重复提交或滚动冲突；禁用状态必须同时反映视觉和程序语义。拖拽、滑块等指针交互还要提供键盘或按钮替代方案。若快捷键与浏览器、屏幕阅读器冲突，应允许用户通过常规操作完成相同任务。

动态反馈应能被辅助技术感知，但不应过度播报。提交成功、错误数量变化和加载完成可以使用适当的状态区域；连续输入时不要每个字符都重复朗读验证消息。错误摘要应能跳转到相关字段，字段提示与错误通过程序关系关联。颜色对比、缩放、减少动态效果和高对比设置也要纳入验收。

验收时沿完整任务流程操作：仅键盘进入页面、填写表单、触发错误、修正并完成提交，然后重新加载或切换页面。可结合自动检查发现缺失标签和结构问题，但自动化无法判断说明是否易懂、焦点是否符合预期。团队可把键盘路径、焦点回归、语义标签和读屏验证纳入组件库文档，让每个新页面复用成熟行为。

复核案例与后续维护

把无障碍纳入组件接口可以减少页面之间的行为差异。组件应说明可访问名称来自何处、哪些按键可用、焦点如何进入和离开，以及禁用状态如何体现。设计系统提供的弹窗、菜单和表单控件先通过键盘及读屏检查，再交给业务页面组合；业务调用方仍需提供有意义的文本和标签。

复杂组件适合遵循成熟的键盘模式，但不能机械套用。单选组、菜单和表格的方向键预期不同，焦点移动还要与屏幕阅读器浏览模式兼容。快捷键需避免占用浏览器常用功能，并给用户退出或关闭入口。拖拽排序、滑块和图表交互应提供可替代的操作方式。

自动化工具可以发现缺少名称、颜色对比不足或结构异常，却无法确认错误说明是否清楚、焦点是否打断用户。手工验收应由只用键盘完成任务开始，再使用常见读屏工具检查反馈；让辅助技术用户参与验证能发现真实流程中的障碍。验收记录应描述具体动作和预期结果，而非只写“已支持无障碍”。

页面更新时，实时提示应保持克制。错误摘要可以汇报一次，随后用户在字段间移动时仍可查看具体说明；列表新增内容可以通知，但无需逐项播报所有数据。对于动画、音频和倒计时，提供暂停或延长方式。持续收集用户反馈并修正组件库，避免无障碍只在专项发布前被临时检查。

持续维护要点

交互设计的无障碍验收要包括放大文字和减少动画设置。布局变宽后控件仍可读，动画关闭后状态变化仍能理解；键盘用户可以完成同一业务任务。记录失败步骤、使用方式和预期焦点位置，修复后由另一位验收者完整复走流程。

验收补充

新页面的验收清单可以包含无鼠标完成主流程、焦点可见、文本放大后无裁切和错误能被辅助技术读出。页面上线后保留反馈渠道，辅助技术用户报告的障碍按功能缺陷排期修复，而不是只记录在可访问性专项文档中。

发布后的观察

交互组件的无障碍行为需要在设计变更时回归，而不是只在首次开发验收。组件更新焦点策略后检查所有消费页面，尤其是对话框嵌套和动态列表；新键盘快捷键记录冲突及退出方式。问题修复完成后保留操作录制和预期焦点路径，方便版本升级时重复检查。

总结

无障碍从正确语义和键盘操作开始。控件有清楚名称，焦点可见且顺序合理，自定义交互实现完整键盘行为，动态状态及时传达。自动检查与实际操作验证结合，才能发现真实使用障碍。