可用性和可访问性 - UCD大社区

浅谈web标准、可用性、可访问性

风月 — 2011-02-14 18:33:44

前言：大家不难发现，只要是招聘UED相关的岗位，如前端开发工程师、交互设计师、用户研究员甚至视觉设计师，一般都对web标准、可用性和可访问性的理解有要求。那么到底什么是web标准、可用性、可访问性呢？

一、web标准

简单的说，就是HTML、CSS、JavaScript这三者分离。WEB标准不是某一个标准，而是一系列标准的集合。网页主要由三部分组成：结构（Structure）、表现（Presentation）和行为（Behavior）。对应的标准也分三方面：结构化标准语言主要包括XHTML和XML，表现标准语言主要包括CSS，行为标准主要包括对象模型（如 W3C DOM）、ECMAScript等。

web标准的优点：

代码的效率：在HTML文件中使用最精简的代码，而把样式和页面布局信息包含进CSS文件中。则放在服务器上的文件越小，下载文件需要的时间就越短。
易于维护：页面的样式和布局信息保存在单独的CSS文件中，如果你想改变站点的外观时，仅需要在单独的CSS文件中做出更改即可。整站统一css则可带来巨大的便利。
可访问性：上网用户中那些视力受损的人，通过屏幕阅读器使用键盘命令将网页的内容读给他们听。以语义化的HTML（结构和表现相分离的HTML）编写的网页文件，就可以让此类用户更容易导航，且网页文件中的重要信息也更有可能被这些用户找到。
设备兼容性：纯HTML，无附加样式信息，可以针对具有不同特点（如屏幕尺寸等）的设备而被重新格式化，只需要引用一套另外的样式表即可。同时，CSS本身也可以让你为不同的呈现方式和媒体类型（如在屏幕上阅读网页，打印网页，在移动设备上阅读网页等）规定不同的样式表。
网络爬虫/搜索引擎：搜索引擎使用“爬虫”，解析你的网页。语义化的HTML能更准确更快速的被解析，从而知道哪些才是重要的内容，那么你的网页在搜索结果中的排名就会大受影响。

二、可用性、可访问性

可访问性就是对所有人一视同仁，无论他们是否有残障。

网站的用户类型：

身体健康的用户；
盲人或严重视觉障碍者，他们使用屏幕阅读器来听取网站，或者通过点字显示器来感知网页；
近视者，需要将字体大小放大到200%；
患有运动性残疾，因此无法用手操作鼠标，而用点击棒来操作键盘，或通过视线点击器来操作网站的用户；
使用移动设备如常用的手机，或使用跟踪球等不常见的计算机控制设备的用户。

实现可用性、可访问性的方法

逐步强化你的网站功能，同时对支持性进行测试。运用“渐进增强”和“平稳退化”原则开发网站。
允许用户关闭有问题的增强功能。
提供相同内容或功能的替代版本。
就客户端需要支持的技术向你的客户提出建议，并举例说明哪些公司的产品支持这些技术。

可访问性良好网页的特征

HTML语义化、结构化：HTML语义结构提供了网页的整体框架，提示他们在文件层级中所处的位置，还有他们可以如何与各种页面元素进行交互，以及在适当的地方对文本内容进行强调，帮助用户获得大量重要信息。如导航菜单例子：
```
	Menu Item 1
	Menu Item 2
	Menu Item 3
```
说明：通过将导航菜单构造为列表，就能很容易地让那些使用屏幕阅读器、同时无法看到列表的人知道这是个列表。因为他们的屏幕阅读器会告诉他们这是一张列表。如果你没有使用列表标记，屏幕阅读器就没办法知道这是列表，因此也就不能告诉使用者了。
替代内容：文本可以作为页面内容的通用替代内容，如img标签的alt属性值、a标签的title属性值。
```
	
```
说明：文本内容可以很方便地由屏幕阅读器朗读出来，也可以放大或缩小，还可以方便地改变其对比度，或者进行其他许多变形操作。alt 属性包含了对该图片的简短描述，以便无法准确看到该图片的用户（或搜索引擎）使用，title属性负责对链接地址的详细文本描述。
HTML定义基本交互：实现tab选项卡搜索功能
```
	
		Search within:
		 
			Dogs
			Cats
			Fish
		
	
	
	
```
说明：先考虑基本交互（而不是仅仅只加载视觉效果的部分）的话，你就可以简化实现tab搜索效果。现在我们可以只用一个表单来进行所有的搜索，而同时仍然能实现tab选项卡效果（虽然这需要一点样式和脚本）。通过 AJAX 来插入页面内容，那禁用javascript的用户将无法使用。

四个可访问性标准（WCAG 2.0）：

可感知：人们可以通过适合自己的媒体来获知网页内容。比如应当让盲人得以收听页面内容。例如，图像应该有文本对应体。
可操作：人们可以与 web 应用程序或内容进行交互。例如，用户应该可以不用鼠标也能与某个网站进行交互，并且可以通过屏幕阅读器来进行导航。
可理解：使用者可以弄懂页面内容和用户界面。例如，正文不应该比它需要的更加复杂，且网站应以可预测的方式来运行。
健壮性：所提供的一切服务都应当不受平台或操作系统的限制。这样就可以避免人们提供一些不太完善的服务，这些服务会因为硬件/软件的限制而导致大多数人都无法使用。例如，不同设备上的浏览器能够一起使用网站，且导航应该是一致的。

说明：网站并不是必须满足全部这些要求，要视网站用户类型而定，但为了实现可访问性，网站应当确保其页面可以用一般的屏幕阅读技术读取。

总结：

可访问性是网站开发质量的一个衡量标准。如果你在开发网站的时候（以及开始开发前）顾及你的使用用户的话，你就能创建可用性、可访问性更好、更符合web标准的网页，并且享受它所带来的一切好处。

参考网页：
opera web标准课程
 百度百科 web标准

可访问性 - 前端的使命(二)

小麦 — 2009-06-27 20:02:33

继续这个读书笔记吧。

9. 定义键盘快捷键（Defining keyboard shortcuts）
意思就是定义accesskey属性。这个好说。有个关键是如何在浏览器里使用。IE里是“alt+”，并且只是将焦点移过去，要点击需要再按 enter；Firefox是“shift+alt+”，按下之后直接触发点击事件。Opera和Chrome还有Safari，我都没试出来，有知情者请告知。

感谢aoao提供：Safari 4/mac control+alt+key | /win alt+key
Opera Shift+Esc 选key
Chrome 3 alt+key

除了accesskey，其实还有一个更重要的：tabindex。有时候需要改变默认的tabindex顺序，以期得到更便利的体验。举个例子，如下格式的登陆框：

用户名
记住我
密码
忘记密码

按照默认的顺序，按下tab键，焦点会依次经过“用户名”、“记住我”、“密码”。但是似乎把“记住我”放在“密码”之后更方便，毕竟不是所有的人都需要使用“记住我”这个按钮，尤其是多次使用这个登陆框的人，他很显然是不喜欢“记住我”。所以应该用tabindex指定如下的顺序：“用户名”、“ 密码”、“记住我”。

