本文来自于 Rational Edge：本文是关于利用 Eclipse 建立易访问的应用程序系列文章中的第一篇，本文以辅助技术和各种残疾开始。之后文章讨论使得 Eclipse 很好地适于在 Windows 或 UNIX 上创建易访问的应用程序的功能和特性。
易访问性是一个总括的术语，它包括生成使具有各种残疾的人易用的产品所涉及的所有东西和人。软件易访问性已经成为一个快速扩展的领域，包括下面所有内容：

　　为将一个程序的用户接口展露给其它程序的应用程序开发人员创建应用程序设计接口（application programming interfaces，APIs）。
　　创建并加入辅助技术（assistive technologies，ATs）—— 引入应用程序易访问性 API 的第三方软件和硬件。
　　服从许多国家，包括美国，要求的合法易访问性需求。
　　适用于具有各种能力和残疾的最终用户。
　　确保系统可访问特性的互操作性。
在美国，创建易访问的应用程序的主要商业（对比人道主义）驱动力是 Rehabilitation Act 1998 年的修正法案，称为 Section 508。Section 508 要求联邦机构使他们的信息技术对带有残疾的人易于访问，并应用到这些机构中的所有信息技术的获取上，但有一些例外（参见附录）。

　　州和地方政府正在制定类似的规章要求，这是世界的公共部分。这些要求已经开始关系到由大型公司引导方向的私有行业。许多公司现在将易访问性需求包含到他们的采购规格中。本系列文章中的第一篇将为利用 Eclipse 创建易访问的开源应用程序提供指导方针，一种使实现互操作性变得简单，使具有各种残疾的人容易使用的技术。

　　第一篇文章的开头，我们简要介绍软件开发的辅助技术和需求。然后，我们讨论对于试图满足这些需求的开发人员来说，为什么 Eclipse 技术是不错的选择。

　　辅助技术（AT）

　　易访问的解决方案将产品与一种或多种针对残疾用户的 辅助技术结合起来。您要创建一个易访问的解决方案，在产品设计和开发过程中使得产品具有易访问性。这与使软件国际化是类似的，更确切地说，您需要建立便于日后添加功能的基础架构。然后，当您将易访问的产品部署到带有残疾人所需的工作环境中时，您可以容易地将补充的 AT 与产品进行结合，创建完整的解决方案。AT 允许用户通过多种可选的访问方法与硬件交互。

　　AT 的通用类型包括：

　　屏幕阅读器（Screen reader）将文本翻译成语音，并为盲人“读”的软件。
　　屏幕放大器（Screen magnifier）为视力低下的人放大屏幕上的信息。
　　为聋人或听力有障碍的人显示字幕。
　　为那些对手的使用受到限制或移动困难的人提供特殊的键盘和输入设备。
　　操作系统特性，如键盘响应、高对比度、鼠标键、声音卫士（SoundSentry），和声音显示（ShowSound）。
　　只有当 AT 所交互的软件和硬件拥有使其易访问的所有必要组件时，AT 才是有效的。例如，屏幕阅读器不能帮助盲人阅读 Web 页面上的信息图像，除非开发人员为那些图像提供了选择性的文本。要帮助开发人员创建易访问的应用程序，软件程序设计平台必须提供方法使应用程序将可视化用户界面导出到 AT 产品中，使 AT 控制用户界面（UI）组件。换句话说，这些平台应该拥有标准的易访问性体系结构。

　　屏幕阅读器

　　要了解其含义，我们必须考虑 AT 如何工作的。举个例子，让我们来看看屏幕阅读器，它为应用程序提供一个可选择的用户界面，和以盲文或语音形式（帮助盲人用户）所运行的桌面。

