本文内容包括：

在开发过程中嵌入易访问性设计 将易访问性原则集成到 RUP 中 对于用 RUP 进行的通用设计的路标 结束语 致谢 注释 参考资料

本文来自 Rational Edge：在当今的软件和 Web 开发项目中，易访问性的考虑起到了非常小的作用，很少有产品对残疾人或老年用户是具有易访问性的。本文的作者主张我们可以通过将易访问性原则无缝地嵌入到所建立的开发过程中来解决该问题。他们提议一种将具有易访问性的设计集成到 IBM Rational Unified Proces，或 RUP（许多软件开发项目中使用的迭代过程）中的激励人的方法。他们还解释说需要更多研究来充分利用所提议的方法。

 全世界的易访问性倡导者说服软件行业通过依照易访问设计原则开发对残疾人和老年用户具有易访问性的主流产品。商业理论很简单：易访问设计使产品对许多用户更具有吸引力，不仅是那些残疾人。例如，一个设计为所有人使用的应用程序，包括那些看不见的人，也会更好地适应于小屏幕的移动设备。如果所有用户拥有一个替残疾用户着想而设计的产品，他们将更高效并很少出错。换句话说，易访问性是一个具有潜在高效益的尚未打开的市场机会。 ¹

立法者也正在推行产品的易访问性，特别是那些对应 Web 站点的产品。在美国，Rehabilitation Act 的 508 部分命令所有联邦机构只购买具有易访问性的产品并在 Web 上以无障碍的方式提供信息。在其他国家类似的规则也在考虑中或实施中，包括澳大利亚和其他欧洲国家。例如，在德国，2002 年反岐视法要求到 2005 年底联邦政府 Web 站点要具有易访问性。

一般而言，易访问性规则依赖于一种普通标准的，能使软件产品或 Web 站点具有易访问性的观点。University of Wisconsin 的 Trace Center 和 World Wide Web Consortium（W3C）是为软件和 Web 领域中的易访问设计开发指导方针的先驱。 ² 现今，易访问性指导方针在以下这些领域中可用：

• 一般软件 ³
• 主要的操作系统和平台
• Web
• E-learning 应用程序
• 公共终端
• 电信和其他领域

然而，尽管所有这些指导方针、标准和规则要求易访问性 ⁴ 大多数主流产品仍旧没有为残疾用户考虑而设计。为什么大多数软件开发人员和 Web 设计人员对易访问设计原则了解得这么少？

在开发过程中嵌入易访问性设计

首先，目前易访问性指导方针和标准是静态对象。要对产品开发有真正的影响，还需要将它们嵌入到现今的开发环境中并具有可操作性和实践性。软件开发项目有严格的时间和预算限制，设计人员和开发人员没有时间费劲地看完长长的易访问性标准的列表。

我们的论点是，应该将易访问设计实践紧密地集成到企业的软件工程项目过程中以便其不显著。换句话说，团队成员应该很容易能够在日常中遵循这些规则，就像他们遵循任何类型的合理工程实践一样。实际上，这种集成会为更广泛环境中的更广泛人群扩展和增强产品的使用。

该集成还会代表易访问设计的下一个发展阶段。第一个阶段是探究：依据易访问性找出什么行什么不行。第二个阶段是聚集：开发对具体领域，如 Web、e-learning 等等，普遍认同的易访问性指导方针。现在，有了公认的指导方针和标准的基准，我们准备将定义到软件开发工具和环境中的原则插入。然后，开发人员可以利用这些工具自动地评估有关具体用户组的产品易访问性并且也能用于有关如何应用易访问性原则的集成到过程中的指导方针。

其次，设计人员倾向于将易访问性考虑成产品完成后应用到产品中的补丁。这是一种事后聪明的做法（或者是“不考虑”），而不是整体的计划考虑。这样代价很大。在开发之后向 Web 应用程序中“添加”易访问性要比最开始建立时多花费大约十次。 ⁵ 所以，许多人认为易访问设计是负担不起的，因此，对产品竞争力不利。

