Office的背后

将Office文档转化为HTML要做几步：

• 检查颜色、对比度；如果有视频，检查视频。具体操作参考前一章
• 为包含信息的图片添加替代文本
• 当处理演示文稿软件时，需要将所有演讲中说的话制作成文字记录或字幕；取消变换效果。

PDF:创建高可用性的便携文档

PDF有三种：扫描图像；没有标签的文本；带标签的PDF。
扫描图像的PDF几乎没有什么可用性。有必要用一些特殊的软件将图像转化为文本。但这些文本在修改后依然没有标签作为支持。
然后为这些扫描图像的生成文本添加标签；检查纯文本。最终得到高可用性的PDF版本。

脚本的回应

脚本的不速之客

脚本页面需要满足的特点：

• 注意行为和样式的分离
• 页面不依赖特定的输入设备
• 页面在没有脚本情况下依然可以运行

源代码的可用性应该避免出现以下3种书写形式：

• <a href='...' onclick='[脚本在这里]'>(高耦合)
• <a href='javascript: func(...)'>（javascript不应该出现在href中，可能导致空链接）
• <a href='#' onclick='...'>（综合了上面2个的问题。）

高端脚本

Ajax虽然是使用javascript来实现富Web界面，但它依然可以具有可用性。
当Ajax发生更新时，它可能带来一些可用性问题，解决方案如下：

• 使用视觉或听觉反馈来标示页面刷新
• 向用户说明，页面会自动刷新其内容，或者告诉使用用屏幕阅读器的用户关闭Javascript
• 明确提供选择。使不喜欢Javascript的用户可以更换模式

当使用脚本实现拖放效果时，也可以提供多一个接口，用按钮的形式替代拖放。
使用API（如YUI）

WEB可用性学习（完）

信号灯和毒苹果

首先我们需要了解一下色盲

• 红绿色盲（出了大家知道的难以区分红色和绿色这个特点外，他们还会感到颜色和亮度变暗，以至于无法区分红色和黑色。最普遍的色盲，男性居多）
• 黄蓝色盲
• 全色盲（完全无法分辨色相，但对相对亮度比较敏感，极其罕见）

我们主要考虑红绿色盲，因为其他两种人群都非常罕见。
色盲用户遇到的最大问题就是用颜色作为关键字的信息。如果某种颜色在色盲模拟中表现不佳，有3个选择：

• 改变冲突的颜色之一
• 添加纹理使信息更明确
• 在关键字的说明中添加数据信息（替代的访问途径）

在黑白世界中思考

相对明度的计算公式：
（0.2126*R）+(0.7152*G)+(0.0722*R)
相对明度的值永远在0~1之间，如果两个颜色的相对明度过于接近，就说明对比度太弱了

择路而行

为所有的<img>和<area>添加alt=属性，这个很容易实现。问题的关键在于如何书写正确的替代文本。

• 首先alt里面是简短的文本，字数在40-80字母之内。
• 使用类似“……的图像”这样的说法。
• 避免在替代文本中提供其他方式中没有的信息。

由于有效的<img>都具有alt=属性，所以这意味着有可能会出现alt=”这样的空属性。两种情况下会出现这种情况：

• 冗余的图像
• 装饰性图像

alt=之外

有的时候图像表现的内容太多，以致无法简略地进行总结，这种情况下可以把说明写在单独的页面上，然后用longdesc=属性连接起来。注意，longdesc是alt的扩充，而不是替代。
一个比较好的例子就是图表。对于这种情况，有3种策略：

• 将内容最小化
• 依靠longdesc=
• 在叙述文本中进行说明

对于一些简单的图像，是完全不需要图像，比如用HTML和CSS来构建一个柱状图。

别让视频破坏你的网站

不要粗鲁地闪你的读者

为网站添加视频和多媒体内容时，应当注意是否存在闪烁。感光性癫痫在受到特定的视觉刺激时，会不同性质，不同程度地发作。
闪烁是指任何形式的视觉输入在高亮度和低亮度之间来回反复切换。对于感光性癫痫，特别注意2-55Hz的闪烁。
对于闪烁的阈值，这样定义：

