【IT168 技术文章】

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

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

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

    一般软件

    主要的操作系统和平台

    Web

    E-learning应用程序

    公共终端

    电信和其他领域

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

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

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

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

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

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

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

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

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

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

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

    收集需求

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

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

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

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

    应用程序的使用必须简单——没有人希望为进行银行业务而阅读手册。

    应用程序必须对各种各样的人可用：男人和女人，年轻人和老年人（也许太虚弱以至于不能去银行），说英语的和说西班牙语的，有经验的计算机用户和技术恐惧者。

    应用程序必须对老年人和其他阅读小文本时有困难的人是可用的。应用程序必须对所有年龄的手不灵巧很难使用鼠标的人是可用的。

    应用程序必须适于在家庭环境中使用。大多数客户会通过Internet连接用家庭计算机访问应用程序。

    用户应该拥有当处理电汇订单时可以断开的能力，因为他们按分钟支付Internet费用。

    图像要容易辨别，甚至对那些视力差的用户。

    对于盲人，至少要有一个屏幕阅读器在目标执行平台上是可用的，并且要与应用程序配合得很好。换句话说，要将产品设计成可以提供音频输出的。

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

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

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