再次，将易访问设计原则嵌入到流行的软件开发过程和工具中能够解决这些问题。如果我们把易访问性需求作为一般的需求，那么它们将和功能与性能需求一起出现在开发人员的任务描述中。开发人员不需要为使产品对残疾人可用而做任何额外的事情，他们要做的全部事情就是开发满足特定需求的产品。

将易访问性原则集成到 RUP 中

应用程序开发不是新规程，且采用已证明的最佳实践可以帮助企业成功地处理应用程序开发的复杂性。我们的目标是将这些最佳实践作为能将易访问设计原则集成到主流应用程序开发中的媒介。

IBM Rational Unified Process，®或 RUP，®是过程框架且是对于面向团队的软件开发方法的最佳实践的集合。在 2003 年，全世界大约有超过 3,000 个公司中的五十万用户使用它。 ⁶ RUP 被设计成对具体企业环境中的具体项目很容易配置。项目或企业也许开发自己的插件以适应他们具体的需求或者加入 RUP 团体中可用的第三方插件。

RUP 提供对概念和工作流的普通理解，并且它从模板和开发过程中各点的核对清单开始。这使得它成为合并易访问设计原则的理想媒介，并且我们在本文中使用它来论证如何做到这点。然而，如您读到的，记住我们所提议的概念和方法可以嵌入到任何迭代应用程序开发过程中。

收集需求

尽管有时候将易访问性定义为对所有用户的“可用性”，但是易访问性的一些方面超过了这些，并考虑到拥有不同能力和个人工具的人。现在，易访问性的一个重要方面是与辅助技术的互通性，且因此，与已建立的标准一致。

当前的易访问性规则和政策要求产品对具有广泛功能限制并处于广泛年龄组中的用户是易访问的（有一些免责条款：例如，在线银行系统不必要为六岁孩子使用而设计）。

虽然我们经常认为易访问性是固有的软件质量，但是它不是真正的二元的属性（例如，要么是真要么是假），而是特殊环境中产品和用户之间的关系。因此，代替询问“我们希望使该产品易访问吗？”，我们应该问“谁是该产品的目标用户（例如预期的和必需的）？”此外，我们将希望知道：“他们的需求是什么？”及“他们在什么情形下使用该产品？”这些问题与 RUP“开发一个远景”行为（初始阶段出现的，在软件开发项目的开始时）保持一致。

让我们拿在线银行应用程序作为实例。在我们开始设计产品之前，如果我们期望该产品能够实现我们的目标（比起银行只通过普通渠道实现的，而以更低的成本服务于更多的客户）那么我们首先必须识别潜在的用户功能和非功能需求。这里是这些需求的示例：

• 应用程序的使用必须简单 —— 没有人希望为进行银行业务而阅读手册。
• 应用程序必须对各种各样的人可用：男人和女人，年轻人和老年人（也许太虚弱以至于不能去银行），说英语的和说西班牙语的，有经验的计算机用户和技术恐惧者。
• 应用程序必须对老年人和其他阅读小文本时有困难的人是可用的。应用程序必须对所有年龄的手不灵巧很难使用鼠标的人是可用的。
• 应用程序必须适于在家庭环境中使用。大多数客户会通过 Internet 连接用家庭计算机访问应用程序。
• 用户应该拥有当处理电汇订单时可以断开的能力，因为他们按分钟支付 Internet 费用。
• 图像要容易辨别，甚至对那些视力差的用户。
• 对于盲人，至少要有一个屏幕阅读器在目标执行平台上是可用的，并且要与应用程序配合得很好。换句话说，要将产品设计成可以提供音频输出的。

注意到我们初始的需求收集是基于 RUP 中倡导的迭代开发方法。我们的设想是按照技术、实践、预算和其他驱动因素所指示的在生命周期过程中添加、修改和撤消需求。我们还将在规定的迭代中开发应用程序，每个迭代不断增加地为应用程序的规定范围和质量标准做出贡献。尽管如此，在过程的早期，定义尽可能完整的初始需求（包括用例）是关键的。这些需求会作为进一步的迭代计划和风险管理的基础。在过程的任意处，需求应该反映出有关预想产品的当前的认识。