• 相对明度超过10%的变换序列都可能是闪烁变换，如果在1秒时间内，序列出现3次或更多就属于超过阈值。
• 如果是小块闪烁往往不认为有害。当闪烁范围占据超过了屏幕像素的十六分之一的矩形大小就认为超过阈值。

如果某一段视频中闪烁是必须的内容，那么请在开始前给予警告。

午夜吱吱嘎嘎走过的文字幽灵

为视屏提供字幕使视频对听力障碍具有可用性。请注意subtitle和caption的区别。前者被设计为提供外语翻译。后者主要为听力障碍者设计。我们重点在于后者。
一个好的caption要做到：

• 保持相关性，提供的信息不能太少也不能太多。
• 任何重要的词语都应该在字幕中体现。
• 如果说话人不明确，应当在字幕中指明说话人。如果会破坏内容，则抽象地指出说话人
• 描述重要的背景声音，忽略无关的。
• 字幕必须同步。

请讲给我听

为视觉障碍者改进视频，在相关性方面和创建caption大同小异。

• 只说该说的话。因为添加解说会使视频的其他背景减弱甚至是视频暂停。
• 内容过多，声音描述应付不过来。如果内容是重要的，需要在视频中创建暂停，引导用户自主得去查看内容。

剪辑室里的秘密

提供一些处理视屏的格式：

• SubRip SRT和SubViewer SUB这是简单字幕格式，非常常用。
• SAMI 微软提供的，制作用HTML形式呈现。
• QuickText 苹果quickTime的某种格式。
• SMIL W3C的解决方案，形式类似XML
• DXFP W3C的用于分发和传输时控文本的解决方案。
• MAGpie 一个字幕处理工具。

不要成为控制狂

• 让用户知道我们将要做什么
• 考虑是否“自动播放”，这个选择权应该交还给用户
• 增加控制按钮，而不是只有开始

对不起，时间到

消灭不必要的时间效果：

• 页面重定向
• 系统超时（确保程序关键路径尽可能简短、简单）

让<form>更正式

为它加个<label>

为它和表单元素增加说明
tips:

• 避免将<input>放在<label>中，这和使用<label>的初衷背道而驰
• 对于隐藏元素无需增加<label>说明，因为他们本来就不打算被访问
• 对于文件上传<input>，增加<label>是必须的

将鸡蛋和火腿放一个篮子里

当一组选择（单选或多选）其实是不同类型的时，可使用<fieldset>+<legend>的嵌套来代替<label>是更好的选择
当同样情况发生在<select>中时，使用<optground>(注意这个无法嵌套)

与键共舞

首先，accesskey和tabindex作为针对无法使用指向设备和依赖键盘导航的用户的解决方案是不提倡使用的。甚至被建议为完全不去使用。

访问的快捷键

• 用户需要为网站所使用的快捷键付出学习成本
• 快捷键可能覆盖系统和浏览器的快捷键设置

Tab键上的内容

tabindex打破了页面的自然阅读顺序，有时会带来一些奇怪的跳跃。

界面要简单易懂

为了将用户的注意力集中在当前任务上，我们要让界面简单易懂。

• 动作计数
• 比较两个界面

动作计数多不一定意味着界面不够简单易懂，有时为了形象可能会损失一些动作计数。关键在于减少无谓的复杂度。

我们需要为table添加额外的信息，用来描述它，这对屏幕阅读器的依赖者有益。

马上使用<thead>

<thead>和<tfoot>标签用于设置表头和表尾，在其中用<th>来标记单元格。而表格的主要内容在<tbody>中
tips:

• 只能有一个<thead>和<tfoot>（<tfoot>是可选的），但是<tbody>可以有多个；
• <thead>和<tfoot>要出现在<tbody>之前。

为表格加标签

用<caption>标签为表格指定标题，它位于<table>之后的第一个标签（<thead>之前），在<table>中添加summary属性来对表格进行描述。

啊！我所不知道的<table>

为了使屏幕阅读器使用表格，我们需要添加信息将表头内的单元格和内容联系起来。

连接表头与表格其余部分

通过scope=row/cols属性来明确某个单元格的表头是标题行还是标题列。

