总之，评估点和角色之间的关系可以被描述成七个值：
1.基本的
2.重要的
3.有益的
4.中立的
5.不便
6.阻碍
7.排除
目标是在不为其他产品生成排除或阻碍因素的情况下为一个产品满足所有基本标准及对所有角色尽可能多的重要标准。
在标准和指导方针的理想集合中，每个指导方针会有多种评估点集，每个集合与具体的平台有关。按照那种方式，您可以在项目中间转向运行时平台并简单地将您原来的评估点集换成适应新平台的集合。您的需求——基于角色集——仍旧稳定，并且仍旧推动评估点对新平台的选择。
减轻与易访问性相关的风险
在任何应用程序开发项目中，项目经理必须确保按照需求、准时，且在预算之内开发产品。当使用RUP中具体化的迭代开发方法时，项目经理保留着一个按照出现和影响可能性排列的风险列表。每次连续的迭代处理最可能在那时出现并对产品有严重的负面影响的风险。团队通过观察产品没有满足的需求来得到这些风险。如果他们将易访问性需求加入他们的初始集中，那么他们可以在早期减少易访问性风险，就像他们对其他可用性问题做的一样。
例如，在RUP的构建阶段，开发人员也许会确定产品不能由利用屏幕阅读器的角色进行访问。要减少该风险，团队可以在目标运行时环境中建立原型，并用屏幕阅读器测试。
当变更请求到来时，要对变更进行考察，看其是否与现有的需求有潜在的冲突。这种变更可以破坏应用程序对一些用户的易访问性，根据项目的角色集分析每个变更。例如，如果您决定将帮助信息作为工具提示，而不是在由用户请求打开的单独的窗口中，工具提示可能对屏幕阅读器用户是不具有易访问性的。如果您的角色集隐含地包含了对与屏幕阅读器互通性的需求，您可以在变更、之前通过检查需求来预料该问题。
专家审查和用户测试
我们已经讨论过的角色驱动方法将为创建易访问产品提供基础指导，但是由于角色是唯一接近实际用户的，用专家审查和真实用户测试来补充该方法是重要的。当然，对于设计人员来说拥有关于潜在用户的完整信息并完全理解角色特性也是重要的。如果设计人员对角色所做的事情有不完善的设想，那么他们可能会设计出那种人不能实际使用的产品。由于大多数设计人员不熟悉残疾人或他们的能力，所以这种类型的错误很普遍。
避免创建在开发的后期仍旧是不具有易访问性的产品的非常好的方法是在每个迭代中实施用户测试——但是预算和时间的限制通常使这项工作不切实际。对于许多项目，另一种最好的方法是实施审查，利用了解残疾人特征的专家和他们对各种产品设计的结论。通过这些审查，您可以发现许多与您通过用户测试而识别的同样的设计问题，并获得如何改正问题的指导方针。
非常好的的策略是在项目生命周期中让这些专家参与测试。在最开始，他们可以帮助识别产品的目标用户以及有关易访问性和可用性的管理需求。另外，他们应该根据所识别的用户基础指导创建角色的关键工作。在开发生命周期中这将花掉许多次。
在每次迭代中，这些专家根据直接推断和自己的专家经验实施易访问性审查以发现设计问题。这对早期的迭代特别重要，那个时候更容易纠正设计问题。根据这些专家审查，随着迭代的进展，为设计人员修改角色集或澄清特征也许是必要的。
然而，虽然这种专家审查实施起来更简单并且比用户测试更便宜，但是一些设计问题只有通过用户测试才能发现。我们推荐至少在项目的早期进行一些对原型的用户测试以减少主要的易访问性风险。您的易访问性专家可以帮助计划、实施并评估这些测试。这些行为将为扩展到超过当前项目的企业带来利益。随着您调整角色以适应测试结果并向设计人员提供更有意义的描述，您将开发出在所有软件开发项目中存储并复用的有效资产。
对于用RUP进行的通用设计的路标
如我之前所说的，RUP可以成为进行易访问设计的集成开发框架。本部分将提供有关这样做的大体概述（路标）。
如前面所说的，您可以修整RUP工作流、工作流细节、模板、报告和检验表以包含与易访问性相关的任务。
例如，一个应用我们所描述的方法的焦点是RUP工件用户界面原型。通过以更加正式的方式经由角色的应用得到用户界面设计，并通过使用根据已生成的评估点检查用户界面的高级工具，您可以减少开发过程早期的基础的易访问性风险。这与减少RUP中描述的详细描述阶段中的体系结构风险类似。
除了简单的修整，我们建议用三点补充来展开RUP：
作为新的工件类型的角色
用于易访问性测试的评估点
新的易访问性经理角色
添加角色
如我们早先描述的，角色代表用户组，在工件中，他们可以由人口统计和其他数据支持。应用程序设计人员可以根据目标用户基础设计角色并将它们与产品用例联系起来。一旦您描述了它们，您就可以复用角色，用细微的修改来适应不同应用程序的环境。最终，RUP插件可以提供覆盖许多用户的可适应的角色集，包括有各种各样残疾的人。设计人员可以使这些适合他们具体的项目环境。