一旦我们获取了易访问性需求（包括法令），我们就可以像对待其他需求一样对待它们。易访问性应该作为一条准则，像其他功能确定产品质量的方式一样鉴定整体的产品质量。换句话说，如果产品对目标用户是不可行的，那么该产品是有缺陷的。

一旦我们辨别出目标用户基础并得到我们的易访问性需求，向设计人员和开发人员传达这些需求的最好方式是什么？为他们生成一个很长的列表来手工处理对大多数项目来说是不现实的。实际上，我们必须以对所有团队成员都方便且具有易访问性的形式来获取这些需求。利用角色（嵌入到用例和情境中）是一种方式。

使用用例和情境

许多主流软件工程项目已经成功地使用用例来指定应用程序的外部特征。用例使功能需求对所有涉及到项目中的风险承担者是具有易访问性的且可理解的。

Ivar Jacobson 1992 年所介绍的 ⁷ 用例被定义成系统执行的动作序列，能够生成对特殊参与者价值的引人注目的结果。 ⁸ 统一建模语言（Unified Modeling Language，UML）为用例定义图形符号，针对系统应该做什么，而不是如何去做。用例作为客户（如，用户）和系统开发人员之间沟通的共同语言。因此，在开发项目的早期可以用它们来获取需求。

尽管用例获取用户和任务的一般化观点，但是依据具体的工作流，情境描述具体的用例实例。情境使用具体的数据，具体的事件，和可能具体的用户界面，有时候描述情节。开发团队为每个用例生成一些情境来说明事件流和各种错误条件（参见图 1）。情境基于真实数据，这使得它们成为后来过程中测试用例的适当基础。

图 1：每个用例都有一组分配的情境。

RUP 使用用例将使用方法描述连接到应用程序的体系结构和代码上。其实，用例像增加的应用程序开发和在项目生命周期中连接各种开发活动的线程一样运行。

然而，用例和情境有局限性。它们把用户仅视为“参与者”并且获取他们的用户界面需求——和他们的功能。虽然这些技术提供了杰出的方法来描述系统行为，但是它们不能传达真实的用户环境和界面需求的足够信息。

添加角色以获取易访问性需求

Alan Cooper 1999 年所介绍的概念，使用角色 ⁹ 是弥补缺陷的一个恰当的方法。指定角色包括为系统用户分配假想的名称和面容（照片）并撰写一篇工作生活中一天的大体描述。虽然假想的角色被描绘成个体，但轮廓反映出整个的用户组。

Cooper 区分了主要角色和次要角色。主要角色代表主要的目标用户，因此是设计应用程序用户界面的主要推动力。次要角色有额外的需求，如果为满足这些需要而进行变更，符合此描述的人就可以使用主要角色的界面。当然，这些变更必须不能与主要角色或者其他次要角色的界面需求冲突。

事实上，使用角色会导致有效的，以用户为中心的设计。角色能够使开发人员通过各种各样有多样化界面需求和参数选择的潜在用户的眼光来观察他们的系统。

有代表性的是，产品设计人员不知道人们实际上如何使用产品，甚至很少知道用户的需求和目标。除此之外，如果设计人员很年轻，技术熟练，并设计为老年人所用的产品，是特别成问题的。这对残疾人来说也是重要的问题。如果角色被定义成带有个人感觉并在生命中挣扎的，角色可以帮助设计人员理解老年人和残疾人如何使用产品。

随着开发人员与该角色的接触 —— 他们会更加熟悉它们的需求和参数选择 —— 甚至同情他们。这些角色所代表的残疾用户会切实地，普遍地出现在开发过程中。

角色规范含有用户环境，包括任何使用产品时所需要的辅助技术。您可能会为一个人书写多种描述，或者，将一个用户组分成多个角色来表示盲人用户的范围（语音输出用户、盲点法用户、天生的盲人、后天失明的等等）。

单独的角色不是易访问性需求的代替，它们是向这些需求中添加意义和上下文的装置。它们可以使需求更加具体并更容易理解。随着时间的推移，它们可以帮助开发人员将需求内在化，以便照例依照它们，不需要记住它们或者迷信地遵循它们。与易访问性需求迷信地保持 ¹⁰ 一致经常导致满足规范的设计，但不是必要地理想甚至可操作。利用角色来举例说明设计过程中的易访问性需求，并随后在实现和测试中追溯可测试评估点是有效的。稍候我们将讨论此后面的功能。