10. 不要打开新窗口（Not opening new windows）
文中的意思是，这样会破坏浏览器的“history”记录，从而使浏览器“后退键”无效。总算知道外国网站很少有新开窗口的缘故了吧，也总算知道为啥 XHTML标准要把a标签的target属性取消的缘故了吧。但这个似乎不符合中国用户的习惯，还值得商讨。不过有一些变通的方式可以考虑：

a) 页面上给一个选框，选择之后就自动把a标签里的target属性移除，使得所有的链接都在本页打开。

b) 新开窗口并不是到”_blank”，而是到一个指定名字的窗口，比如“new”。这样所有新开的页面都会到同一个窗口里打开，至少在这个窗口里，还是可以使用浏览器的“后退键”的。（提一下，土豆网的视频都是这样的，开到同一个新窗口里）。

11.定义首字母缩略字（Defining acronyms）
先说明一下，其实作者这里对acronym这个词理解不正确。acronym是指单词的首字母合起来成为一个新的可读的单词，这个单词未必是所有字母都大写的，比如Nato（北大西洋公约组织）。所以HTML或是CSS算不上acronym，而
DOS、BASIC这种才算。像HTML或CSS这种，应该叫abbreviation，与其对应的是标签，但很遗憾，这个标签IE6上无效。

12. 给你的日历加上抬头（Giving your calendar a real caption）
13. 使用真正的表头（Using real table headers）
14. 为表格提供摘要（Providing a summary for tables）

把这三条合在一起说，就是要正确使用表格。其实表格的使用远比这三条更多，建议大家仔细阅读HTML权威指南。

最后说的是，我这只是一个读书笔记，光看这个是看不明白的，所以建议还是去通读一下原文吧。

相关话题：可用性和可访问性源地址：http://www.mikkolee.com/191

可访问性 - 前端的使命(三)

小麦 — 2009-06-27 21:27:05

其实这个系列还没写完，我看到已经被转载了。下次应该写个未完待续。

15. 忽略空白图片（Ignoring spacer images）
一定记得给图片加上alt属性，哪怕它为空。其原因是如果不写alt，有些阅读器会直接把它的文件名或URL读出来。

这让我想起小时候读过，说在发明数字0以前，人们都是用空位来表示的。这样就很不方便啊。所以alt=”"就相当于数字0这个伟大的发明。

16. 使用真实的列表（或者正确的把它们伪装起来）
这一条其实也是在讲如果要用图片作为列表前的icon，最好用CSS。但是没有提到为什么要用

相关话题：可用性和可访问性源地址：http://www.mikkolee.com/198

可访问性 - 前端的使命(一)

小麦 — 2009-06-23 01:58:42

事情的缘由是，前两个礼拜打了个“飞的”去北京玩，见了一位在百度做前端的朋友。过去一年以来，这家伙就不停的在鼓动我去他们那个邪恶的公司。当然，见面之后就不能再当面称呼人家是邪恶的公司啦，所以我就找了个理由，说你们那个“百度盲道”做得太垃圾了。他当然就很虚心的问我为什么啦。所以我也只能很心虚的糊弄了几句，说回上海之后详细告诉他。

回来之后，就马上很虚心的翻出一本老旧的电子书——《Dive Into Accessibility》，认认真真的看了一遍。

然后惊奇的发现：
1. 虽然我没看过这本书，但里面讲的大部分，我平日里都有遵守。果然，坚持好习惯是值得表扬的。
2. 网页的可访问性，似乎只能由前端来重视并实现。这点挺可悲，作为可用性的一部分——可访问性，居然只能由技术人员来掌控，这是我不愿意看到的。但反过来，这给前端开发工程师们新增加了一个责任，同时为如何区分优秀的前端增加了一个指标。

好吧，下面我把这本Dive Into Accessibility的内容作一个摘要，看看对于可访问性，应该要注意哪些问题：

1. 标明语言（Identifying your language）
这一条的意思是，加上lang属性，如。如果其中有一段是其他的语言，就在那一段的标签上加lang属性。这一条我做得不好，以后记得。

2. 构建有意义的页面标题（Constructing meaningful page titles）
有几点值得一提：
a) 做页面时，千万不要忘记写title。我见过好多页面的title是“Untitled Document”或“新建页面”，丢脸啊~
b) title到底应该是“小标题”在前呢，还是“大标题”在前？现在的惯例似乎都是“小标题”在前，比如“影音娱乐首页_新浪网”。但我个人倒是有个看法，或许大标题在前比较好。这样当我把“新浪网_影音娱乐首页”、“新浪网_新闻中心首页”放入收藏夹时，它们会因为音序排序而呆在一起，而不是散乱在各处。当然这个也不一定，仅供参考。
c) 对于英文的标题，一定要注意尽量不要把The放在title的前面，否则你的网页在收藏夹里就会被排在T开头了。

3. 提供额外的导航辅助（Providing additional navigation aids）
这一条是说要加这个。这个其实我知道。但是貌似对于页面里这么多链接，要都加上rel和rev属性，有点难度。

4. 先呈现主要内容（Presenting your main content first）
好啦，这就是一条典型的“指望优秀的CSS”的可访问性原则啦。把

放在

的前面，其实挺考验CSS技术的。一道著名的题目是：如何让侧栏固定宽度，主栏宽度自适应，同时主栏的HTML要在侧栏的前面。我很想放在我的面试题里，可又觉得是不是太刁难了。但是，无论如何，这道题目很重要！

5. 用于跳过导航栏的链接（Skipping over navigation links）
很重要！这个在骨灰级网页标准教程《网站重构》里就提到了。只是有一点我比较怀疑，如果把skip link设为display:none，难道不怕被阅读器也忽略掉么？

6. 安全的使用颜色（Using color safely）
这条其实讲了几个要点：
a) 颜色对比要够，否则眼神不好的人看起来费劲
b) 链接的颜色，最好用蓝色（像我比较喜欢用#09c）
c) 链接最好有下划线

7. 用“真链接”（Using real links）
意思是，即便这个链接是用于触发Ajax，也要把Ajax代码片段放在href里，好让搜索引擎以及阅读器等等能够爬到。关于此条，请参看土豆网首页的“挖土豆”一块。

8. 给链接加“title”属性（Adding titles to links）
这个还用说么，可用性两大重点：a的title和img的alt。

呼~~~先结束这第一回合吧。如果你对可用性感兴趣，可以详细的读一下这本“Dive Into Accessibility”，尤其是前5节。然后可以再去看看那个可恶的“百度盲道”，我接下来会专门用一篇来诅咒这个忽悠障碍人士的无良黑心产品。

相关话题：可用性和可访问性源地址：http://www.mikkolee.com/181

可用性设计是不够的（译文）

阮一峰 — 2009-01-30 15:50:39

春节期间，我就干了两件事。

第一件事，是参加了若干次的亲友聚会，食用了大量高热量高脂肪食品。第二件事，就是在痛苦地翻译More Joel on software。