　　当计算机屏幕上显现的所有信息只简单地包含 ASCII 文本行时，对屏幕阅读器来说，阅读屏幕图像，然后为盲人用户大声念出是不困难的。然而，随着图形用户界面（graphical user interface，GUI）的出现，屏幕阅读器需要附加的语义来理解图形屏幕对象。例如，看得见的用户看到和理解的按钮对屏幕阅读器来说，感觉到的是内有光栅文本的矩形，没有与该矩形相关的暗指的功能（对许多图标和其他 GUI 组件来说是一样的）。因此，屏幕阅读器需要一个标准方法 —— 如 Microsoft? Active Accessibility（MSAA）for native GUIs 或 Java? Accessibility API（JAA）for Swing? GUI 之下的标准控制所提供的内容 —— 来了解并告诉盲人用户屏幕上有一个可选择的按钮。这些 API 是基于使得应用程序 GUI 对象（也就是，组件、窗口小部件，或控件）导出自身信息的对象技术。

　　屏幕阅读器和其他 AT 使用操作系统、程序设计平台，和应用程序资源来为用户提供专门的输入或输出方法。在一些平台上，屏幕阅读器可以直接从已经实现了标准的易访问性体系结构的 GUI 应用程序中提取文本信息。然后屏幕阅读器利用专门的文本到语音转化硬件、软件语音合成器、盲文显示，或其他组合提出信息。其他平台上的阅读器利用屏幕以外的建模和直观推断的组合来从 GUI 应用程序中提取文本。由于此方法经常是不可靠的，所以如果应用程序得到文本易访问性 API 的充分支持（如果这些 API 对平台是可用的）就最好了。

　　屏幕放大器

　　屏幕放大器为应用程序提供一个可选择的 UI 和桌面，在此桌面上放大器以放大的带有可选的字体平滑和专门的彩色主题的桌面的形式运行。屏幕放大器被设计成跟随键盘焦点或鼠标。放大器选择“关注点”周围的矩形区域并伸展到整个屏幕（参见图 1）。一些屏幕放大器还为那些视力低下的人加入文本到语音的接口（就像屏幕阅读器）。对于这些 AT 所执行的所有功能，有必要访问一个设计的易访问性 API。

　　图 1：GNOME? 屏幕放大器

　　如图 1 所示，GNU Object Model Environment（GNOME）桌面留出一半屏幕正常显示，另一半放大显示，十字线表示指针位置。

　　高对比度主题

　　操作系统提供为支持易访问性而设计的主题机制。色盲或视力低下的用户得益于这些机制提供的高对比度色彩方案。图 2 中的屏幕显示此种易访问性选项，以及 Microsoft Windows XP? 操作系统提供的其他内容。GNOME 桌面也提供了多个主题，包括图 3 显示的高对比度主题。

图 2：Windows XP 中的易访问性选项

　　理论上，应用程序组件应该被构建成允许在用户指定的系统字体和颜色中的相同变化。

图 3：GNOME 桌面上的高对比度主题

　　Eclipse 利用响应这些变化的 Standard Widget Toolkit（SWT）中的标准桌面窗口小部件。对于其他的图形要素，您可以使用自动响应基本的操作系统中的颜色变化的假彩色。如果不行，您必须提供另一种变化颜色的方法。

　　屏幕键盘（On-screen keyboard）

　　GNOME 和 Windows 桌面都提供响应来自交替输入设备（如单一切换设备）而设计的屏幕键盘（参见图 4 和 5）。屏幕键盘通过输入到应用程序中的并通过交替输入设备激活的附加键自动循环。

　　GNOME 还包含一个单词预报功能。当用户开始输入普通的单词时，系统将完成该词，以便用户不需要输入每个字母。

图 4：GNOME 屏幕键盘（GNOME on-screen keyboard，GOK）

图 5：Windows XP 屏幕键盘

　　将应用程序构建成适合专门的输入设备，如屏幕键盘，是重要的。

　　其它可选择的设备包括单一切换设备、跟踪头部移动的设备，和用于行动困难的人可选择的键盘。这些可以顶替常规的鼠标或键盘。因为操作系统管理与常规鼠标、键盘和其他输入设备的交互，所以正确使用了标准的易访问性 API 的应用程序也可以正常操作这些专门的输入设备。