您应该为每个人类参与者提供一组相关的角色（参见图 2）。对每个组，您必须指派一个主要角色，其他的都是次要的。主要角色应该为每个涉及相关人类参与者的用例推进用户界面设计。然后，对每个用例，您应该用所有次要角色来“代替”主要角色，修改用户界面设计，并确保用户界面满足每个次要角色的需要。您可以依照与情境类似的程序。很少情况下，主要角色是两个，因为他们有冲突的用户界面需求。在这种情况下，您可以复制用例，为一个主要角色分配每个用例，并为每个用例创建分开的界面。

用例、情境和角色共同组成了支持用户为中心的分析和设计的强大技术。用例获取产品的整体功能行为，角色为用例指定（不同的）目标用户集，并因此可以表达易访问性需求，并且连接到具体用例的情境为真实用户描述现实的事件顺序。

图 2：每个用例有一组相关的角色。

您需要多少角色？要表示一组完全的用户，包括多种残疾的用户（一般在老年人中），我们的研究表明您也许需要三十个角色（假设该组中极大的可变性和许多残疾的方面）。用更小的数字获得完全的覆盖面会更有利，对这方面的研究在 University of Wisconsin 的 Trace Center 中正在进行。然而，目前，对不能表示局限性不同排列的一组角色的使用、开始的年龄、技能，和残疾人之间等的内容能够导致严重的误解和浪费了的工作。甚至对易访问性很热心的设计人员还经常不注意地忽略重要用户组的需求 —— 包括那些上了年纪的用户。需要做更多的研究来识别应用程序开发中使用的标准角色组。此外，启发式的和对于易访问性的设计指导方针对创建伴有角色的易管理的设计过程是关键的。

确保为用户提供对易访问性的支持

当您完成了产品的开发时，进行部署的用户会需要支持。这是角色的另一个有用之处，它们可以为这些用户推动支持机制。您可以利用角色来开发产品文档（例如，用户的指导、安装指导、课程和培训材料）。如果您计划以印刷形式散发文档，您也需要做电子形式的。您需要检查这些文档，以及其他在线材料（例如，在线帮助，版本注释，用于下载的 Web 页面）是否对目标用户组有易访问性。如果要将产品以物理包的形式售出，您也需要检查包装的易访问性。如果您在举行辅导活动，那么房间应该是具有易访问性的。

如果您决定为直接的用户支持提供热线，那么您还应该为此检查易访问性。您需要为文本电话用户安装单独的热线，并在文档中包含其号码。

测试易访问性

RUP 将测试描述为一种在软件开发生命周期中不断地确保质量的方法。 ¹⁰ 及早测试可以减少完成和维护软件的成本。测试最初源于需求，但它们也源于其他来源。例如，在您发现并纠正具体错误情况之后进行测试。对于当今的复杂软件应用程序，自动化工具对生成测试数据并运行和分析测试是必要的。

如果您已经利用整合到用例和情境中的具体角色来获取易访问性需求，如我们上面描述的，那么您可以使易访问性测试成为您继续的生命周期测试活动中的完整部分。IBM Rational 的 Jim Heumann 描述了一个方法，由用例和情境生成测试用例。 ¹¹ 如我们早期注意到的，每个用例都有一组分别表示主要的和次要的事件流的情境。测试人员可以为每个情境获得一个或多个测试用例并将数据值附上。

对于根据功能需求评价产品来说，这些测试用例是有用的。它们还为用例提供具体的用户界面，这使得您对照易访问性需求来评估产品，您可以让您的测试基于源自一组角色的易访问性评估点。

如我们所见，您可以为每个用例和其人类参与者指派一组角色，来为易访问设计生成整合的方法。不论您在测试用例中使用的角色是什么，测试数据都将是一样的，因为对于主要和次要角色来说事件流是一样的。然而，此要角色扩展并增强了情境的可用性需求，且这些额外的需求要得到检查。