痛苦来自于两方面。首先，我的翻译没有按照合同约定的日期完成，心理压力很大。其次，翻译的难度也不小，电脑前坐4个小时，只译出了2000字，怎么能不痛苦呢？

我觉得，罪魁祸首就是Joel喜欢用长句，30个单词以上的句子遍地都是。他喜欢把三四种意思，合在一句话里说。我猜想，他滔滔不绝的自我感觉一定很好，但是留给我简直就是心灵创伤，用中文还原他一口气绵延不绝的语气，真是太难了。（有兴趣的朋友，可以看一看副书名的翻译，体验一下。）我的良心建议是，以后你写书的时候，请一定多用短句。语言学家研究过，7个单词以下的句子，读者理解速度最快，单句最长一般不应超过12个单词。

下面的文章是原书中的第15篇。

===================

可用性设计是不够的

作者：Joel Spolsky

译者：阮一峰

原文网址：http://www.joelonsoftware.com/articles/NotJustUsability.html

发表日期 2004年9月6日，星期一

好多好多年以来，许多自封的（self-fashioned）权威——比如鄙人——一直在不断地唠叨软件的可用性（usability），鼓吹让软件变得易用是多么多么重要。Jakob Nielsen[1]有一个数学公式，如果你愿意出122美元，他就让你看一眼。你可以用这个公式，算出网站可用性的具体数值。（如果网站可用性的期望值大于122美元，那么我猜你赚到了。）

我在这方面写过一本书《程序员的用户界面设计指南》（User Interface Design for Programmers, Apress, 2001），价格要便宜许多。我在书中告诉了你一些原则，关于如何设计出具备可用性的软件。我没用到数学，不过你的收获肯定将超过书价。

在那本书的第31页，我举了一个例子，对象是当时地球上最流行的应用软件Napster。它的主窗口采用按钮，在5个不同的界面之间切换。界面设计有一个原则叫做“功能的可见性[2]”（affordance）, 根据这个原则，就不应该使用按钮，而真的应该使用选项页（tab）。我以前主张的观点就是这样。

但是即便如此，Napster依然是当时地球上最流行的应用软件。

在手稿的早期版本中，我实际上还写过这样的话：“这表明软件的可用性并不是决定性因素。”在一本宣传可用性的书中，出现这种话，其实是挺别扭的。所以，后来当书籍印刷时，排字工人跟我说，这一段太长必须压缩，我不由感到如释重负，就删除了这句话。

但是，必须承认，这件事反映出真理残酷的一面，至少对用户界面设计专家来说，这是残酷的。如果一个应用程序具备真的非常重要的功能，而且用户真的非常需要这个功能，那么即使这个程序难用得令人感到可悲，它仍然会大受欢迎。反过来说，有一个应用程序，被做成是世界上最容易使用的东西，但是如果它对任何人都毫无用处，那么它照样会完蛋。用户界面设计专家总是属于防守方，不得不与一些很不实际的投资回报率公式对抗。那些公式告诉客户，花75000美元进行可用性改造，到底能取得多大的回报。之所以会发生这种事，完全是因为在许多人心目中，可用性属于可有可无的“可选项”（optional）。在许多情况下，这种看法确实说出了事实。现实中，这样的事情比比皆是。一个用户界面设计师，就无法帮助CNN网站多赚到一分钱。它的界面再难用，也依然会有人去访问。我愿意担风险，在这里断言，世界上所有以内容为主的网站，没有一个会单单因为可用性的改善，而多赚到哪怕一美元的收入。因为，以内容为主的网站（请注意我的言下之意，那些不以内容为主的网站依然属于应用程序的范畴）不管再怎么样难用，都已经可以用了，真是太该死了。

不去管它了。

我今天真正要讲的东西，不是抱怨可用性如何不被重视……事实上，在其他条件相同的情况下，可用性设计就是决定性的。有许多例子证明，恶劣的可用性设计会导致小型飞机的空难，造成人员伤亡；还导致饥荒和瘟疫，以及别的灾难。但是，这不是我今天要讲的东西。

我今天真正要讲的东西，是关于软件设计的下一个层次的问题，也就是当你做好用户界面以后，你会遇到的问题——设计社会化界面（social interface）。

我想，这里需要我来解释一下。

上个世纪80年代，“可用性”这个概念被“发明”出来了。当时的软件全部都是人与机器之间的互动。目前，还有许多软件是这个样子的。但是，互联网的兴起，带给我们一种新的软件，它可以实现人与人之间的互动。

论坛，社会化网络，分类广告网站，……嗯，还有电子邮件。所有这些软件都属于人与人之间的中介，而不是人与机器之间的中介。

当你在编写充当人与人中介的软件时，做好可用性设计以后，下一步你就必须做好社会化界面的设计。而且，社会化界面比可用性设计更重要。如果社会化界面一塌糊涂，那么就算你有世界上最好的用户界面，你的软件也活不了。

最好的讲解社会化界面的方法，就是看一些成功的例子和失败的例子。

几个实例

首先，请看一个失败的社会化界面。每个星期，都有我从未听说过的人给我发电子邮件，邀请我加入他们所在的社会化网络。既然我不认识那个家伙，我就感到有点不悦，直接把邮件删除了。后来，我从别人那里知道了这是怎么回事。某个社会化网络软件公司，提供一种工具，能够自动获取你的电子邮件地址本，然后向其中的每一个人发送邀请加入的邮件。这个工具是第一步，第二步是有些电子邮件客户端软件每收到一封信，都会自动将发信人的地址保存下来，第三步是如果你正好订阅过“Joel谈软件”的邮件列表，你就收到过用我的邮件地址发给你的一封确认邮件，问你是不是真的想加入，这时你的Email软件就自动把我的地址记入你的地址本。这三者加在一起，一切就这样发生了。所有我根本不认识的人，一打开那个社会化网络的工具软件，它就会没头没脑地向我发出一封邮件，要我确认我是这些人的朋友。谢谢你订阅我的邮件列表，但是不要有幻想，我不会把比尔·盖茨介绍给你认识的。我当前的政策是，不加入任何社会化网络。因为，它们给我的感觉，就是与人类关系网的真实运作方式完全格格不入。

现在，再来看一个成功的社会化界面。许多人在面对面交流时，比较胆怯和拘谨，但是如果不见面用文字交流，就比较放得开。青少年尤其如此。手机上的短消息，使得他们更容易将对方约出来。所以，短消息软件在社会化方面做得如此成功，以至于极大地改善了几百万人的爱情生活（或者说，至少改善了他们的社交生活）。即使短消息的用户界面糟糕得可怕，但是它依然在孩子们中疯狂地流行。这件事的可笑之处在于，每一台手机上都有一个比短消息好得多的用户界面，专门供人与人之间的交流，这个精巧的界面叫做打电话。你拨一个号码，然后你说的每一个字，对方都能够听到，他说的每一个字，你也能听到。就是这么简单，可是在某些人群中，打电话就是不如操作麻烦的短消息流行。你不停地按键盘，简直把大拇指都按断了，只为了发出一句话“天啊，你真漂亮”。为什么你宁愿按断大拇指，都不愿直接打电话说？原因是这一长串的按键能让你得到一次约会，如果是直接打电话，你永远不会有勇气从喉咙里说出“天啊，你真漂亮”。