　　粘滞键

　　易访问的桌面还提供键盘过滤机制，如粘滞键、反跳键，和重复键来为行动困难的人调整键盘响应。

　　粘滞键允许常规的按键“停滞”一段指定时间，允许用户完成一个“组合键”—— 同时激活的一组键。通常的命令 Ctrl-Alt-Del 就是组合键的一个例子。

　　音频信号的可视化提示

　　操作系统也提供 AT 来辅助有听力障碍的用户。例如，声音卫士显示图标和其他可视化提示来指示系统已经发出报警或其他警告。

　　瞄准各种残疾

　　我们的讨论到现在为止已经提到了许多类型的残疾。让我们更近地观察这些类型的残疾及软件平台和应用程序需要适用的其他环境。

　　失明、视力低下，和色盲

　　失明的人根本看不到屏幕。对于他们，使用鼠标几乎是不可能的，甚至借助为行动受限的人设计的 AT 的帮助也是不可能的。取而代之，他们必须使用诸如屏幕阅读器的 AT，以有意义的方式解释屏幕上的信息。屏幕阅读器提供关联的听觉表述，如屏幕上有什么，可用的选项是什么，聚焦到什么用户界面控件上，以及发生了什么变化。另一个选择是盲文翻译设备。然而，只有 10％ 的视力受损者可以阅读盲文，他们是那些利用盲文和计算机的文本到语音转换设备组合的人。

　　视力低下的人看屏幕有困难，他们使用屏幕放大器来选择并放大一部分。所有的现代操作系统都提供一个基本的屏幕放大器。第三方产品提供附加的功能，如放大全系统字体的“主题”，或者提供背景和前景之间高对比度的主题。

　　色盲的人一般不借助辅助技术使用计算机，但是他们不能区分特定颜色。有许多类型的彩色色盲，但最普遍的 —— 不能区分红色和绿色 —— 影响百分之 6 到 8 的人。

　　供应商应该为任何视力损伤程度的人提供打印的产品文档的易访问版本。

　　技术需求

　　这些人也许需要以下内容：

　　图像的文本描述
　　提供通过鼠标可以正常访问的所有功能交替访问的键盘功能
　　屏幕或网页阅读器
　　文本和语义到语音或盲文的转换
　　大字体、高对比度，和屏幕放大
　　聋的，听力受损的，和耳背的用户

　　聋的和听力受损的客户要么听不见，要么在听到听觉警告和多媒体表现上遇到困难。

　　对于耳聋的用户来说，必须将音频信息转换成可显示或可打印的文本。一些现代操作系统提供全系统的设置，在出现听觉警报时自动生成可视化警告，或者为听觉警报自动提供具体的文本字幕。所有多媒体格式都提供它们自己的字幕 API。

　　技术需求

　　这些人也许需要以下内容：

　　声音的可视化指示
　　字幕
　　可调整的音量
　　电传（TTY?）或用于聋人的电话设备（telephone device for the deaf，TDD）界面
　　高信噪比率
　　行动能力受损的用户

　　此类别包含很大范围的残疾类型，从很难控制手部移动的帕金森患者，到遭受撞击后不能使用手臂的人，到根本没有手臂的被截肢的人。

　　行动能力受损的用户很难使用鼠标。Parapalegics 通常使用戴在头上的指针指示设备，他们移动头部以在屏幕上移动指针，并通过嘴里的管子吹气来点击鼠标。那些可以适当使用手的用户可以利用前面描述的屏幕键盘。此外，能够使用标准键盘，但却很难键入一次按下多个键的组合键的撞击受害者和其他行动障碍者可以使用允许他们按顺序一次输入一个键的操作系统设置。

　　技术需求

　　这些人也许需要以下内容：

　　适用于手或手指不能使用或受到限制的人
　　适用于有限的范围、速度和力量
　　易访问的开关和锁布置
　　键输入
　　设置键响应时间的功能
　　认知障碍的用户

