学习python 第四版
七/100
其实已经不是Python的纯新手了，之前赶项目的时候用过python，由于时间比较急，所以就挑了一本不怎么样的书大致看了一下，本来想做完就扔掉的，没想到通过这个项目我却迷上了这个动人的语言，所以就找了这本饱受好评的learning python来看了。最新的第四版，暂无中文版，我就自行翻译了。英语未过4级，语文也不好，结果估计会比较悲剧，看官们请不要介意啊。
原书名：Learning Python 4th Edition
作者：Mark Lutz
翻译者：Banum
前言
This book provides an introduction to the Python programming language. Python is a popular open source programming language used for both standalone programs and scripting applications in a wide variety of domains. It is free, portable, powerful, and remarkably easy and fun to use. Programmers from every corner of the software in-dustry have found Python’s focus on developer productivity and software quality to be a strategic advantage in projects both large and small.
这本书介绍了Python这种编程语言。 Python是一种在独立程序和脚本领域广泛使用的开源语言。它是免费、轻量、功能强大的，它非常容易使用同时充满了乐趣。来自软件业各个角落的程序员们发现无论项目大小，Python都能着眼于在软件生产率和软件质量两个方面，获得巨大的战略优势。
Whether you are new to programming or are a professional developer, this book’s goal is to bring you quickly up to speed on the fundamentals of the core Python language. After reading this book, you will know enough about Python to apply it in whatever application domains you choose to explore.
无论你是编程菜鸟还是专家，这本书的目标就是带你在Python核心编程基础上获得快速提升。读完这本书，你就能够对Python有一个足够的了解，使它适用于每一个你选择探索的应用领域。
By design, this book is a tutorial that focuses on the core Python language itself, rather than specific applications of it. As such, it’s intended to serve as the first in a two-volume set:
- Learning Python, this book, teaches Python itself.
- Programming Python, among others, shows what you can do with Python after you’ve learned it.
在设计时，这本书被定位为一本重点讲述核心Python编程本身的教程，而不是着眼于特定的应用领域。所以，这本书的目标是成为下面两类中的前者：
- 《学习Python》，也就是这本书，教授Python本身。
- 《Python编程》，其他那些中的一本，展现你学习了Python以后可以做什么。
That is, applications-focused books such as Programming Python pick up where this book leaves off, exploring Python’s role in common domains such as the Web, graphical user interfaces (GUIs), and databases. In addition, the book Python Pocket Reference provides additional reference materials not included here, and it is designed to supplement this book.
即，重点于应用的书（比如《Python编程》）应该在这本书读完后拿来继续研习，用以探索Python在Web、图形用户界面(GUI)以及数据库等常规领域的角色。此外，《Python袖珍参考书》这本书所提供的额外的参考材料本书也没有涉及，它被设计为对本书的另外一种支持。
Because of this book’s foundations focus, though, it is able to present Python fundamentals with more depth than many programmers see when first learning the language. And because it’s based upon a three-day Python training class with quizzes and exercises throughout, this book serves as a self-paced introduction to the language.
正因为这本书的基础目标（尽管第一次学习一种语言我们可以学得比很多程序员所看到得更深入），也因为这本书是在为其3天的带有练习和测试的Python教学课的难度基础上，这本书将会以适合自学的方式来介绍这种语言。
关于第四版
This fourth edition of this book has changed in three ways. This edition:
- Covers both Python 3.0 and Python 2.6—it emphasizes 3.0, but notes differences in 2.6
- Includes a set of new chapters mainly targeted at advanced core-language topics
- Reorganizes some existing material and expands it with new examples for clarity
As I write this edition in 2009, Python comes in two flavorversion 3.0 is an emerging and incompatible mutation of the language, and 2.6 retains backward compatibility with the vast body of existing Python code. Although Python 3 is viewed as the future of Python, Python 2 is still widely used and will be supported in parallel with Python 3 for years to come. While 3.0 is largely the same language, it runs almost no code written for prior releases (the mutation of print from statement to function alone, aesthetically sound as it may be, breaks nearly every Python program ever written).
未完。。等待晚上编辑
我也来谈谈“腾讯qq空间失败的理由”
七/102
今天看到了Kai Lukoff的一篇帖子的翻译。说的是腾讯qq空间失败的3个理由。归结起来，有：
- 错失良机
- 差劲的站点设计与功能
- qq空间并非真正的No.1
同译者一样，本人也认为这位老外的观点略有偏颇，过于刻薄，但也不乏冷静的分析，部分地方写得一针见血。且不说qq空间是否失败这个问题，但是这一点毋庸置疑，qq空间不算成功。相比人人和开心，qq空间总是逊了别人一大截。
Lukoff提到qq依靠其巨大的用户群体，所以即使qq空间的服务实在够烂但依然能够盛行于世。这一点我非常赞同，而这句话的前半句，不就是众多中国互联网创业者最害怕腾讯插足的原因之一么？
对于Lukoff说的第一个原因，我不得不说自己的观点，其实腾讯的众多服务都有一个特点，他们总是不是第一个登陆中国的该类服务。qq空间前有人人网(facebook被天朝咔嚓了)，qq的拍拍前有淘宝。就连qq本身，在他之前也已经有icq了（当然这个非本国，但在互联网初期他在国内的确有一定的市场占有率）。在这样的一个大好惯例下，腾讯就永远坐着千年老二（通常还是山寨老二），而且坐得很稳，坐得很爽。所以腾讯的错失良机是有优良传统的。正因为没有别的企业能够像腾讯那样，在那么多的领域都能坐稳第二把交椅，所以在年财报上，腾讯才能真正坐稳第一把交椅。
有人可能会说，qq空间很早之前就有了，那个时候还没有人人网。但是早期的qq空间有很多弊病。那个时候的qq空间和qq客户端之间有着很高的耦合性。比如说，如果没有qq客户端作为中介，要直接去访问一个朋友的空间是不那么容易做到的。那时的qq空间更像是一个blog空间，而不是严格意义上的sns。
再者，Lukoff提到的离开校园后，用户的份额流向了人人和开心其实也是有原因的。因为在一个时期的中国本土企业，上班时间开qq总给人感觉是不认真工作的象征（只可能是导致qq大力推广im的原因之一），而之前我所提到的qq空间与qq客户端高耦合的弊病最终导致了用户流向了只要有浏览器就能很方便来社交和游戏的其他sns服务。而等到qq形象改变以及服务更新（比如解耦），明显已经落后于别人了。而sns固有的特点，可以称之为病毒式营销，使得份额流失的趋势很难在短期内逆转，这很有可能是qq空间不成功的原因之一（这让我想起我刚进大学的时候，我不得不放弃一直使用的联通而选择移动，因为学校里的大多数人都使用移动。）。
Lukoff还提及了qq空间存在的系统繁忙的问题。这个问题把腾讯往不成功的路上狠狠推了一把。说来好笑，其实这个系统繁忙在腾讯也是由来已久，记得oicq刚开始热起来的时候，每次申请qq号，都会遇到这个熟悉的“系统繁忙，请稍后再试”。不同的是，那个时候腾讯提供给了广大用户第二条不会繁忙的路：花一元钱买一个qq号；而这一次，我们所能选择的只有稍后再试了。这个后遗症正是我后来一直不大愿意使用qq空间的主要原因，就在前几天，我还遭遇到了这个问题。
Lukoff提到的第二点站点设计和功能。对于这一点我不是非常得苟同。因为这与qq的主要市场定位有关：年轻一代。过于朴实和单调的色彩搭配往往无法引起少年一代的兴趣。而用人民币堆砌的花哨，蹩脚，复杂以及混乱的页面却正迎合了这样一群人的口味。而且qq的消费排行榜（不知道现在还有没有）很好的激发了用户的消费炫富欲望。当然这也可能是导致用户成长变得理智以后流失到其他sns的主要原因之一。
对于Lukoff提到的最后一点，其实他已经很接近真相了。腾讯，不管现在他有多少服务，他的根本依然是他的腾讯qq。所以引用本杰明的话，qq空间的用户数据很可能适合im账号捆绑在一起的。我觉得事实正是如此。我不止一次得认为，只要腾讯qq（即im）的核心用户发生了转移，或者这项服务不再时髦和“必须”，腾讯的黄金时代很有可能就此过去。
从Lukoff没有提及的角度出发。qq空间的易达性要差于人人和开心。因为qzone始终是qq的2级域名。而人人和开心却是实实在在的1级域名。从我个人的角度，我访问qzone的常规路径依然是qq->某好友->空间。一个糟糕的初期定位基本决定了qq空间的不成功。不知我的这个行为模式是否具有普遍性。
至于帖子最后提到的qq空间翻身的机会，我的观点和lukoff依然是相近的。qq依然握有当今中国互联网领域令人闻风丧胆的用户基量以及深不可测的资金量，任何一个正确的举措都有可能使腾讯迎来一个漂亮的翻身仗。
由圆通建包操作引起的思考
七/102
什么是建包：
建包操作一词源于快递行业，这个词汇在某些快递中的过程中经常出现。它的意思是在快递的途中，把需要邮寄到同一个地方的大大小小的邮件打包成一个大包，一同发往目的地。
本来这个操作并不存在什么问题，但是在圆通这里就遇到了一些问题。现在大多快递公司都可以进行物流跟踪，圆通也不例外。之前我在淘宝订货走圆通不在少数，也没有遇到过什么意外。但是这次当我过了一天查看物流情况，看到了物流跟踪结果如下：
2010-07-24 20:47:18 福建厦门 快件揽收扫描
2010-07-24 21:15:46 福建厦门 建包操作
从最后一个操作，也就是“建包操作”之后就没有进一步的动静了，整整1天时间。其实本来如果是上车扫描之类的记录的话我也不会感到非常奇怪，因为物流走1天也是常有的事情。但是建包我第一次见，就感到十分困惑，所以我就拿着我的疑惑去询问了谷歌。得到的结果除了上述的哪个定义以外，还有大量的对圆通的投诉，抱怨，都表达了一个意思，建包操作以后就死在那里了，几天没有反应。其实产生这个结果的一个原因在这里：
圆通建包操作：
建包操作完成，中间再出现的中转记录，看不到单号了，只能看到包号，也就是说快递单号要到拆包后，才会有记录显示的。
明白了。圆通建包以后，物流没有死，只是单号消失了，中间几次转运的上车下车扫描都获取不到了。所以如果一次转运需要1天，那么多转运几次导致的单号“假死”现象也就可以理解了。
分析到这个程度，文章还没有结束。让我们看看以下两种情况：
- 第一种：我订了货，物流正常要走3天，但是我无法直接查询物流的具体情况。
- 第二种：我订了货，物流正常要走3天，我可以直接查询到物流的情况。
前一种情况，只要货能在正常的3天内到达，作为用户的我并不会感到不安和疑惑。
但是作为后一种情况，用户的要求就会变得很高，他们中的一部分可能会乐衷于时不时得检查一下，看看物流是否正常，看看是否已到家门口。这一定程度上增加了用户的紧张心理。原本3天内正常的物流，可能因为1天没有跟踪的刷新而让用户怀疑是不是出现了丢了这类的问题。
所以上文提到的圆通建包正中了这个问题的下怀。在建包以后的处理上，圆通向用户隐藏了实际进行中的物流动向，这种隐藏导致了用户在正常物流时间范围内不必要的恐慌和抱怨。
其实在物流查询的问题上圆通做得没有他的同行申通做得好，我们来看两单记录：
圆通的：
2010-07-19 22:34:18 广东广州海珠区滨江 快件揽收扫描
2010-07-20 01:10:01 广州分拨中心 下车扫描
2010-07-20 01:11:39 广州分拨中心 上车扫描
2010-07-20 22:44:55 杭州分拨中心 上车扫描
2010-07-20 22:45:19 杭州分拨中心 下车扫描
2010-07-20 22:49:37 浙江杭州 上车扫描
2010-07-21 07:37:47 浙江杭州天目山路 下车扫描
2010-07-21 07:45:45 浙江杭州天目山路 业务员派送扫描
2010-07-21 16:17:59 浙江杭州天目山路 签收扫描,签收人:本人
申通的：
2009-12-08 20:44 福建晋江公司 的收件员 沈建国已收件
2009-12-08 21:33 由福建晋江公司 发往 福建泉州航空部
2009-12-08 22:59 快件已到达福建泉州航空部 扫描员是 称重扫描2 上一站是福建晋江公司
2009-12-08 23:07 由福建泉州航空部 发往 河南郑州航空部
可以看到申通比圆通的运单跟踪废话更多，而这种废话多的表现给了用户一种安全感。我一直以为在电子商务的过程中，安全性和可信度是成功的关键因素，所以在这个细节上申通做得的确要比圆通来得好。
就问题论问题，来讨论一下解决方案，为什么圆通在建包以后就不能把包的跟踪情况都更新到各个子运单的动向里面呢。从操作上讲，既然在建包时进行了扫描，那么包号和单号应该存在一个对应关系，那么这个更新操作完全是可以实现的。不知是因为跟踪系统在需求时没有考虑到这一点，还是圆通故意绕过了这点来隐藏建包后的操作。
如果这个跟踪真的无法完成，我觉得至少应该在圆通的页面里给出对建包的说明，指出建包到拆包中间的操作是无法跟踪的，并估计出一个大概需要的物流时间，这样在这个漫长的包转运过程中的单号假死现象对用户造成的影响就会减弱很多。等到用户担心了，郁闷了，到贴吧里面去询问了，为时已晚，企业的品牌信誉就这样慢慢得荡然无存。
WEB可用性学习<十>添加额外装饰
四/102
并非所有文档生来平等
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可用性学习（完）
WEB可用性学习<九>造就完美外观
四/100
一图胜千言
信号灯和毒苹果
首先我们需要了解一下色盲
- 红绿色盲（出了大家知道的难以区分红色和绿色这个特点外，他们还会感到颜色和亮度变暗，以至于无法区分红色和黑色。最普遍的色盲，男性居多）
- 黄蓝色盲
- 全色盲（完全无法分辨色相，但对相对亮度比较敏感，极其罕见）
我们主要考虑红绿色盲，因为其他两种人群都非常罕见。
色盲用户遇到的最大问题就是用颜色作为关键字的信息。如果某种颜色在色盲模拟中表现不佳，有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 一个字幕处理工具。
WEB可用性学习<八>高可用性界面
四/100
web属于用户，我们只是建造者
不要成为控制狂
- 让用户知道我们将要做什么
- 考虑是否“自动播放”，这个选择权应该交还给用户
- 增加控制按钮，而不是只有开始
对不起，时间到
消灭不必要的时间效果：
- 页面重定向
- 系统超时（确保程序关键路径尽可能简短、简单）
让<form>更正式
为它加个<label>
为它和表单元素增加说明
tips:
- 避免将<input>放在<label>中，这和使用<label>的初衷背道而驰
- 对于隐藏元素无需增加<label>说明，因为他们本来就不打算被访问
- 对于文件上传<input>，增加<label>是必须的
将鸡蛋和火腿放一个篮子里
当一组选择（单选或多选）其实是不同类型的时，可使用<fieldset>+<legend>的嵌套来代替<label>是更好的选择
当同样情况发生在<select>中时，使用<optground>(注意这个无法嵌套)
与键共舞
首先，accesskey和tabindex作为针对无法使用指向设备和依赖键盘导航的用户的解决方案是不提倡使用的。甚至被建议为完全不去使用。
访问的快捷键
- 用户需要为网站所使用的快捷键付出学习成本
- 快捷键可能覆盖系统和浏览器的快捷键设置
Tab键上的内容
tabindex打破了页面的自然阅读顺序，有时会带来一些奇怪的跳跃。
界面要简单易懂
为了将用户的注意力集中在当前任务上，我们要让界面简单易懂。
- 动作计数
- 比较两个界面
动作计数多不一定意味着界面不够简单易懂，有时为了形象可能会损失一些动作计数。关键在于减少无谓的复杂度。
WEB可用性学习<七>圆桌
四/100
表格的基础
我们需要为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对于普通用户和屏幕阅读器都是相当的负担。当很难讲表格按维度分割时，才使用这个属性。
附例子：
（请通过源码查看该示例）
| 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可用性学习<六>结构化生活
四/100
言之有物
创建语义内容的第一步，是正确使用标记语言。目标是使内容清晰明了。
阅读顺序
如标题标签不应该越级
使用故事板避免混合内容和表现
不要试图使最终设计与故事板丝毫不差。
用微格式增加更多信息
软件可以将信息提取出来，用不同格式展现。微格式是方法论，而不是技术
自定义格式
用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可用性学习<五>
三/100
设计时就考虑测试
测试应该在最初就被得到关注。可用性成本高的项目有两类：
- 大量需要文本替代物的媒体项目（不可削减）
- 开发末期加入可用性导致的两次创建内容的成本（可削减）
从上面的分类可以看出最初就考虑测试和可用性开发可以减少成本。
第一天就开始测试，即每做一步都测试可用性，然后渐进地添加新功能和样式。
动手去做
手工测试
- 检查替代文本的恰当性(alt、lable、声音的文字记录和字幕)
- 关闭图像，看内容是否有意义（或是否中断页面流向）
- 关闭样式表，看是否按自然阅读顺序构建web产品
- 检查其他分辨率，确保在低分辨率下可用
- play unplugged，放弃鼠标，看看依靠键盘是否可浏览（甚至考虑屏幕阅读器）
让残障用户参与过程
- 组成焦点小组
- 加入残障作为全程的测试人员
测试考虑的问题
- 哪些任务无法完成，为什么？
- 完成某任务是否耗时过长？
- 用户完成任务时，界面是否舒适？
WEB可用性学习<四>第三部分
三/100
多种访问途径
选择使用多种途径的目的是为了向用户以最佳的方式呈现信息，这取决于用户如何访问网站。
如果一段内容依赖于特定媒体的表现（如视频中的画外音），我们就至少要提供一种替代表现方式（我们添加字幕）。最终，我们希望用尽可能少的途径来覆盖尽可能多的用例。这并不意味着我们只是简单的在页面上罗列内容的几个不同版本。
在使用替代方案时要注意途径是否合理，确保没有使残障用户迷失方向的“黑洞”，以及允许其他完全用户进一步研究的能力。如果只是简单罗列替代版本，这可能导致
用户过载（overload）
这个说法基于感知负荷理论（cognitive load theory），即人用于某事的精神是有限的。除了信息本身带来的负载我们无能为力以外，我们需要减少因为信息的表现形式所导致的外来负荷，即使信息更容易理解。需要注意的是，非互补的信息会带来障碍。如为视频提供字幕，如果字幕与视频不同步，就会增加障碍。此外，如果互补信息跨越了多个页面(banum注：如某些注释链接需要开新的页面)，用户就需要在导航和界面上消耗精神资源。
牢记媒体的属性
每一个媒体的属性都是不相同的，所以我们需要考虑他，然后提供额外的信息作为该媒体类型缺失属性的补偿。对于交互元素，如果这个交互元素很重要，就需要设计替代的控制和响应来使不具有感应能力的也可以交互。
这里需要注意一点，设计一个大部分用户都一目了然的页面和为每个用户都设计一个页面是有巨大区别的。如果可能就要避免后面那种情况。
不要重复工作
如果项目中包含相互依赖的重复，事情变得糟糕，修改的工作量会按乘法增加。在某个系统中，一条知识必定有单一、明确、可靠的表现方式。
为了做到这一点，我们需要
进行抽象
我们需要许多真正有用的基本要素。 这个要素能够在多个地方使用，同时要避免上层的修改反过来影响这些要素。
避免一次性的决定
当系统需求中出现“一次性”的请求时要判断它是不是真的是一次性请求，如果真的是要把这个样式变化限制在一个特定页面上，以减少未来维护的开销；如果这个一次性请求（通常是如此多的一次性请求）其实是因为系统漏洞引起的，那么应该向开发者提出意见，在未解决前依然使用前面的方法来处理这个请求，即局部样式；如果这个一次性请求是内容开发者过于追求某个想法的最初观点而产生的特定语言，那么可能可以用已有的标记和样式来表达，重新审视它吧。
使用模板系统
并不是所有的模板系统都可以解决重复问题。请使用支持数据、接口和表现的最佳分离的模板系统吧。