测试应该在最初就被得到关注。可用性成本高的项目有两类：
从上面的分类可以看出最初就考虑测试和可用性开发可以减少成本。
第一天就开始测试，即每做一步都测试可用性，然后渐进地添加新功能和样式。
选择使用多种途径的目的是为了向用户以最佳的方式呈现信息，这取决于用户如何访问网站。
如果一段内容依赖于特定媒体的表现（如视频中的画外音），我们就至少要提供一种替代表现方式（我们添加字幕）。最终，我们希望用尽可能少的途径来覆盖尽可能多的用例。这并不意味着我们只是简单的在页面上罗列内容的几个不同版本。
在使用替代方案时要注意途径是否合理，确保没有使残障用户迷失方向的“黑洞”，以及允许其他完全用户进一步研究的能力。如果只是简单罗列替代版本，这可能导致
这个说法基于感知负荷理论（cognitive load theory），即人用于某事的精神是有限的。除了信息本身带来的负载我们无能为力以外，我们需要减少因为信息的表现形式所导致的外来负荷，即使信息更容易理解。需要注意的是，非互补的信息会带来障碍。如为视频提供字幕，如果字幕与视频不同步，就会增加障碍。此外，如果互补信息跨越了多个页面(banum注：如某些注释链接需要开新的页面)，用户就需要在导航和界面上消耗精神资源。
每一个媒体的属性都是不相同的，所以我们需要考虑他，然后提供额外的信息作为该媒体类型缺失属性的补偿。对于交互元素，如果这个交互元素很重要，就需要设计替代的控制和响应来使不具有感应能力的也可以交互。
这里需要注意一点，设计一个大部分用户都一目了然的页面和为每个用户都设计一个页面是有巨大区别的。如果可能就要避免后面那种情况。
如果项目中包含相互依赖的重复，事情变得糟糕，修改的工作量会按乘法增加。在某个系统中，一条知识必定有单一、明确、可靠的表现方式。
为了做到这一点，我们需要
我们需要许多真正有用的基本要素。 这个要素能够在多个地方使用，同时要避免上层的修改反过来影响这些要素。
当系统需求中出现“一次性”的请求时要判断它是不是真的是一次性请求，如果真的是要把这个样式变化限制在一个特定页面上，以减少未来维护的开销；如果这个一次性请求（通常是如此多的一次性请求）其实是因为系统漏洞引起的，那么应该向开发者提出意见，在未解决前依然使用前面的方法来处理这个请求，即局部样式；如果这个一次性请求是内容开发者过于追求某个想法的最初观点而产生的特定语言，那么可能可以用已有的标记和样式来表达，重新审视它吧。
并不是所有的模板系统都可以解决重复问题。请使用支持数据、接口和表现的最佳分离的模板系统吧。
如软件工程中不断提到的那样，在《Design Accessible Web Sites》中也提及了可用性计划要在项目初期进行，以减少后期因为可用性重构而引起的高费用。
文中提到计划分可以为如下两个部分：
让我们一个一个来看：
关键字：最有价值的产物
形式：wiki上的页面、由计划小组创建的文档
作用：解释内容的标签和样式以及能反映产品目标的媒体获取标准。
具体：
结构化标签。
将内容和表现分离。样式指南每种内容对应的标签。
文档化的输出格式。
将每种格式都输出为文档。
内容样式。
以一致的方式清晰写出内容，目的在于减少读者负担。尤其对于专业用户，请参考对应的标准。
媒体获取标准。
确保输出格式能够恰当呈现多媒体资产。这可能涉及到资产的属性、内容以及储存形式，甚至是替换形式。
制定了计划以后应该经常修订。
步骤：
如：
Powered by WordPress