　　此类别也包含很大范围的残疾类型，但是通常指不容易理解所读内容的人。

　　具有阅读障碍的人需要调整文本前景和背景颜色及/或调整字母和单词间空隙的功能。

　　技术需求

　　这些人也许需要以下内容：

　　单词和行之间可调整的白色空格
　　前景和背景颜色选择，改善可读性
　　不强调“连接”词（连接词、文章）
　　定时的功能
　　双模态（打印和音频）信息递送
　　指导眼睛从一个词到一个词的定向照明
　　用代替文本的图像
　　既然我们了解了现有的 AT，以及开发人员需要考虑的各种残疾，让我们转向 Eclipse 在易访问的软件开发中起到的作用。

　　Eclipse 是什么？

　　Eclipse 环境提供一组用于建立新应用程序的组件。在 IBM 中，我们已经利用 Eclipse 技术建立从 IBM WebSphere Studio 家族产品到 IBM Tivoli 配置公用和 IBM Lotus Rich Client 的下一代的应用程序。Eclipse 的重要特性是它可以运行在很大范围内的操作环境之上，包括客户环境中的所有战略上的 IBM 平台。

　　Eclipse 操作环境包括处理器体系结构、一个操作系统、一个分屏系统，和一个 Java 运行时环境。在易访问性的讨论中，操作系统和分屏系统是关键变量。

　　对于性能和其他原因，Eclipse GUI 库直接使用通过将窗口小部件封装到瘦的 Java 层中来提供窗口部件的操作系统。这些组件也用于本地客户应用程序，并需要连接本地平台易访问性特征。因此，对于在 Eclipse 中生成易访问性特征来说，平台易访问性支持是必要条件。Eclipse 包括一个平台 GUI 抽象层和一个映射到本地操作系统平台框架的易访问性 API。目前，Eclipse 易访问性的实现支持 Windows 操作系统，并且正扩展到支持任意带有 GNOME Toolkit（GTK）窗口部件集（如 GNOME 桌面）的 UNIX 平台。对其他平台和其他操作系统，如 Mac OS X 的考虑超出本文的范围。

　　Eclipse 如何启用易访问性

　　Windows 平台的易访问性特征在 Eclipse 2.0 中得以实现，并且在 Eclipse 2.1 中得到进一步细化和稳定化。Eclipse 3.0 中加入了对 GNOME 平台的基本支持。主要的 AT 厂商参与测试其产品在 Eclipse 上的互操作性的工作，确保该技术在所有的支持平台上是完全易访问的。

　　此外，Eclipse 拥有一个包含 API：org.eclipse.swt.accessibility 的易访问性包。虽然 Eclipse 应用程序是用 Java 编写的，但是 Eclipse 应用程序遵循目标桌面操作系统的易访问性 API。Eclipse 提供一个丰富的插件环境，在该环境中，标准是为本地窗口部件创建插件。大多数与 Eclipse 一起的 SWT 窗口部件实际上是为本地 GUI 窗口部件的 Java 包装（与纯粹的 Java GUI，如 Swing 相反，其更高级别的组件不转化为本地操作系统窗口部件）。

　　Eclipse 3.0 易访问性特征是基于 MSAA 1.3 程序设计模型所提供的功能。您可以将 Eclipse 中的 Accessible 对象联系到每个控件上，并且 org.eclipse.swt.accessibility 接口中的方法集对应 MSAA 1.3 IAccessible 界面中的消息集。

　　SWT Accessible 对象提供一座桥梁，由基本的平台框架发送与易访问性有关的消息到用户应用程序所使用的 SWT 窗口部件 —— 以便应用程序组件可以向平台提供易访问性信息。平台易访问性体系结构确定了平台易访问性框架和 AT 用户代理之间的接口。图 6 阐明了此设计。

　　图 6：一个易访问的基于 Eclipse 的解决方案的组件

