无障碍问题常藏在看似顺手的细节里：按钮只能用鼠标点击，输入框报错却不说明原因，键盘焦点也可能在弹窗打开后消失。应用无障碍交互设计的关键要求，不是额外添加一种操作方式，而是让不同用户都能看懂状态、完成操作，并知道下一步该做什么。
常见误区：看起来可用，不等于操作完整
- 只检查颜色。用红色标错误、绿色标成功，却没有文字或图标说明，色觉差异用户可能无法区分。状态应同时通过文字、形状或位置表达。
- 认为有键盘快捷键就够了。用户还需要能用 Tab、Shift+Tab、Enter、空格和方向键完成主要操作，并随时看清当前焦点。
- 把提示当作装饰。占位文字可能在输入后消失，不能代替字段名称；弹出的成功或错误消息也不能只靠颜色传达。
- 所有控件都能聚焦就算合格。焦点顺序若与页面阅读和操作顺序不一致，用户仍可能迷路；弹窗关闭后，焦点还应回到触发它的控件。
应用无障碍交互设计的关键要求，是让控件名称、状态和操作结果能够被感知，也让流程可以通过不同输入方式完成。可访问名称应说明控件用途，例如“提交订单”，而不是只读出“按钮”。
按步骤检查键盘操作
- 先不用鼠标。刷新页面后，仅用键盘完成一项核心任务，例如搜索、填写表单并提交。若中途必须点击鼠标，记录对应控件和步骤。
- 逐项按 Tab。确认焦点按合理顺序移动，且当前焦点有明显视觉标记。用 Shift+Tab 反向检查，避免焦点跳过链接、按钮或输入项。
- 测试控件操作。链接通常用 Enter 激活；按钮应能用 Enter 或空格操作；单选项、菜单等复合控件则按其常见键盘交互检查方向键等操作。
- 检查弹窗与动态变化。打开对话框后，焦点应进入对话框；关闭后回到触发位置。展开折叠内容、提交表单后，也要确认焦点没有无故跳到页面顶部。
- 处理键盘陷阱。在弹窗或菜单内，用户应能按预期离开或关闭；如果焦点被限制在弹层中，应提供清晰、可操作的关闭方式。
提示与读屏：检查信息有没有送达
让错误信息可定位、可修正
表单检查可逐项触发必填、格式错误和提交失败状态。提示要指出具体字段及修正方法，例如“邮箱地址格式不正确，请检查@后的域名”；同时把错误关联到对应输入框，并保留用户已输入的内容。只在页面顶部写“提交失败”，却不指出问题位置，通常不足以帮助用户完成修正。
用辅助技术复核名称和状态
使用屏幕阅读器按顺序浏览页面，检查控件是否读出名称、类型和必要状态，例如复选框是否已选、按钮是否禁用。图像若承载信息，应有恰当的替代文本；纯装饰图像则不应造成重复朗读。动态提示还应在内容变化时能被辅助技术感知，但避免把每个细小变化都变成打断用户的播报。
也可按 WCAG 的对比度标准检查文字：一般文本达到 4.5:1，大号文本达到 3:1，是常见的 AA 级参考要求。对比度合格并不能代替键盘和读屏测试，三类检查需要分别完成。
把检查结果变成可复测清单
记录具体页面、操作步骤、预期结果和实际结果，例如“打开确认框—按 Tab—焦点未显示”。修复后用相同步骤复测，并在桌面浏览器及计划支持的平台上检查。自动化扫描适合发现部分结构和对比度问题，但不能判断提示是否清楚、焦点是否符合用户任务顺序。
归根结底，应用无障碍交互设计的关键要求可以落到三件事：键盘能完成任务，焦点走向可预测，提示明确且能被读出。把它们纳入每次功能验收，比发布后再补救更可靠。
常见问题
只用键盘测试可以代替读屏测试吗？
不可以。键盘测试关注操作路径，屏幕阅读器测试还要检查名称、状态和动态提示是否能被感知。
占位文字能代替输入框标签吗？
不建议。占位文字可能在输入后消失，也可能对比度不足；应保留可识别的字段名称。
焦点一定要限制在弹窗里吗？
模态弹窗通常需要让键盘操作留在弹窗范围内，并提供关闭方式；关闭后应把焦点还给打开弹窗的控件。
自动化扫描通过就代表无障碍吗？
不是。扫描只能覆盖部分问题，仍需人工完成键盘操作、屏幕阅读器和提示内容检查。