通过

辅助功能最佳方案

  • 项目
注意注意

本文档的目标读者是欲使用 System.Windows.Automation 命名空间中定义的托管 UI Automation类的 .NET Framework 开发人员。有关 UI Automation的最新信息，请参见 Windows Automation API: UI Automation（Windows 自动化 API：UI 自动化）。

在控件或应用程序中实现下列最佳方案将改善那些使用assistive technology设备的用户的辅助功能。 其中的许多最佳方案都将重点放在好的user interface (UI) 设计上。 每个最佳方案都包含 Windows Presentation Foundation (WPF) 控件或应用程序的实现信息。 在许多情况下，为了满足这些最佳方案而需要完成的工作都已经包括在 WPF 控件中。

本主题包括下列各节。

  • 编程访问
  • 用户设置
  • 可视化 UI 设计
  • 导航
  • 多模式界面
  • 相关主题

编程访问

编程访问涉及到确保所有 UI 元素都进行了标记、属性值已经公开而且相应的事件已引发。 对于标准的 WPF 控件来说，许多准备工作都已经通过 AutomationPeer 完成。 对于自定义控件来说，需要执行其他工作才能确保编程访问能够正确实现。

启用对所有 UI 元素和文本的编程访问

User interface (UI) 元素应当启用编程访问。 如果 UI 是标准的 WPF 控件，则说明该控件中包括对编程访问的支持。 如果该控件是自定义控件（即已经归为公共控件的子类或者已经归为 Control 子类的控件），则必须检查 AutomationPeer 实现，看是否存在可能需要修改的区域。

遵循该最佳方案将允许assistive technology供应商标识和操作您的产品 UI 的元素。

UI 对象、框架和页面上的位置名称、标题和说明

辅助技术（尤其是屏幕阅读器）使用标题来了解框架、对象或页面在导航方案中的位置。 因此，该标题必须具有充分的说明性。 例如，如果用户已经深入导航到某个具体区域，则“Microsoft 网页”这一网页标题毫无用处。 说明性标题对于盲人和依赖屏幕阅读器的用户至关重要。 同样，对 Windows Presentation Foundation (WPF) 控件而言，NameProperty 和 HelpTextProperty 对于assistive technology设备非常重要。

遵循该最佳方案将允许assistive technology标识和操作示例控件和应用程序中的 UI。

确保编程事件能够由所有的 UI 活动触发

遵循该最佳方案将允许assistive technology侦听 UI 中进行的更改并将这些更改通知给用户。

用户设置

本节中的最佳方案可确保控件或应用程序不重写用户设置。

保留系统范围内的所有设置并且不影响辅助功能

系统范围内的某些标志可以由用户在控制面板中设置，其他标志可以通过编程方式来设置。 这些设置不应当由控件或应用程序来更改。 同样，应用程序必须支持其主机操作系统的辅助功能设置。

如果遵循该最佳方案，则用户可以设置辅助功能设置并知道这些设置将不会由应用程序来更改。

可视化 UI 设计

本节中的最佳方案可确保控件或应用程序有效地使用颜色和图像而且能够由Assistive technologies使用。

不对颜色进行硬编码

具有色盲、视力低下或者使用黑白屏幕的用户可能无法使用具有硬编码颜色的应用程序。

遵循该最佳方案将允许用户基于自己的需要来调整颜色组合。

支持高对比度和所有的系统显示特性

应用程序不应当破坏或禁用由用户选择的系统范围内的对比度设置、颜色选项或系统范围内的其他显示设置和特性。 用户所采用的系统范围内的设置可增强应用程序的辅助功能，因此它们不应当由应用程序禁用或忽略。 为了提供正确的对比度，颜色应当使用正确的前景色/背景色组合。 不应当混合无关颜色，而且颜色不应当反白。

许多用户都需要特定的高对比度组合，如黑底白字。 如果在绘制时进行反白，成为白底黑字，则会导致背景渗入前景，而且会使得某些用户难以阅读。

确保所有的 UI 都按任何 DPI 设置正确缩放

确保所有的 UI 都可以按照任何dots per inch (dpi) 设置正确地缩放， 还要确保 UI 元素适合分辨率为 1024 x 768 且dots per inch (dpi) 为 120 的屏幕。

导航

本节中的最佳方案可确保已经解决控件和应用程序的导航问题。

为所有的 UI 元素提供可通过键盘访问的界面

制表位（尤其是经过仔细规划的制表位）为用户提供了另一种用来在 UI 中导航的方法。

应用程序应当提供下列可通过键盘访问的界面：

  • 面向用户可以与之交互的所有控件（如按钮、链接或列表框）的制表位

  • 符合逻辑的 Tab 键顺序

显示键盘焦点

用户需要知道哪些对象具有键盘焦点，以便他们可以预测其击键效果。 若要突出显示键盘焦点，请使用颜色、字体或图形（如矩形或放大功能）。 若要从声音的角度突出键盘焦点，请更改音量、音调或音质。

为了避免混淆，应用程序应当隐藏所有的可视化焦点指示器并使那些位于不活动窗口（或窗格）中的选项变暗。

应用程序对于键盘焦点有如下要求：

  • 应当总是有一项具有键盘焦点

  • 键盘焦点应当可见而且明显

  • 选项和/或带有焦点的项应当在视觉上突出显示

支持导航标准和功能强大的导航方案

不同方面的键盘导航为用户提供不同的 UI 导航方法。

应用程序应当提供下列可通过键盘访问的界面：

  • 面向所有命令、菜单和控件的快捷键和带下划线的访问键

  • 指向重要链接的键盘快捷键

  • 所有的菜单项都有一个访问键，所有的按钮都有快捷键，所有的命令都有一个快捷键。

不要让鼠标位置影响键盘导航

鼠标位置不应当影响键盘导航。 例如，如果鼠标位于某个位置，而且用户正在用键盘导航，那么，除非用户启动鼠标，否则不应当发生鼠标单击。

多模式界面

本节中的最佳方案可确保应用程序 UI 中包括可视化元素的替代项。

为非文本元素提供可供用户选择的等效项

对于每个非文本元素，为文本、脚本或音频说明（如替换文本、标题或视觉反馈）提供可供用户选择的等效项。

非文本元素包括大量 UI 元素，如图像、图像映射区域、动画、小程序、框架、脚本、图形按钮、声音、独立音频文件和视频。 如果非文本元素中包含可视化信息、语音或一般音频信息，而且用户必须访问这些信息才能了解 UI 的内容，则这些元素非常重要。

在使用颜色的同时也提供颜色的替换项

使用颜色可以增强、强调或重复借助于其他方式显示的信息，但是不能单独使用颜色来传达信息。 具有色盲或者使用黑白显示器的用户需要颜色的替换项。

将标准输入 API 与设备无关的呼叫结合使用

与设备无关的呼叫可确保键盘和鼠标功能等效，并同时用有关 UI 的必需信息来提供assistive technology。

请参见

任务

NumericUpDown Custom Control with Theme and UI Automation Support Sample

参考

System.Windows.Automation.Peers

其他资源

Guidelines for Keyboard User Interface Design