　　图 6 中三个组件是：

　　用 SWT 构建的应用程序（或插件）。该组件是独立于平台的，因为 SWT 将应用程序与平台分离。org.eclipse.swt.accessibility 包运行时提供从应用程序到平台之间的桥梁。

　　平台易访问性框架，如 Windows MSAA 或 GNOME Accessibilty Project（GAP）。
AT，如 JAWS 屏幕阅读器。在运行时刻，AT 通过调用平台易访问性框架来获取有关用户界面要素的信息，框架依次调用.swt.accessibility 包。

　　org.eclipse.swt.accessibility 设计目标

　　org.eclipse.swt.accessibility 包被设计用来向 Eclipse 开发人员提供一组工具，开发人员用这些便利建立应用程序和支持这些技术的平台上的 AT 进行互用。目前，Eclipse 与 Windows 和 Linux GTK 上的易访问性平台集成了。

　　从 IBM 的角度看，此项工作对应用程序开发人员有一些要求：

　　提供可视化的和程序化的中心。
　　考虑高对比度、色彩，和大字体的系统设置，或提供特定的备选方案。
　　为界面要素提供文本名称和描述。
　　提供语义信息，如对象的作用和它们之间的关系。
　　提供利用键盘导航并访问所有功能的功能。
　　基础的平台易访问性框架的便利将在各种程度上适应这些需求。例如，在 Windows 上，MSAA 通常提供获取 UI 要素名称和描述的便利，但只有有限的能力定义要素之间的关系。

　　跨平台的 Eclipse org.eclipse.swt.accessibility 包实际上为开发人员提供基础 Windows 平台中可用内容的易访问性支持中的一个或多个改进。Windows MSAA 设计通常不让开发人员控制 UI 要素上的易访问性属性。根据具体到每个控件的内部算法，MSAA 自动确定名字和描述。例如，MSAA 自动在按钮上使用文本作为 MSAA name 属性。如果开发人员希望提供不同的名字或描述，那么他们必须付出昂贵的代价来创建 MSAA 代理。然而，Eclipse org.eclipse.swt.accessibility 自动执行代理工作。因此开发人员可以很容易地为各种 UI 要素（如易访问的名称和描述）定义适当的属性值，全部在 SWT 环境中。

　　Eclipse 3.0 中的变化

　　Eclipse 3.0 版本中加入了许多重要的易访问性特性。

　　首先，版本 2.1 中定义的现有org.eclipse.swt.accessibility API，现在得到了 Linux?/GNOME 平台的支持。此外，GNOME 拥有一组新的用于文本控件的特性。

　　通过 AccessibleTextListener 接口（和相应的 AccessibleTextAdapter 和 AccessibleTextEvent 类），和org.eclipse.swt.accessibility.Accessible 中的三个新方法 text{*} 提供用于开发易访问的文本窗口部件的新便利。这些新的便利是基于 GNOME Accessibility Project 的 AtkText 接口的小子集。更丰富的文本 API 可能包括检索文本子范围和风格属性的本地信息的功能，现在这些功能在 Eclipse 中是不可用的。

　　跨平台 API 兼容性

　　Eclipse 易访问性 API 工作于多个平台之上，尽管每个操作系统的基础易访问性 API 中有很多差别。

　　在 Windows 平台上，大多数可用的操作易访问性特性的功能是通过单一的 MSAA 接口提供的：IAccessible 接口。该接口为通用的属性和行为定义 MSAA 1.3 属性和方法，并且提供对所有 UI 控件的访问。

　　当特定的属性或方法不适用于特定类型的 UI 要素时，属性值为“don't care”。或者，在不适用的方法的情况下，成为空操作。MSAA 2.0 中加入了一些附加的文本接口。不幸的是，目前 AT 技术对 MSAA 2.0 只提供有限的支持，Eclipse 根本不支持 MSAA 2.0。