另一个社会化软件的成功例子是eBay。当我第一次听到eBay的时候，我说：“瞎搞！这绝对行不通。你在网上随便遇到一个人，就把钱送给他，寄希望于那个家伙良心未泯，会把商品寄给来。这不是太可笑了？”抱有类似看法的还有许多人。我们全都错了，完全错了，大错特错了。eBay对文化人类学意义上的人类，下了大赌注，并且赌赢了。eBay了不起的地方在于，它的巨大成功，完全是因为它的模式当时被看作根本不可行，没有其他人来做这件事，只有eBay做了，等到它依仗着网络效应（network effect），锁定领跑者的优势（first-mover advantage），其他人再想追赶就晚了。

除了本身的成功和失败，社会化软件还有一些副效应。社会化软件运作的方式，在很大程度上，决定了围绕它所形成的用户社区的类型。Usenet用户有一个叫做“大回复”（big-R）的命令，在回复时，可以引用别人的发言，并且在引用的每行左边最前面加上一个简洁的>。早期的Usenet客户端，也就是各种新闻阅读器（newsreader），不能列出同主题所有发言，所以如果你想针对某个人的发言做出有连贯性的回复，你就不得不用“大回复”命令，引用原始发言。这导致了一种Usenet风格的特殊讨论方式，也就是逐行驳斥（line-by-line nitpick）。这种事做起来感觉很爽，但是对他人来说，根本不值得阅读。（顺便说一句，后来在互联网上出现了一些政治类的网志，重新使用了这种技巧，那些作者认为这是他们发现的好玩的新做法，并取名为fisking，具体的原因我这里就不深究了。不过不用担心，这不是脏话。）你看，即使人类已经争论了几千年，但是只因为一个软件产品的小功能，就产生了一种全新风格的讨论方式。

软件的小变动，就能导致其所支持的（或不支持的）社会化功能的大变动。Danah Boyd对社会化网络软件写过一篇精彩的批评文章《自闭的社会化软件》（Autistic Social Software，www.danah.org/papers/Supernova2004.html），抨击当前的一些社会化网络软件强迫用户像自闭症患者那样行为。

请认真审视当前的潮流，人们对于将用户通过“朋友的朋友”关系互相连接起来的社会化网络，显示出浓厚的兴趣。这样的网络包括Friendster、Tribe、LinkedIn、Orkut等等。它们做了一些技术尝试，试图将人们构建和管理自己的人际关系网的方法模式化。它们假设你能够评判谁是你的朋友。在某几个软件中，它们用既定的程序指导人们结识不认识的人，它们不给你提供其他选择，只有唯一的途径，让你可以结识它们提供给你结识的人。

这种方法肯定有它的优点，因为这样一来，一切都能够通过计算得到。但是，一想到要是人们将这类模型同社交生活等同起来，我就感到恐怖。它们太过于简化了，人们被迫按照程序提供的模式进行交往，好像都得了自闭症一样，好像一定就得按照预先的设计进行互动一样。这种方法对于那些需要这类系统的人，肯定有帮助，但是它并非一个普遍适用的模型。而且，用技术来机械化地指导人际交往，到底会有怎样的后果？我们是否真的需要一种具有自闭症倾向的人际交往呢？

如果一个软件部署社会化界面时，不考虑文化人类学，那么这个软件就会难于使用，令用户恼火，不会真正地发挥作用。

设计社会化软件

让我给你示范一下，如何设计社会化界面。

假定你的用户正在做某些他们不应该做的事。

根据可用性设计的思想，这个时候，你应该告诉用户，哪些事是不对的，以及怎样纠正。专家为这种做法起了个专门的名称，叫做“防御性设计”（Defensive Design）。

如果你把这种做法照搬到社会化软件上，那就太天真了。

举例来说，用户的不当行为是在一个论坛中，贴出伟哥的广告。

你的做法是向这些用户显示警告信息：“对不起，本论坛不欢迎伟哥广告。你的帖子将被拒绝发表。”

猜猜看，那些用户会怎么反应？他们会换一种形式，照贴不误。（或者他们会发动一场冗长而乏味的抗议，跟你辩论审查制度和宪法第一修正案[3]。）

根据社会化界面的工程学（social interface engineering），这时你必须考虑社会学和人类学的因素。在社会中，存在各种各样的人，包括想占便宜的人、搞诈骗的人、以及其他为非作歹的人。反映到社会化软件中，就是总有人会为了自己的利益滥用软件，而不惜损害他人的利益。如果听任其发展，这就会导致经济学家所称的“公地的悲剧[4]”（the tragedy of the commons）。

用户界面的设计目标，是帮助用户能够成功操作。而社会化界面的设计目标，是帮助人与人之间的社会关系能够成功运作，即使这意味着必须要冒犯某个特定的用户。

所以，一个优秀的社会化界面设计师这时候会说：“让我们不要显示错误信息，假装系统接受了用户张贴的伟哥广告。这样使得张贴者感到达到了目的，就转到其他论坛去贴广告了。我们要做的，就是不让他的广告被任何其他人看到。”

说真的，避开攻击最好的方法之一，就是让它看上去好像获得了成功。这是装死战术在软件中的表现。

当然，这种方法不会100%有效。不过，95%的情况下，它是有效的。所以，它将你遇到的麻烦减少到二十分之一。就像社会学中的其他事情一样，这方面没有最优算法，只能做到大致上的改进（fuzzy heuristic）。在很多情况下，它是有效的，所以就值得尝试，即使不能保证肯定会成功。俄国黑手党精心策划的网络钓鱼计划（phishing scheme），最后会想出破解的方法。但是，住在流动房屋（trailer park）中的某些低智商的、盼望着快速致富的佛罗里达人，看到广告帖子张贴成功，就会心满意足地转到下一个论坛去了。今天我收到的垃圾邮件中，90%简陋到令人摇头叹息，就连Microsoft Outlook内置的那么低级蹩脚的垃圾邮件过滤器，都能把它们拦截住。你只需要随便凑几个很简单的搜索关键词，就能成功拦截这些不中用的垃圾邮件。

推广社会化界面