要运行测试用例，构建基于主要角色的测试数据，然后根据次要角色检查附加的易访问性就足够了。例如，如果您的主要用户使用鼠标和键盘进行可视化交互，使用屏幕阅读器和键盘导航的次要角色会添加以下需求：

• 通过平台的易访问性 API，要显露出所有单元。
• 图像要有文本的等价物。
• 通过键盘要能访问所有单元。

对于听力损伤的次要角色，您会确保为声音输出提供音量调节功能，为视频剪辑提供字幕，等等。对于无语言或学习能力的次要角色（也许看不见），您要对产品的易用性、在线帮助文本的阅读级别等等特别关注。

利用自动和手动测试来验证易访问性

同大多数测试一样，将您对易访问性需求的测试自动化是有利的。用自动测试工具，您可以在开发生命周期中重复运行回归测试，以确保在您进行变更之后，系统体系结构和用户界面仍然健全并且易访问特性仍然完好无缺。理论上，您甚至可以生成能够自动实现测试用例（或一部分）的脚本。然而，易访问性不是所有方面都支持自动测试。很重要的是不要严重依赖那些适合此种测试的方面。

RUP 的测试建议由单元测试、整合测试、系统测试和试点测试组成。对易访问性需求的测试技术在这些领域大概是一样的（除了试点测试，其涉及了真人用户的测试）。尽可能早地开始测试是合适的。由开发人员所执行的单元测试使您在早期辨别并修改问题，这样做既降低了成本又降低了项目风险。改正您通过随后的测试所发现的问题要涉及不只一个人 —— 因此，更多间接营业成本。

在许多项目中，开发人员在书写代码的同时书写单元测试 —— 或者有时甚至提前（如在测试驱动开发中）。如果单元测试相当小并且只覆盖必要的功能需求的话，这种方法是可行的。如果开发人员不得不为每个测试用例中的易访问性评估点书写代码，那样会添加许多工作。幸运的是，易访问性需求对运行在同一平台上的测试用例和功能单元是公共的。大多数易访问性需求与用户界面设计有关，并且对拥有类似用户界面的用例是一样的。因此，开发人员可以在项目测试用例和用例上复用评估点，利用当前的测试工具来自动地生成代码并根据易访问性评估点验证产品。

此外，用于易访问性检查的专门的商业和免费工具可以帮助简化并自动化测试过程。大多数工具以指导方针和规则为基础评估 Web 页面。 ¹² 一些工具允许您配置评估点集合来应用到应用程序中。

易访问性评估点是具体到特殊平台的检查点的最小单位，不幸的是，不是所有的点都可以由计算机进行测试。例如，计算机可以测试文本等价物对图像是否可用，但不能测试文本的质量或者甚至确定文本是否是无意义补白。

然而，一旦人类做出了决策，计算机就会接管，执行统一的，重复的任务。例如，如果一个测试人员手工地验证具体图像所对应的具体文本，那么他可以安排计算机来验证应用程序中对应图像副本的同样的文本。然后，在后继的测试运行中，测试人员将不需要再观察文本等价物了，除非从最近一次测试运行开始图像或文本改变了。

不幸的是，很少有工具关注图形用户界面，并且大多数没有我们提到的成熟。然而，该情况应该随着对生产力工具的需求而改进，以支持易访问设计的增加。

从角色中得到易访问性评估点

确定易访问性评估点不是微不足道的事。这些点应该基于用例所涉及的角色和使用的上下文（参见图 3）。如果您向一些或所有用例中添加角色，那么您也应该向相关的测试用例中添加检查点，以确保系统对新角色是具有易访问性的。

图 3：测试用例源于用例情境，评估点源于角色并包含于测试用例中。

理论上说，您可以使用自动化工具取得基于角色和使用的上下文的易访问性评估点。要使其可行，您需要角色和易访问性测试工具之间的无逢连接。该方法也会提出关于评估点所出自的标准和指导方针的具体需求。出于讨论的目的，我们将假设指导方针和标准由一组开发人员用于产品检查的评估点组成。当然，真正的标准和指导方针实际上包含了需要由开发人员转化为具体平台上的评估点的一般易访问性原则。