双重表头

通过对单元格设定headers属性可以为表格中的一项指定多个表头，这个要通过id属性为表头赋予标志（banum注：与页内锚点的使用类似）。
abbr属性是缩写，在阅读器中可能读出abbr的值，headers顺序和阅读顺序可能是相关的。

轴：信息的联盟

有的时候信息是多个维度的（超过两个维度）。一种较高的的要求是指使用一个表格来表现。这需要使用axis属性。
有的时候将表格拆开是更好的做法，因为使用axis对于普通用户和屏幕阅读器都是相当的负担。当很难讲表格按维度分割时，才使用这个属性。
附例子：
（请通过源码查看该示例）

布局和其他不良的表格习惯

滥用表格导致的3个问题：

• 布局管理困难
• 降低网页速度
• 降低页面可用性（请考虑屏幕阅读器是线性的）

如果必须使用表格布局

为了可用性，请考虑表格的线性顺序（从左到右、从上到下）。处理不当，会使用户的操作流程不断被打断，甚至产生误解，最糟糕的结果是失去用户。

当表格不是表格

列表不是表格

表格和表单

尝试用<fieldset>来代替表格作为表单的容器。

创建语义内容的第一步，是正确使用标记语言。目标是使内容清晰明了。

阅读顺序

如标题标签不应该越级

使用故事板避免混合内容和表现

不要试图使最终设计与故事板丝毫不差。

用微格式增加更多信息

软件可以将信息提取出来，用不同格式展现。微格式是方法论，而不是技术

自定义格式

用div+css+class以标志出信息类型即可，为用户提供可能的语义环境。

简单就是美

使用开门见山的语言来增加内容的可用性。按面向用户的类型选择内容的语言水平。

特殊术语

对于术语，如果用户群是专业用户，则可不用提供定义。否则要增加定义，如果术语很多要提供词汇表，但首次使用时定义依然不可缺少，因为在正文与词汇表之间的跳跃会增加用户的负担。

我看不懂希腊文

在必要的地方增加lang属性（这里指外语，外来词）。

成语的雷区

避免过度使用成语、俚语等。

缩写亦须明意

使用<abbr>处理简写。使用<acronym>标记处理缩写。在title中使用完整内容。

注意<p>和<q>

字体和格式

避免使用非语义的标签，用其他标签代替他们：
用<strong>代替<b>表现粗体；
用<em>、<var>代替<i>表现斜体；
用<strong>、<em>代替<u>表现下划线；
用<del>代替<s>表示删除线；
用<ins>表示上划线；
用<code>、<kdb>、<samp>、<var>代替<tt>表示等宽字。

框架

减少使用框架，或在<noframe>中提供替代版本。

链接在一起

让链接引人注目

清晰地使用链接，不要模糊他们的意图。
使用有别于其他元素的显眼颜色标注。同时防止链接相互紧挨。

明确链接的目标

给链接添加描述的元数据。避免使用<a href=”#here”>点击这里</a>这样的表述。（banum注：关于这个业内有很多讨论。从可用性角度分析，应该这么做。）

“跳转到内容”链接

添加页内锚点以方便有障碍的用户，却依然使全能力者得到好处。（banum注：关于这一点，其他专家同样有很多不同的看法。）

样式：华丽的盛装

使用CSS要注意分清内容和表现，确保失去的样式，内容依然是内容，即不要使用<span>来表现<h1>。
再者要在css标准与实际应用中找到平衡点，有些建议标准没有得到广泛支持，减少或者避免使用。

测试应该在最初就被得到关注。可用性成本高的项目有两类：

• 大量需要文本替代物的媒体项目（不可削减）
• 开发末期加入可用性导致的两次创建内容的成本（可削减）

从上面的分类可以看出最初就考虑测试和可用性开发可以减少成本。
第一天就开始测试，即每做一步都测试可用性，然后渐进地添加新功能和样式。

动手去做

手工测试

• 检查替代文本的恰当性(alt、lable、声音的文字记录和字幕)
• 关闭图像，看内容是否有意义（或是否中断页面流向）
• 关闭样式表，看是否按自然阅读顺序构建web产品
• 检查其他分辨率，确保在低分辨率下可用
• play unplugged，放弃鼠标，看看依靠键盘是否可浏览（甚至考虑屏幕阅读器）

