I'm banum 技术回归人本

WEB可用性学习<七>圆桌

表格的基础

我们需要为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对于普通用户和屏幕阅读器都是相当的负担。当很难讲表格按维度分割时，才使用这个属性。
附例子：
（请通过源码查看该示例）

My Music

Artist	Album Title	Media Format
		Compact Disc	MP3
Magnetic Fields	69 Love Songs	Yes	No
Song Title			Rating
Absolutely Cuckoo			****
I Don’t Believe In The Sun			****
U2	Zooropa	Yes	Yes
Song Title			Rating
Zooropa			*****
Babyface			**

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

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

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

如果必须使用表格布局

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

当表格不是表格

列表不是表格

表格和表单

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

WEB可用性学习<六>结构化生活

言之有物

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

阅读顺序

如标题标签不应该越级

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

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

用微格式增加更多信息

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

自定义格式

用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标准与实际应用中找到平衡点，有些建议标准没有得到广泛支持，减少或者避免使用。

WEB可用性学习<五>

设计时就考虑测试

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

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

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

动手去做

手工测试

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

让残障用户参与过程

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

测试考虑的问题

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

WEB可用性学习<四>第三部分

多种访问途径

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

用户过载（overload）

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

牢记媒体的属性

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

不要重复工作

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

进行抽象

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

避免一次性的决定

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

使用模板系统

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

WEB可用性学习<四>第二部分

做好可用性计划

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

• 样式指南
• 修订计划

让我们一个一个来看：

样式指南

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

修订计划

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

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

如：

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

WEB可用性学习<题外话>

今天在google搜索相关内容时，发现一位淘宝网的朋友前不久也写了一篇《Design accessible web sites》的学习笔记，不过他的是简明提纲版的，我的blog更新得比较慢（自己比较懒），急着看完的看官可以去他的blog看看，所以上来一个链接maxbbn>>阅读笔记《创建高可用性的Web内容》

WEB可用性学习<四>第一部分

发挥团队的作用

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

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

tips:

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

项目干系人

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

内容作者

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

用户界面设计师

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

视觉特性设计师

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

基础结构开发者

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

可用性协调员

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

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

保持团队的凝聚力

tips:

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

WEB可用性学习<三>

前一段时间在阿里巴巴实习，一时没时间更新blog一晃就是半年，半年后回来继续以前的话题：web可用性。第三篇涉及到进行可用性研究针对的核心目标人群：残障。

残障的简介

残障主要分为以下4类：

• 视觉残障
• 听觉残障
• 行动残障
• 认知残障

视觉障碍是web开发的主要关注点，因为如果需要为视觉障碍者创建可访问的内容，那么这将会涉及web开发的所有方面。
关于视觉障碍的一些tips:

• 多数弱视者使用屏幕放大镜
• 并非所有的盲人都使用盲文
• 如果为色盲设计,需要特别注意颜色，或许可以提供专用样式表
• 重复图案和闪烁可能引起感光性癫痫
• 尝试为包含信息的视觉元素添加适当的替代文字
• 确保站点能够通过键盘浏览

听觉障碍对网站可用性问题造成的问题要小很多，如果网站不依赖于声音，几乎没有访问障碍。
关于听觉障碍的tips:

• 为失聪者提供字幕和文字记录，且确保与媒体同步。字幕中应包含一些非对话的重要声音。

行动障碍指一个或多个肢体运动受限或丧失运动能力的情况。
tips：

• 减少页面上不必要的时间效果。
• 减少小图标或者紧凑导航，增大响应区域。看看apple是怎么做的

认知障碍指人的大脑处理信息时的缺陷和不正常。这是最大、最抽象的残障种类。
关于认知障碍的tips:

• 创建简单易懂的内容。
• 创建多种访问方式。

多重障碍指同时具有多种障碍的人，对于这样的用户，我们需要采取均衡的策略。