　　相反，GNOME Accessibility Project 利用为多种 UI 要素提供更多具体接口的更面向对象的方法。GAP 定义了一个关于易访问性工具包（accessibility tool kit，ATK）中十多个易访问性接口的集合。每个 UI 要素通过实现一个或多个这样的接口来提供易访问性服务，由于适合该窗口部件的专门的行为。这生成了 AT 所利用的比 MSAA 所提供的更丰富的特性集。

　　org.eclipse.swt.accessibility 包最初模型化为具有 MSAA 1.3 功能（MSAA 1.3 方法实际上分为两个接口 —— 一个用于标准的窗口部件，另一个用于定制控件）的单一接口。Eclipse 3.0 添加了对 GNOME 的支持，包括映射 Eclipse 的基于 MSAA 的体系结构以与 GNOME 一同工作。

　　使用 Eclipse，开发人员不需要担心基础平台的易访问性 API 中的差别。所有的易访问性支持都通过包含用于与各种平台的易访问性 API 对话的具体平台代码的 org.eclipse.swt.accessibility 进行。

　　现在我已经介绍了使 Eclipse 适用于创建易访问的应用程序的基本特性和功能，下个月的文章将探究在 Eclipse 中创建易访问的定制控件的具体代码示例。

　　附录：易访问性的法律方面

　　开发易访问的解决方案的商业动机是很基本的：渐渐的，不提供易访问的解决方案，您将根本不能做生意。

　　1998 年，美国国会修正现有的 Rehabilitation Act，要求联邦机构将他们的电子和信息技术易于残疾人的访问。不易访问的技术妨碍个人快速并简单地获取及使用信息的能力。Section 208 表明了对这部分的调整。该法律于 2001 年 7 月开始实施。类似的法律在其他国家也出台了，或者不久将出台。

　　Section 508 的颁布是用来消除信息技术中的障碍，为残疾人创造新机会，并鼓励开发帮助实现这些目标的技术。当联邦机构开发、获得、维护，或使用电子和信息技术时，该法律就适用。在 Section 508 下，机构必须向残疾雇员和公众中的残疾人员提供与对其他人所开放的访问程度比得上的信息访问程度。

　　机构可以选择在以下范围内找到 Section 508 法规的例外：

　　国家安全：用于国家安全系统的电子信息技术。

　　承包商：带有合同的承包商所获取的电子信息技术 —— 也就是，用于开发由联邦政府使用的应用程序的任何应用程序或计算机设备。
Back room：位于那些服务人员进行维护、修理，或偶尔进行设备监控时才去的地方的电子信息技术。例子包括服务器、磁盘存储设备、磁带存储设备，和与这些相联系的连接设备。

　　过度的负担：会对一个机构强加上过度的负担的电子信息技术。过度的负担意味着存在一种使技术非常昂贵或很难顺应的情形。
在所有情况下，机构，而不是厂商或产品必须寻求例外，并且只是在特殊的应用程序部署环境中。例外不断的变少。在一种例外环境中部署的产品不会在另一个例外环境中进行考虑。那是因为只在一个应用程序中的 后台用到的硬件或软件用户接口也许会在另一个应用程序的信息站中用到。机构可能确定为第一个环境寻求例外，但几乎不会为后来的寻求例外。此外，一些机构希望能够雇佣失明的系统管理员。他们希望每个东西都是易访问的，且对 AT 是有效的，如屏幕阅读器。

　　在任何情况下，机构越来越不愿意承认例外，因为诉讼数量在不断增长。

　　Section 508 的易访问性条款被包含到每个联邦行政部门命令中。如果一个政府机构不遵守 Section 508 的要求，那么该机构将会受到控诉。出于这些原因，满足 Section 508 要求的厂商具有非常大的竞争优势。

　　类似的法律出现在许多美国州政府的供给系统中，以及在欧洲和亚洲中。此外，类似的要求已经从公共部门流动到私有行业中了。

　　参考资料

　　您可以参阅本文在 developerWorks 全球站点上的 英文原文。