几个月前，我意识到，我们Fog Creek软件公司开发的所有软件，有一个共同的主题，那就是我们执着地、一心一意地要把软件的社会化界面做好。比如，FogBugz的设计中有许多特定的功能，和更多较小的细节上的安排，使得有效追踪软件中的bug实际上成为可能。不断地，有客户告诉我，他们以前的bug追踪系统，从来没有被真正使用过，因为它不适合团队开发的环境。但是，当他们改用FogBugz后，bug追踪系统就被真正投入了使用，而且很受欢迎，它改变团队开发中的一些做法。我知道FogBugz有效，是因为每当我们推出一个新版本，旧客户选择升级的百分比非常高，这表明FogBugz并不是“架上软件[5]”（shelfware）。甚至有一些客户，已经购买了许多张软件使用许可证，但是还是经常回到我们这里，购买更多的许可证，因为这个软件在他们的组织中使用得越来越广，越来越多的地方需要用到这个软件。这真得令我感到非常骄傲。团队内部使用的软件，通常很难推广，因为它要求团队中的每一个人都同时改变使用习惯。如果你学过人类学，你就知道这不太可能做到。由于这个原因，FogBugz在设计时就做了很多安排，即使团队中只有一个人使用这个软件，它依然是有用的。同时，FogBugz的设计中还有一些有利于推广的特性，能够鼓励其他用户使用，直到团队中每一个人都用上它为止。

在如何正确部署社会化界面这个问题上，我自己的网站上使用的论坛软件做得更完善，我很快就会把它并入FogBugz，作为一个功能上的卖点。我的论坛软件做了各种安排，包括特定的功能、各种细节、设计上的安排等等，加起来一共有几十项，它们加在一起，使得我的论坛成为一个可以进行非常高水平的趣味对话的场所，在我去过的论坛中，它具有最好的信噪比（signal-to-noise ratio）。在下一章中，我会详细来谈它。

这几个月来，我越来越认同，良好的社会化界面设计会为我们创造更多的价值，我变得更加专注于实现这个想法。我们聘请了好几个像Clay Shirky这样的专家（他是这个领域的先驱），在不幸的“Joel谈软件”的论坛用户身上进行了大胆的实验（许多变动都很细微，实际上不会被察觉，比如在你回复的时候，我们不向你显示你的留言所针对的原始帖子，目的是防止出现长篇累牍的引用，影响到整个页面的可读性），我们还不惜耗费大量资源，采用许多高级算法，减少论坛上的垃圾帖子。

一个新领域

社会化界面设计是一个全新的领域，还处于婴儿期。据我所知，这方面的书籍一本也没有出版过，只有少数几个人做过一些相关的研究，还没有系统的理论来指导如何设计社会化界面。回想起来，在可用性设计诞生的早期，软件公司招募人体工程学（ergonomics）专家和心理（human factor）专家，帮助设计具备可用性的产品。人体工程学专家对办公桌的正确高度所知甚多，但是这些人不知道如何正确设计文件系统的图形界面，所以一个全新的领域就这样诞生了。渐渐地，用户界面设计开始形成了自己的体系，确定了一些基本的概念，比如界面的协调性（consistency）、功能的可见性（affordability）、反馈性（feedback）等等。它们成为了用户界面设计学的基石。

展望下一个十年，我期待软件公司会雇佣受过人类学家（anthropologist）和人种学家（ethnographer）训练的人，请他们参与社会化界面的设计。他们采用的方法，不是兴建可用性实验室，而是走向室外，开展田野调查，写出人种调查报告（ethnography）。但愿我们会找到社会化界面设计的一些原则。那一定非常迷人……就像上个世纪80年代，用户界面设计刚刚兴起时那样有趣……所以，敬请期待（stay tuned）。

注释：

[1] Jakob Nielsen（1957-），丹麦人，著名的网站可用性咨询专家。

[2] Affordance指的是在设计时，必须明显体现出设计对象的使用方法。

[3] 美国《宪法》的第一修正案保证公民享有言论自由和出版自由。

[4] “公地的悲剧”是1968年美国生态学家Garrett Hardin（1915-2003）首先提出的。他指出，在公共草地可以无偿放牧，所以牧羊人一定会过度放牧，尽可能多地占用公地的资源，因为如果他不这样做，其他人也会这样做，最终就会导致公地的荒芜。在经济学上，这特指公共资源会因为过度使用而枯竭。过度砍伐的森林、过度捕捞的渔业资源及污染严重的河流和空气，都是“公地的悲剧”的典型例子。之所以叫悲剧，是因为每个当事人都知道资源将由于过度使用而枯竭，但每个人对阻止事态的继续恶化都感到无能为力。而且都抱着“及时捞一把”的心态加剧事态的恶化。

[5] “架上软件”指的是不被使用的软件，就好像一直放在货架上一样。

（完）

使用Alt提升可访问性

千鸟 — 2009-04-03 09:13:24

alt的准确含义是，当照片不存在或者load错误时的提示。但同时img也同时支持alt和title，再有某些浏览器的错误解析，因此经常被误导并误用。最简单、准确的理解，在看不到图片的情况下如何用文字传达给用户？

比如下图flickr的订阅图标通过alt告知用户Add to My Yahoo!，个人认为这里使用title进行操作指引更合适，alt属性应该进行描述。并且此时只有在IE6和IE7中才可见tip，其他任何智商稍微正常的浏览器都看不到，更糟糕的是IE8仍旧没有改善。

某些图片带链接，也就是img外层有a的情况下，并没有注意传达需求上的差异，把img标签的alt与a标签的title都应用同样的说明。但实际上它们本质不同，如下图flickr提供给用户的外链代码，可惜与上个例子有同样问题，在IE环境下看不到a标签的tip。

问题也不是没办法解决，如下图Wordpress2.7上传图片插入编辑器自动生成的代码，把img标签的alt和title都写了出来，可以保证在各种浏览器中的兼容性。

再来看看flickr.com顶部logo的代码，直接使用alt写入Flickr logo. If you click it, you’ll go home。如果按照刚才探讨的结论调整还有更优答案，参考下图第二个例子。也就是说，图片在有链接的情况下，alt传达内容是什么？title传达链接到哪里？

分别测试IE7, FF3, Chrome1, Safari4四个浏览器，可证明其良好通用性。依次如图：

结合title来更好的说明alt用法，可见如果结构、表现分离彻底，辅助修饰等图片根本不需要img插入，也就避免了很多alt的错误应用场合。Junchen在05年译的alt属性和title属性中有更多规范和细则，alt相较title而言用途单一，但给img插入使用alt替换文字时，也应该注意：

简洁
清晰
符合语境

使用Title提升可访问性

千鸟 — 2009-04-02 10:44:24

最早大家都没有给链接加title的习惯，后来因为w3c标准普及，又集体加上了title。从一个极端走到另个极端，于是出现很多怪异现象。两方面，第一a标签内title不是必须使用，第二title可以用在除了base, basefont, head, html, meta, param, script和title之外的所有标签。

抛开标签语义、搜索引擎友好等因素，在纯用户角度找几个场景来分析。

列表内容被截断后通过title显示完整，此时如果没有被截的链接，也会被再显示出来。试想本来已经看清楚的信息，触发又提示一遍，传达是不是感觉很婆妈。此时没有截的链接控制不输出title，效果或许合理很多。或者title在此时根本就不应该？印象中英文好站似乎很少做列表截取。

最典型类似对icon图示的辅助说明，可以最大化平衡界面复杂度与可操作性。并且针对某些群众认知度比较高的操作，如果图形传达到位，完全可以使用icon代替，更多交互场景请参考臭鱼在06年完成文字还是图标的总结。