让残障用户参与过程

• 组成焦点小组
• 加入残障作为全程的测试人员

测试考虑的问题

• 哪些任务无法完成，为什么？
• 完成某任务是否耗时过长？
• 用户完成任务时，界面是否舒适？

选择使用多种途径的目的是为了向用户以最佳的方式呈现信息，这取决于用户如何访问网站。
如果一段内容依赖于特定媒体的表现（如视频中的画外音），我们就至少要提供一种替代表现方式（我们添加字幕）。最终，我们希望用尽可能少的途径来覆盖尽可能多的用例。这并不意味着我们只是简单的在页面上罗列内容的几个不同版本。
在使用替代方案时要注意途径是否合理，确保没有使残障用户迷失方向的“黑洞”，以及允许其他完全用户进一步研究的能力。如果只是简单罗列替代版本，这可能导致

用户过载（overload）

这个说法基于感知负荷理论（cognitive load theory），即人用于某事的精神是有限的。除了信息本身带来的负载我们无能为力以外，我们需要减少因为信息的表现形式所导致的外来负荷，即使信息更容易理解。需要注意的是，非互补的信息会带来障碍。如为视频提供字幕，如果字幕与视频不同步，就会增加障碍。此外，如果互补信息跨越了多个页面(banum注：如某些注释链接需要开新的页面)，用户就需要在导航和界面上消耗精神资源。

牢记媒体的属性

每一个媒体的属性都是不相同的，所以我们需要考虑他，然后提供额外的信息作为该媒体类型缺失属性的补偿。对于交互元素，如果这个交互元素很重要，就需要设计替代的控制和响应来使不具有感应能力的也可以交互。
这里需要注意一点，设计一个大部分用户都一目了然的页面和为每个用户都设计一个页面是有巨大区别的。如果可能就要避免后面那种情况。

不要重复工作

如果项目中包含相互依赖的重复，事情变得糟糕，修改的工作量会按乘法增加。在某个系统中，一条知识必定有单一、明确、可靠的表现方式。
为了做到这一点，我们需要

进行抽象

我们需要许多真正有用的基本要素。 这个要素能够在多个地方使用，同时要避免上层的修改反过来影响这些要素。

避免一次性的决定

当系统需求中出现“一次性”的请求时要判断它是不是真的是一次性请求，如果真的是要把这个样式变化限制在一个特定页面上，以减少未来维护的开销；如果这个一次性请求（通常是如此多的一次性请求）其实是因为系统漏洞引起的，那么应该向开发者提出意见，在未解决前依然使用前面的方法来处理这个请求，即局部样式；如果这个一次性请求是内容开发者过于追求某个想法的最初观点而产生的特定语言，那么可能可以用已有的标记和样式来表达，重新审视它吧。

使用模板系统

并不是所有的模板系统都可以解决重复问题。请使用支持数据、接口和表现的最佳分离的模板系统吧。

如软件工程中不断提到的那样，在《Design Accessible Web Sites》中也提及了可用性计划要在项目初期进行，以减少后期因为可用性重构而引起的高费用。
文中提到计划分可以为如下两个部分：

• 样式指南
• 修订计划

让我们一个一个来看：

样式指南

关键字：最有价值的产物
形式：wiki上的页面、由计划小组创建的文档
作用：解释内容的标签和样式以及能反映产品目标的媒体获取标准。
具体：
结构化标签。
    将内容和表现分离。样式指南每种内容对应的标签。
文档化的输出格式。
    将每种格式都输出为文档。
内容样式。
    以一致的方式清晰写出内容，目的在于减少读者负担。尤其对于专业用户，请参考对应的标准。
媒体获取标准。
    确保输出格式能够恰当呈现多媒体资产。这可能涉及到资产的属性、内容以及储存形式，甚至是替换形式。

修订计划

制定了计划以后应该经常修订。
步骤：

1. 将修订建议添加到主修订列表
2. 考虑修订的影响
3. 审查修订列表，对于改变做好记录以方便驳回修订。
4. 确定要做什么

