7.9 KiB
7.9 KiB
Windows 输入与无障碍基线
目录
- 输入等价性
- 键盘与焦点
- 鼠标、触控、笔与拖拽
- UI Automation 语义
- 视觉与认知无障碍
- 状态、错误与计时
- 无障碍测试矩阵
- 官方资料
1. 输入等价性
确保所有主要场景都能只用键盘完成。指针悬停、右键、触控轻扫、笔桶形按钮、拖放和手势可以加速任务，但不得成为完成任务的唯一方式。
优先使用标准控件，因为它们已经实现大量焦点、键盘、指针、触控和 UI Automation 行为。为每个自定义控件定义：
- 自动化角色、名称、值、状态和支持的模式；
- Tab 停靠点和内部方向键行为；
- 键盘激活和 Escape 行为；
- 指针光标、悬停、按下和上下文菜单行为；
- 触控目标、操作阈值和手势替代方式；
- 焦点视觉、选中视觉和高对比度渲染。
2. 键盘与焦点
- 将可操作元素放入 Tab 顺序；让标签和装饰元素退出该顺序。
- 让 Tab 顺序与视觉和阅读顺序一致。优先使用自然布局/声明顺序，仅在纠正确认存在的问题时显式覆盖焦点顺序。
- 在列表、菜单、单选组、标签页和网格等复合控件内部使用方向键。
- 窗口、页面、对话框或任务界面打开时，将初始焦点设置到最有用且安全的元素。
- 浮出控件或对话框关闭时将焦点返回调用者。删除后，将焦点移动到可预测的相邻项或稳定容器。
- 保持平台焦点视觉可见。不要只用轻微颜色变化表达焦点。
- 为可见命令和表单导航使用访问键；为频繁或标准操作使用键盘快捷键。
- 在菜单和工具提示中显示快捷键，帮助用户学习命令。
- 允许 Escape 关闭可解除界面或取消当前临时模式。不得静默丢弃未保存工作。
- 确保 Enter 和 Space 按标准控件行为激活控件；不要发明冲突的按键语义。
仅当命令真正具有熟悉含义时使用常见快捷键：
| 快捷键 | 预期含义 |
|---|---|
Ctrl+N |
根据场景新建项目/文档/窗口 |
Ctrl+O |
打开 |
Ctrl+S |
保存 |
Ctrl+Z / Ctrl+Y 或 Ctrl+Shift+Z |
撤销/重做，并与应用领域保持一致 |
Ctrl+F |
搜索或查找 |
F5 |
在刷新有意义时刷新 |
Delete |
删除选中项，并根据后果提供撤销或确认 |
Alt+Left |
应用存在导航历史时后退 |
F6 |
在复杂工作区的主要窗格间移动 |
不要覆盖操作系统或辅助技术快捷键。
3. 鼠标、触控、笔与拖拽
鼠标与指针
- 使用悬停进行预览或加速，但不要把命令的唯一入口隐藏在悬停中。
- 为对象特定命令提供上下文菜单，同时让频繁命令保持可见。
- 将工具提示用于不熟悉的图标、截断内容和快捷键教学，不要用于关键说明。
- 在高密度列表和网格中，让选择与焦点在视觉上可区分。
- 悬停和按下时保持目标位置稳定；避免几何变化迫使指针追逐控件。
触控与笔
尽可能使用平台控件的默认尺寸。自定义目标应满足 Windows 触控基线：
- 目标至少为 40 × 40 epx，即使可见字形更小；
- 高度为 32 epx 的目标，在宽度至少 120 epx 时可以接受；
- 针对触控优化的体验，优先使用 44 × 44 epx，并保持至少 4 epx 可见间距；
- 让频繁使用或误操作后果严重的目标大于最低尺寸；
- 不要让破坏性目标紧邻常规操作。
在支持鼠标精确操作的同时保证触控可用。让滚动、缩放、选择和笔输入共存且不产生手势冲突。
拖放
显示清晰的拖动提示、有效目标、插入位置、禁止状态和完成反馈。使用移动阈值避免误拖。对于关键拖动操作，始终提供“上移/下移”“移动到”“附加”或“导入”等键盘和菜单命令。
4. UI Automation 语义
无障碍名称必须简洁，在上下文中足以区分，并对命令使用操作导向的表述。
- 当标准控件根据可见文本生成的名称正确时，使用该默认名称。
- 对仅有图标的按钮、有意义的图像、自定义绘制内容、含义不清的重复控件，或可见文本无法描述操作的控件，通过目标框架的无障碍 API 显式设置名称。
- 适用时，通过目标框架的标签关系把表单标签与字段关联。
- 将补充说明放在帮助文本或无障碍描述中；不要把所有内容塞进名称。
- 通过正确的控件或 AutomationPeer 公开选择、选中、展开、按下、只读、必填、无效、忙碌和禁用状态。
- 标记装饰性图像和重复字形，避免产生噪音。
- 为自定义控件实现合适的 UI Automation 模式；只有无障碍名称并不充分。
不要机械地为每个控件添加显式名称。重复或过期的名称会使屏幕阅读器体验更差。
5. 视觉与认知无障碍
- 在普通浅色和深色主题中保持至少 4.5:1 的文本对比度。
- 测试高对比度；不要把高对比度主题当作普通主题对比度不足的补救方法。
- 对错误、选择和状态，除颜色外同时使用文本、形状、图标、位置或图案。
- 在所有主题状态中保持焦点、当前选择和输入验证清晰可见。
- 支持 Windows 文本大小设置和显示缩放，不能出现文本裁切、控件不可访问或命令丢失。
- 优先使用换行和自适应高度而不是截断。产品支持相关区域时，测试长本地化字符串、窄窗口和从右到左布局。
- 使用平实、具体的文案。先给出决策或恢复操作；避免指责用户，也不要只显示错误代码而不解释。
- 避免闪烁和非必要的重复动画。尊重系统动画偏好，并在动效运行时保持可交互。
- 为有意义的音频/视频提供字幕或文字稿，为信息性图形提供文本替代内容。
6. 状态、错误与计时
播报重要的异步状态变化，但不要抢夺焦点。为加载完成、错误和后台状态使用合适的实时区域或标准控件行为。
错误反馈必须回答：
- 什么失败了？
- 用户的哪些工作已保留？
- 用户现在可以做什么？
将字段错误放在字段附近；有多个错误时，根据需要在任务层级汇总。仅在有助于恢复时移动焦点，例如提交后聚焦第一个无效字段。
不要自动关闭关键错误。给用户足够时间阅读临时状态；可行时暂停时间限制，并为重要后台操作或通知提供持久历史记录。
7. 无障碍测试矩阵
- 只使用键盘完成主要流程。
- 验证合理的 Tab、Shift+Tab、方向键、Enter、Space、Escape、访问键和快捷键行为。
- 测试 Narrator 阅读顺序、名称、角色、值、状态和实时播报。
- 使用 Accessibility Insights for Windows 或 Inspect 检查 UI Automation 树。
- 测试浅色、深色和至少一种高对比度主题。
- 测量文本对比度，并确认颜色不是唯一提示。
- 测试 Windows 文本大小变化、显示缩放变化、放大镜和窄窗口。
- 测试鼠标、支持时的触控、上下文菜单，以及拖拽/悬停的替代方式。
- 检查长字符串、本地化扩展和任何受支持的从右到左语言。
- 在测试技术栈支持时，为关键界面和流程添加自动化无障碍检查。