在导航系统的各条目中，title主要作用是做补充说明。同时也对应可访问性原则中，要求导航传达清晰简洁的建议。用户感兴趣后操作触发，再title提示更多详细，强调信息引导而不是推送。

还有种做目的指引之用的案例，明确告知用户这个链接做什么？到哪里？在某些容易引起误会，或者不是很清晰的地方效果比较好。另外title不在a标签内也有广泛应用，典型如表单。可以为用户提供更精准、得体的操作指引，并且我想一定程度上可以代替明文提示。

学以致用，顺手给评论模板加了条语句。上次改的时候本想写出来，又感觉多余，现在好多了。准备动手评论的用户，自然会看到，并且这么土的语句也没有兼容性问题。

相应的不良应用不再图示举例，互联网上不胜枚举，深入分析语义和用法不仅能纠正错误、开拓思路，而且能贯通很多理论上的困惑。总结起来，title并不像seo从业者鼓吹的那么简单，在用户角度除避免与文字、图形重复传达，并且主要有三类用途：

描述非文本内容
补充说明文本内容
操作指引

导致网站可用性差的十个最常见问题

Experiencesolutions — 2009-03-23 14:57:50

作者：Experiencesolutions
译者：尚文欢
原文地址：http://www.experiencesolutions.co.uk/blog/2008/09/15/the-10-most-common-reasons-for-poor-usability-part-1/
注：括号【】内的文字为译者自己添加的内容

只有置身事外才能真正发现产品的可用性问题，很容易举出可用性差的例子，但是通常情况下人们并不知道那些造成产品好用或者难用甚至令人愤怒的真正原因。当然，这并不是偶然，大多数优秀的产品都曾进行过深入的用户体验设计以及可用性测试。

下面是我们总结的导致可用性差的最常见原因

1. 过分关注产品功能与技术

在项目的一开始，很多项目负责人和利益相关人员都希望能够利用最新的技术或开发大量的的功能，功能的开发与测试则受到高度重视，并且通常会有一个专门的项目小组负责，错就错在未能平衡这些功能与用户真正的需求之间的关系，相反，用户需求被扔到了大部分接口开发完成之后。

【没有数据表明但听过很多设计师抱怨，决策者往往将改善用户体验交给了视觉设计师或者是交互设计师进行最终界面的改善，这让设计师们无从下手】

2. 设计师和工程师的“门户之见”

脱离用户的情况下，设计师和工程师除了自我经验并没有更多想法，仅从自我能力、理解和看法出发进行系统设计。他们常常会深入的做项目却很少怀疑自己的决定，如果产品能够按照他们预想的方式运作那就足够了。

【这里可参考千鸟同学的文章：对设计和技术的误解，顺便提一下最近比较热闹的Doug Bowman辞职事件，在我理解中，G公司受到流量的影响，是一个数据决定设计的公司，而Apple则受到销量的影响，是设计决定数据的公司，人各有志，而G公司也不会因为Doug的离开有所改变】

3. 没人考虑过用户真正需要使用的界面

开发人员很容易陷入项目的细节，并沉浸在如何使产品正常运作的复杂性上。有时候，一个团队很容易做到集中精力于工作细节却不能退一步从用户的角度去质疑自己的设计，了解用户真正的需求，了解用户在什么情况下使用他们的产品，而这些很可能彻底改变设计的方向。

【工程师很容易为了一个细节问题和产品设计师较真，而如果这个设计师在没有实权的情况下，很容易和工程师妥协，不论设计师说话的手段有多高，方向性问题上或许能够说服设计师，针对某个细节，并且是设计师不熟悉的细节，产品很容易被工程师误导而失去本意】

4. 最终拍板的人缺乏界面设计经验

通常，我们会碰到一个能干并且善良的项目主管来为产品最终的界面与运作拍板，但大多数情况下并非如此，这个能够拍板的人往往很少有用户界面设计的经验，并经常不经意间做出那些并不考是否会虑影响用户体验的决定。

【两方面原因，设计师无法担起重任时，项目经理不得不事必躬亲，在双方不信任的情况下自然会出现各种矛盾】

5. 过分关注数据（定量测量）

当一个网站完工后，你会听到项目团队在讨论各种数据，独立访问的数据，注册量，PV数据等等。不幸的是，产品或者网站的可用性却没那么容易度量。与此同时，项目团队或许会意识到一堆被忘记的问题，或者是网站关键页面的低PV，他们却很少能够理解用户的操作方式，什么才是提高的可用性以解决问题的关键。

【数据只能代表过去，只是暂时的，而可用性则是一个长期的，见效慢的过程，做数据很快，而做口碑则需要积累】

6. 太多的决策者

当一个项目小组中出现太多的决策者或者是一个很大的团队没有清晰的项目领导或角色定义时，这个小组会收到太多相互冲突的关于产品应该如何设计的观点，通常情况，这个小组会讨论，视图将接口转化成他们自己“认为”的有利于项目的方式，一旦这种未经检查的产品开发方式变成了妥协、投机和自我意识，项目小组将会很少乃至不会再去理智的检查他们的想法，最终导致失去为用户设计产品以满足用户需求这一目标。

【产品设计师、项目经理、首席工程师，如果这三者都意见不一，如何让工人们做出一个意义明确的产品】

7. 定义不明确的项目目标

在每接触一个新客户的时候，我们总是惊讶的发现很少有项目有明确的目标。当项目没有确定的目标，这种产品或是服务所呈现的是一种偶然的上升趋势，随着时间的推移，项目团队失去了信心，而用户则流失于那些并不匹配的特性和功能。平衡清晰的商业目标与清晰的用户目标是提供给用户一贯的好的体验的重要方面。

【明确的目标也要适度，给予工程师与设计师一定的发挥空间，当然，前提是这个工程师和设计师愿意发挥，如果是那种不喜欢创造或者实力还达不到创新，最好是事无巨细交代清楚，否则不仅效率低下，做出来的结果也不好】

8. 没有为提升用户体验提供激励

极少团队会在产品开发过程中为提升用户体验提供激励，大部分时候，公司采取更为传统或者是以指标（客户满意度、预算、交通、产出等）的方式来奖励团队。显而易见的是，如果项目小组没有在提升可用性过程中得到奖励，他们将会将工作的重心放在那些可以让他们得到关注和奖励的方面。在项目的开始就以规范的基准建立可用性测试，这将在任何项目中为测量与激励可用性提升提供一个很好的方式。

【这的确是一个问题，很少有公司会为提升用户体验而给工程师奖励，工程师会认为这是设计师的工作而不会主动去思考，结果仍旧是双反扯皮，妥协】

9. 他们只是没有意识到可用性差而已

很多客户告诉我们，他们已经知道其产品或者服务的问题出在哪，但他们还是很惊讶我们的报告中出现的那些他们并没有关注过的可用性问题。除非你的确进行了规范的可用性测试，很难想像问题出在哪。顾客的意见，投诉和网站分析有时可以告诉你出现了问题，但很少能够让你深入了解问题在哪以及为什么会出现问题。这些问题只能通过观察用户如何使用产品与服务来发现，但很多团队从未这样做过。