如：

• 该修订是否需要获取新的内容？
• 是否需要新的标签形式？
• 当前的到黄和搜索系统是否满足需要？或者，是否需要新的东西？
• 是否须要为内容准备新的布局？
• 该修改是否要求使用多媒体元素，以致需要生成字幕或声音的文字记录？
• 关于这个新的标签需求的哪些信息应当写进样式指南中？
• 新的内容是否需要更多的基础结构支持？
5. 将任务分派给适当的人并决定截止日期。

生产高质量的web内容需要几个领域的专业技能互相合作。因此我们需要组建一个团队，而不是单兵作战：

• 项目干系人
• 内容作者
• 用户界面设计师
• 视觉特性设计师
• 软件工程师/基础结构开发者

tips:

• 对于小团队：几个代言人的职责有可能重叠（即一个人代表多个职责），但要明确每个时间点其应该代表的角色。
• 对于大团队：团队中各个人员代表不可太多，最多不超过2个。

项目干系人

(banum注：在企业中其可能的职称：PD,PM,RA。包括且不等于这些职称)
项目干系人是项目愿景背后的人。在项目中处于领导者。其拥有可用性的最抽象需求。
在可用性需求上，项目干系人应该掌握哪些需求能在内容设计过程中实现。并且了解团队在可用性设计过程中可能遇到的困难，并协助找到解决困难的方法。
在可用性责任上，项目干系人应了解其他成员的需求，并使其实现。要确保协商顺利完成，达成一致。时刻将项目放在正确的方向上。

内容作者

(banum注：在企业中可能的职称：内容编辑，运维等。包括且不等于这些职称)
内容作者产出内容资产（文字、插图或者流媒体），其与视觉特性设计师正好相对。
在需求上，内容作者需要界面设计师为其提供多种界面设计，需要图形设计师为其提供多种互相补充的格式；基础结构开发师（banum注：可以理解为前端开发，产出实际可用的前端结构的人。）为其提供适当的界面。
在责任上，内容作者需确保内容简明易懂；当需求变化时，内容作者应当跟进；内容作者需要提供各种媒体资产的描述（alt、longdesc以及其他）。

用户界面设计师

创建必要的内容布局，确保共同导航、多种途径。
在需求上，需要与内容作者和视觉设计紧密协作，以制定媒体标准；在设计替代界面时，需要和图形设计师合作，确保一致性，这也有可能需要内容作者的介入。
在责任上，确保设计有正面的效果；默认界面必须具有可用性；确保界面符合项目干系人和内容作者的愿景。

视觉特性设计师

（banum注：企业中可能的职称有视觉设计师，ued，美工，包括且不等于上述职称）
视觉特性设计师有时会在可用性上受到批评（布局图像可能使一些残障遇到障碍）。好的设计师能在设计的自由与限制之间取得平衡。
在需求上，如前面所说，设计师需要了解这些给定的限制；基础结构开发者可以为视觉特性设计师提供方法，方便其保存样式和媒体。
在责任上，是高可用性方式来满足视觉标准；如果标准与可用性冲突，这是设计师需要担起的责任；个别的视觉元素，可以创建替代信息（alt）。

基础结构开发者

(banum注：企业中可能的职称有：DBA，程序员，前端开发…包括且不等于)
开发者是内容、界面、设计的实现者。
在需求上，开发者可以获得需求，得到反馈，了解产品的期望，以方便开发和测试。
在责任上，开发者应满足其他组的需求；使其他组理解可行的方案和代价；提供访问工具；向内容小组和设计小组提供测试结果。

可用性协调员

(banum注：国内可用性设计起步甚晚，大多公司都不具备这个类型的专业人士。)

• 可用性协调员确保环境的所有方面可以被残障用户使用。
• 可用性协调师可以在很大程度上节约成本。
• 可用性协调师的工作应该在计划阶段就开始进行。

保持团队的凝聚力

tips:

• 经常碰头：简短的会议，并确保人人到场。
• 维护项目的wiki：重点在于知识的共享。
• 进行室外活动：重点在于互相了解。