让我们再假设指导方针和标准阐述了每个评估点如何影响不同类型用户（角色）的可用性，并将用户利益分为：基本的、重要的，或者有益的。如果系统没有满足基本的评估点，角色根本不能够使用该系统。如果没有满足重要评估点，角色可以使用产品，但只能付出很大努力，而以效率低下的方式。如果系统实现了有益的评估点，产品对角色会更有用，尽管产品在不满足标准的情况下仍旧具有功能。

在某些情况下，评估点实际上会使特殊的角色更难使用产品。我们还可以定义三个程度的劣势：排除、阻碍，和不便。排除意味着如果满足了评估点，角色根本不能使用产品。阻碍意味着角色可以使用产品，但只有付出相当大的努力。不便意味着产品对角色的可用性较小，但角色可以在没有重大困难的情况下使用产品。

总之，评估点和角色之间的关系可以被描述成七个值：

1. 基本的
2. 重要的
3. 有益的
4. 中立的
5. 不便
6. 阻碍
7. 排除

目标是在不为其他产品生成排除或阻碍因素的情况下为一个产品满足所有基本标准及对所有角色尽可能多的重要标准。

在标准和指导方针的理想集合中，每个指导方针会有多种评估点集，每个集合与具体的平台有关。按照那种方式，您可以在项目中间转向运行时平台并简单地将您原来的评估点集换成适应新平台的集合。您的需求 —— 基于角色集 —— 仍旧稳定，并且仍旧推动评估点对新平台的选择。

减轻与易访问性相关的风险

在任何应用程序开发项目中，项目经理必须确保按照需求、准时，且在预算之内开发产品。 当使用 RUP 中具体化的迭代开发方法时，项目经理保留着一个按照出现和影响可能性排列的风险列表。每次连续的迭代处理最可能在那时出现并对产品有严重的负面影响的风险。团队通过观察产品没有满足的需求来得到这些风险。如果他们将易访问性需求加入他们的初始集中，那么他们可以在早期减少易访问性风险，就像他们对其他可用性问题做的一样。

例如，在 RUP 的构建阶段，开发人员也许会确定产品不能由利用屏幕阅读器的角色进行访问。要减少该风险，团队可以在目标运行时环境中建立原型，并用屏幕阅读器测试。

当变更请求到来时，要对变更进行考察，看其是否与现有的需求有潜在的冲突。这种变更可以破坏应用程序对一些用户的易访问性，根据项目的角色集分析每个变更。例如，如果您决定将帮助信息作为工具提示，而不是在由用户请求打开的单独的窗口中，工具提示可能对屏幕阅读器用户是不具有易访问性的。如果您的角色集隐含地包含了对与屏幕阅读器互通性的需求，您可以在变更、之前通过检查需求来预料该问题。

专家审查和用户测试

我们已经讨论过的角色驱动方法将为创建易访问产品提供基础指导，但是由于角色是唯一接近实际用户的，用专家审查和真实用户测试来补充该方法是重要的。当然，对于设计人员来说拥有关于潜在用户的完整信息并完全理解角色特性也是重要的。如果设计人员对角色所做的事情有不完善的设想，那么他们可能会设计出那种人不能实际使用的产品。由于大多数设计人员不熟悉残疾人或他们的能力，所以这种类型的错误很普遍。

避免创建在开发的后期仍旧是不具有易访问性的产品的最佳方法是在每个迭代中实施用户测试 —— 但是预算和时间的限制通常使这项工作不切实际。对于许多项目，另一种最好的方法是实施审查，利用了解残疾人特征的专家和他们对各种产品设计的结论。通过这些审查，您可以发现许多与您通过用户测试而识别的同样的设计问题，并获得如何改正问题的指导方针。

最佳的策略是在项目生命周期中让这些专家参与测试。在最开始，他们可以帮助识别产品的目标用户以及有关易访问性和可用性的管理需求。另外，他们应该根据所识别的用户基础指导创建角色的关键工作。在开发生命周期中这将花掉许多次。

在每次迭代中，这些专家根据直接推断和自己的专家经验实施易访问性审查以发现设计问题。这对早期的迭代特别重要，那个时候更容易纠正设计问题。 根据这些专家审查，随着迭代的进展，为设计人员修改角色集或澄清特征也许是必要的。