【可用性测试的规范很多，去google搜索一下usability checklist就可以了】

10. 见树不见林

我们都曾经历过以为自己做出那种类似已经很好不能更好的决定的感觉，这在项目的全过程中都有可能发生，人们过于熟悉自己的产品或者服务之后，无法退一步去考虑全局，因为他们无法再从用户的角度去看整个项目，最终一手导致了差可用性的出现。引入中立的、长期的建议机制是从客观的角度去制定决策以及消除可用性问题至关重要的解决方式。

做一个好用的产品和服务是很难的，但消除差的可用性则可以从一开始建立目标就开始，贯彻整个项目周期。

【一叶障目，这不仅仅体现在小小的产品设计上，更能体现出一个人的资质，需要一个有远见的leader，更需要一群有远见的员工】

可用之前先保证可访问

千鸟 — 2009-03-16 13:06:52

最近重读WCAG1.0有很多感触，其中提到的很多约束看起来比较偏激，但能从侧面促进对其他概念的理解，并且提供理论支持。很多曾经困惑的问题都找到了合理解释，比如少用图片、合理文档结构、控制闪烁、结构一致性等。

通常网站好不好，第一印象的打分很重要，主要是可访问性在主导，与可用性关系并不大。关于Accessibility在互联网技术领域的定义，第一次怀疑是在某次做可用性分析时。我发现有些问题完全不需要“用”就能看出来，既然我还没用，那叫“可用性”问题似乎有点不恰当。如果在专业技术角度理解，只有发生交互行为的前提下，才可能考核可用性指标。

当然后来我也认识到并不是所有需要“动”才看出来的就叫可用性，比如target=_blank问题，多弹出新窗口会让用户迷惑。这里的迷惑主要指浏览上的感觉，而不是操作问题，与我们在交互上处理流程、表单等可用性障碍是两码事。

04年江湖上有本叫《在30天內打造更具親和力的網站》的热门书，当时就觉得“亲和力”这个词怪怪的，用代码写出亲和力？这事儿有难度。后来才搞清楚，Accessibility在各领域有无障碍、亲和力、可访问性、可到达性、可及性等多个版本翻译。并且了解到，Accessibility最初适用于环境建设，主要针对残障人士，后来被引入到信息技术领域，才诞生信息无障碍这个概念。准确的定义，信息无障碍是指确保在不同条件下的更多人能够无障碍获取信息。

也就是说，Accessibility在不同领域不仅有最佳翻译，并且还有更准确的技术方案定义。显然在互联网技术领域“可访问性”最准确，但不适合公共建设、软件工程。利用技术特性去解决问题和创新，我认为这才是各领域设计的价值点，同时这也是为什么工业设计高手、软件UI的可用性专家、架构师不一定能做好网站的根源。《The Zen of CSS Design》译者Dflying的意见：

关于accessibility，按照英语的构词法，“可访问性”没有任何问题。且“性”有“能力”的意思，因此“可访问性”即可被理解为“网页可被访问的能力”。而“无障碍性”则没有了“访问”的意思，如果要使用的话，也应该是“无访问障碍性”。综上，“可访问性”虽称不上完美，但仍差强人意。

写了这么多之所以和为什么，主要是我想真正搞清楚概念，最近老是提到“积累”这个词，我认为对概念的认知不是积累。但在去找差距之前，必须认识到这个圈到底有多大，否则永远是混沌不清、坐井观天，永远被下图这样的信息快餐忽悠着左转、左转、左转，再左转。

基本以上就是我这个阶段的思考过程，同时咨询了几位比较资深的朋友。需要强调的是，我本人无意去推概念，因为对概念的理解完全建立在实践基础之上。顺便说句，Jedi的blog常年黑底、浅灰字，这哥们太不敞亮了，很不Accessibility。

相关话题：可用性和可访问性源地址：http://blog.rexsong.com/?p=5842

给网站界面预留退路

千鸟 — 2009-03-11 15:16:16

常见到网上博文有错误理论，包括身边很多朋友都曾认同“可访问性(Accessibility)是为残障人士准备”的观点。其实在互联网技术领域远不是这么简单，总结起来有三个方面：

应付极端环境下的正常浏览需求；
结构、表现、行为跨平台兼容支撑。
保障残障人士无障碍信息获取；

web1.0网站以内容为主；web2.0网站以功能为主，有“纯内容、内容+功能、纯功能”三类互联网产品界面形态，格局基本已定型。虽然以内容为主的网站更突出Accessibility，以功能为主的网站更突出Usability，但不是说以功能为主的网站就不用考虑Accessibility。

技术发展至今，“纯功能”网站界面为提高Usability有大量富客户端应用，并且逐渐形成核心竞争力。也就是说在这种情况下同时保证良好Accessibility和Usability几乎不可能，因此只能采用保底的用户友好方案，告知为什么？怎么办？比如Gmail在disable javascript情况下会默认进入“基本HTML”模式；如果切换标准视图则提醒“必须启用JavaScript。”如下图

但在传统不以富客户端应用为核心竞争力的“内容+功能”网站界面上，同时保证良好Accessibility和Usability则完全可能，只是技术复杂度问题。比如yahoo首页这个著名web2.0门户和Ajax应用典范，在disable javascript情况下，虽然所有交互模式不能用，但功能不受影响，整体页面效果也保持良好。如下图

“纯内容”网站界面就是以信息为主的各资讯、新闻类网站内容页，大量存在于互联网，也大量被收录于各搜索引擎，这样的页面保证Accessibility更得把握住用户核心需求。比如163新闻的内容页，在disable css情况下，依然能够清晰辨认信息内容，一方面呈现优先级处理得当，另一方面标记语言的结构化良好。如下图

说到disable css, javascript，好多同行就会想到人为因素，并且以此定论应用场景不典型、不用考虑。其实懂得disable的高端用户也一定知道如何enable，真正可怕的是网速慢、I/O设备故障等非人为不可控因素，造成css, javascript无法下载或解析。

网上流传份5000万独立用户的网站数据分析显示，javascript disabled有1.19%，这个数据与我能看到的几个网站差不多。如果每天5000万的流量，大概就有60万这样的用户。

不管是客户端还是服务器端的网速问题，都会造成数据无法下载、浏览器无法渲染，严重影响用户的浏览体验。或许有人认为，曾经拨号时代此问题比较明显，现在资源普遍已比较宽裕。首先并不是全中国的网络都已小康，其次并不是小康的网络就健康，比如我们办公室经常就因为硬件防火墙、带宽限制等原因造成网络故障。

尤其在病毒泛滥、中毒杀毒的时候，浏览器经常会出现莫名其妙的问题，我曾经就碰到过因为浏览器一直脚本报错，导致服务无法使用，数据拿不到而影响工作。另外在国内使用代理服务器的愤青、伪愤青们也不少，是否有人考虑过为什么有些网站访问容易？有些困难？

回到五年前，在Gmail和Flickr刚在国内流行时，无疑都经历了访问效率低下的严峻考验。作为当时的用户和现在的从业者，我们不妨设身处地认真思考，为什么Gmail容错做的好？为什么Flickr会慢的很稳定？

极端情况并非只极端条件下才碰到，不可控因素无处不在。著名诗人泰戈尔曾说过，世界上最远的距离不是生和死，而是电信和网通间的距离，还有中国连接世界的距离。

对本文亦有贡献
浅谈产品设计中的可用性和可访问性
 可访问性浅析

相关话题：可用性和可访问性源地址：http://blog.rexsong.com/?p=5687

可访问性浅析

lifesinger — 2009-01-13 12:49:33

在Web前端开发界，有三个词经常被提及：可用性（Usability）、可访问性（Accessibility）和可维护性（Maintainability）。

可用性指的是：产品是否容易上手，用户能否完成任务，效率如何，以及这过程中用户的主观感受可好，是从用户的角度来看产品的质量。可用性好意味着产品质量高，是企业的核心竞争力。

可维护性一般包含两个层次，一是当系统出现问题时，快速定位并解决问题的成本，成本低则可维护性好。二是代码是否容易被人理解，是否容易修改和增强功能。可维护性和可复用性、可扩展性等有交叉的地方。构建可维护性好的代码，对企业的长期发展非常重要。

可用性和可维护性定义比较清晰，在软件界研究也非常多，在此不展开讨论。我们来看看可访问性。

什么是可访问性？很难给出严格的定义。在《Web Content Accessibility Guidelines 1.0（Web内容可访问性指南）》里，对可访问性的描述是：Web内容对于残障用户的可阅读和可理解性。同时指南里还特别指明：提高可访问性也能让普通用户更容易理解Web内容。具体而言，要考虑以下两方面：

无论用户是否残障，都得通过用户代理（User Agent）来访问Web内容。因此要提高可访问性，首先得考虑各种用户代理：桌面浏览器、语音浏览器、移动电话、车载个人电脑等等。在Google, 专门聘请了一些残障雇员，来帮助提高产品的可访问性。
还得考虑用户访问Web内容时的环境限制。比如：嘈杂的环境、过暗或过亮的房间、或者是免提等各种情况。这是更高一层次的可访问性要求，做到了，能造就产品在特定领域的核心竞争力。

理解以上两点，能解答不少疑惑。比如Web开发社区经常讨论的话题：我们真的要考虑浏览器禁用JavaScript/CSS的情形吗？我的理解是，要考虑的其实不是禁用了JavaScript/CSS的浏览器，而是那些对JavaScript/CSS不支持或支持不好的用户代理。比如语音阅读器，手机浏览器等，JavaScript提供的是一层可访问性，不能代替内容本身。当然，从渐进增强的角度讲，鼓励使用高级特性，只是同时要做到优雅降级，让低端用户代理上，也能保留低保真的体验。

理解可访问性，同时能有助于更好地理解语义的重要性。为何要看重em和strong的区别？因为在语音阅读器上，对这两个标签的理解是不一样的，错误使用会导致语调的错误变化和重音的位置不对。这对盲人用户来说，是极大的不尊重。

关注可访问性，是网络上的尊老爱幼，体现的是前端开发工程师对社会的道义感和关爱度。

相关话题：可用性和可访问性源地址：http://lifesinger.org/blog/?p=966

潜谈产品设计中的可用性和可访问性

oldfish — 2009-01-17 22:59:28

在用户体验这个行业，经常会听到，可用性，可访问性这样专业的名词，但是，事实上在很多产品实现过程里都忽略了这一点！WHY？

举个很简单的例子，用户的注册流程，很多交互设计师在做这块流程设计的时候都无可避免的忽略了部分可用性和可访问性，直白点说，产品的应用场景没有cover全用户群，损害了这部分用户的可用性和访问性。

太抽象？不明白？好，那我们就用户注册流程展开，侃侃流程中用户提交表单的设计。

看上图，这是现有支付宝注册流程中的一块功能，要实现的功能很简单，个人用户直接填写注册信息，是企业用户的话，就先选择企业，再填写注册信息，最后提交表单，完成操作。流程早就发布上线了，看上去很和谐，但是不然……

不然在哪里呢？应用场景，没错，您答对了。交互设计师在设计这个流程的时候忽略了一些场景，没有考虑到那些客户端对JavaScript不支持或支持不好的用户。做个实验，打开支付宝的注册页面，然后禁用脚本，你会发现，不论怎么搞，你都无法点出企业类的注册信息了！OK,现在明白了吧，企业类的用户在这种场景下基本上就game over了，搞不好还会再来上一句“FT，支付宝真TMD难用啊！”

听到这里，或许很多交互设计师坐不住了，“这不是前端开发工程师要去考虑的吗？”，我认为要这样来理解，如果单纯的从前端开发的角度而言，这种实现方式是无可厚非的。什么做法？对的，要说明一下……

实现方案1：采用css样式设置企业注册信息的容器默认为隐藏，当用户点选企业后通过js脚本改变容器的隐藏属性为显示。

实现方案2：通过脚本控制企业注册信息的容器的初始状态为隐藏，当用户点选企业后通过脚本改变容器的隐藏属性为显示。

一般情况下，前端会有两种实现方案，抛开可访问性，光从Developer这个层面上来选择的话，我选第一种。现在的注册流程中用的也是这个方案。

讨论一下这两个方案吧，各有优缺点，但是今天我们讨论的是可用性和可访问性，所以很显然第一种方案是不可取的。那为什么前端开发工程师还是选择了她呢？自然也有他的道理，如果采用第二种方案的话，势必要在页面结构加载完成后，再去初始化要隐藏的容器，当客户端网速不佳的情况下，会先显示企业注册信息的内容，几秒后又不见了，体验上有所折扣。但是就可用性和可访问性而言，是无懈可击的。假设，当前用户环境禁用了脚本，那么他访问这个页面的时候，企业注册信息不会被隐藏，会显示在当前页面上，易用性可能有一些缺失，但是功能上是可访问可用的，整个流程是健全的。相比两种情况，我想我会选择采用方案 2。当然如果你不屑可用可访问性，那就砖头砸我吧！

很多交互设计师都会想当然的认为，类似这样的应用场景受重群体是很小的，也许真实的数据会让你大吃一惊！总而言之，多为用户想想，是设计师最起码的职业道德！

可用性和可访问性的重要还能表现在很多应用上，如语音阅读器，手机浏览器等，这些在ppk谈javascript中有比较详细的描述，有兴趣的话，可以查阅《ppk谈javascript》。总而言之，语义化的页面结构在以后互联网产品的可用性和可访问性中起着非常重要的作用！

说到这里，我相信看懂的都应该明白可用性和可访问性是咋会事了，除了明白，你是不是也看到了一些问题呢？没错，绝对是有问题的，交互设计和前端开发过程中都存在的问题，专业化路线绝对不是单一的，专业化cover的度很重要！

相关话题：可用性和可访问性源地址：http://ued.alipay.com/?p=826