然而，虽然这种专家审查实施起来更简单并且比用户测试更便宜，但是一些设计问题只有通过用户测试才能发现。我们推荐至少在项目的早期进行一些对原型的用户测试以减少主要的易访问性风险。您的易访问性专家可以帮助计划、实施并评估这些测试。这些行为将为扩展到超过当前项目的企业带来利益。随着您调整角色以适应测试结果并向设计人员提供更有意义的描述，您将开发出在所有软件开发项目中存储并复用的有效资产。

对于用 RUP 进行的通用设计的路标

如我之前所说的，RUP 可以成为进行易访问设计的集成开发框架。本部分将提供有关这样做的大体概述（路标）。

如前面所说的，您可以修整 RUP 工作流、工作流细节、模板、报告和检验表以包含与易访问性相关的任务。

例如，一个应用我们所描述的方法的焦点是 RUP 工件用户界面原型。通过以更加正式的方式经由角色的应用得到用户界面设计，并通过使用根据已生成的评估点检查用户界面的高级工具，您可以减少开发过程早期的基础的易访问性风险。这与减少 RUP 中描述的详细描述阶段中的体系结构风险类似。

除了简单的修整，我们建议用三点补充来展开 RUP：

• 作为新的工件类型的角色
• 用于易访问性测试的评估点
• 新的易访问性经理角色

添加角色

如我们早先描述的，角色代表用户组，在工件中，他们可以由人口统计和其他数据支持。应用程序设计人员可以根据目标用户基础设计角色并将它们与产品用例联系起来。一旦您描述了它们，您就可以复用角色，用细微的修改来适应不同应用程序的环境。最终，RUP 插件可以提供覆盖许多用户的可适应的角色集，包括有各种各样残疾的人。设计人员可以使这些适合他们具体的项目环境。

添加易访问性评估点

我们的推荐是包含 RUP 中的基于普通易访问性标准和指导方针的易访问性评估点，并对各种运行时平台可用。每个评估点会提供与插件集中每个角色相关的具体平台信息，并且根据我们早先概括的种类进行分类：基本的、重要的、有益的、中立的、不便的、阻碍或排除。应用程序设计人员会根据他们所选的角色来选择一组相关的易访问性评估点。理论上，角色和相应的评估点会由工具支持基于 RUP 的半自动测试过程的商家所提供。

添加易访问性经理角色

我们建议添加新的 RUP 易访问性经理角色，该角色会检查过程调整以反映与易访问性相关的由企业和项目使用的标准和指导方针。一个（或一些）设想此角色的人会实施专家审查并且作为项目易访问性问题的顾问。然而，为目标用户设计易访问产品的实际工作仍旧是项目团队设计人员、开发人员、测试人员，和其他内行角色的责任。企业的目标是必须总是将易访问设计原则集成并根植于现有开发团队过程的和实践中。

要支持这三个对 RUP 的主要补充，企业也会扩增加一些现有的过程要素来反映易访问设计原则。例如：

• 添加描述原则的“Accessible design”概念页面，用于增强并扩充软件开发中的可用性，列出与易访问性相关的 RUP 活动，并提供对重要文献和标准的参考。
• 用与易访问性相关的活动扩充 RUP 工作流，修改现有工作流细节，而不添加新的内容。
• 更新工件，如检查点、模板和报告，来提供易访问设计原则。例如，Software Architecture Document 会有一个关于易访问性的附加部分。

结束语

本文简要地概括了一种通过推动产品开发并为迭代测试指示评估点的用例和角色来开发易访问软件应用程序的集成方法。将该方法嵌入到公认的过程框架中，如 RUP，是将其引入到开发企业中的理想方法。最后，开发 RUP 插件以将此方法的要素集成到标准的 RUP 框架中。 ¹³

除了我们已经介绍的概念，开发团队可以应用体系结构模式和用户界面模式来生成满足目标角色需求的代码。在 RUP 中，这些模式可以作为增加代码质量并增大开发生产率的设计机制而使用。

总之，我们希望本文将刺激应用程序开发企业的“内心的思考”，鼓励他们实践以用户为中心的计划并从开始就将易访问特性建立到软件产品中 —— 而不是在开发生命周期晚期把它们作为事后产生的想法。我们还希望工具厂商和 RUP 及其他开发框架的第三方供应商将开始把对易访问性的集成方法嵌入到他们的产品中。

对所有软件开发企业，我们相信本文中所介绍的方法最终将提高生产力和应用程序的质量。在制造对所有潜在用户易访问并实用的产品时，进步的企业能够利用新的市场机遇并获得强大的竞争优势。

致谢

此项工作是在 Grant H133E030012 下的，由美国教育部，National Institute on Disability and Rehabilitation Research 提供部分资助。在 Universal Interface 和Information Technology Access Rehabilitation Engineering Research Center of the University of Wisconsin, Trace Center 进行实施。此处的意见是作者的，不代表资助机构的。

注释

¹参见“The Wide Range of Abilities and Its Impact on Computer Technology。”2003 年由 Forrester Research 实施的 Research Study by Microsoft。由 http://www.microsoft.com/enable 获得。

² 参见 Application Software Design Guidelines，Version 1.1，1-June-1994。Trace Center，University of Wisconsin（在 http://trace.wisc.edu/docs/software_guidelines/software.htm 可访问）和 Web Content Accessibility Guidelines 1.0，W3C Recommendation 5-May-1999（在 http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/ 可访问）。

³参见 1) American National Standards Institute (ANSI) Draft Standard for Trial Use (DSTU) 2003: "Human Factors Engineering of Software User Interfaces." Human Factors and Ergonomics Society, Santa Monica, California 和 2) ISO TS 16071:2003: "Ergonomics of Human-System Interaction: Guidance on Accessibility for Human-computer Interfaces

⁴ 要得到易访问性标准和指导方针的列表，参看 Access Technologies Group Web 站点：http://www.accesstechnologiesgroup.com/Resources

⁵ 参见“Design Accessible Sites Now，”Forrester Report，2001 年 12 月。http://www.forrester.com/ER/Research/Report/Summary/0,1338,11431,00.html

⁶ Philippe Kruchten，The Rational Unified Process: An Introduction。Addison-Wesley，2004 年。

⁷ 参见 Ivar Jacobson，Object-Oriented Software Engineering: A Use-Case Driven Approach。Addison-Wesley，1992 年。

⁸ Philippe Kruchten，The Rational Unified Process: An Introduction。Addison-Wesley，2004 年。

⁹参见 Alan Cooper，The Inmates Are Running the Asylum。SAMS/Macmillan，1999 年。

¹⁰通过迷信的行为，我们的意思是一个人继续以不与必要相联系的特定方式做事情 —— 只是因为以前那样做。例如，电话用户可能总是在通话最后关掉电话，因为他原来的电话需要他去关掉电话来挂断。或者，某些计算机用户可能总是完全删除并将信息重新输入到新的记录中，而不要仅仅编辑旧记录 —— 一种与老技术相联系的残留行为。或者，一些进行页面规划的人可能总是使用特定的格式，因为另一个设计人员给她的印象 —— 而不是因为她理解了那个设计人员决策的基础。换句话说，当人们继续做他们曾经做的事而不质疑或理解为什么 —— 甚至如果在当前环境中该行为不再必要或者充分 —— 时，人们就在从事迷信行为。

¹¹参见 Paul Szymkowiak and Philippe Kruchten，“Testing: The RUP Philosophy。” The Rational Edge，2003 年 2 月。

¹²参见 Jim Heumann，“Generating Test Cases from Use Cases。” The Rational Edge，2001 年 6 月。

¹³参见 Web Content Accessibility Guidelines 1.0，W3C Recommendation，1999 年 5 月 5 日（在http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/ 可得到）。

¹⁴ 虽然使 RUP 本身对有残疾的开发团队成员具有易访问性的问题超出了本文的范围，但是我们目前有一个特殊的想法，就是关于视觉上减弱的人可能如何通过各种方法从事“可视化建模软件”的最佳实践。

参考资料

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