在用户体验这个行业，经常会听到，可用性，可访问性这样专业的名词，但是，事实上在很多产品实现过程里都忽略了这一点！WHY？
举个很简单的例子，用户的注册流程，很多交互设计师在做这块流程设计的时候都无可避免的忽略了部分可用性和可访问性，直白点说，产品的应用场景没有cover全用户群，损害了这部分用户的可用性和访问性。
太抽象？不明白？好，那我们就用户注册流程展开，侃侃流程中用户提交表单的设计。
看上图，这是现有支付宝注册流程中的一块功能，要实现的功能很简单，个人用户直接填写注册信息，是企业用户的话，就先选择企业，再填写注册信息，最后提交表单，完成操作。流程早就发布上线了，看上去很和谐，但是不然……
不然在哪里呢？应用场景，没错，您答对了。交互设计师在设计这个流程的时候忽略了一些场景，没有考虑到那些客户端对JavaScript不支持或支持不好的用户。做个实验，打开支付宝的注册页面，然后禁用脚本，你会发现，不论怎么搞，你都无法点出企业类的注册信息了！OK,现在明白了吧，企业类的用户在这种场景下基本上就game over了，搞不好还会再来上一句“FT，支付宝真TMD难用啊！”
听到这里，或许很多交互设计师坐不住了，“这不是前端开发工程师要去考虑的吗？”，我认为要这样来理解，如果单纯的从前端开发的角度而言，这种实现方式是无可厚非的。什么做法？对的，要说明一下……
实现方案1：采用css样式设置企业注册信息的容器默认为隐藏，当用户点选企业后通过js脚本改变容器的隐藏属性为显示。
实现方案2：通过脚本控制企业注册信息的容器的初始状态为隐藏，当用户点选企业后通过脚本改变容器的隐藏属性为显示。
讨论一下这两个方案吧，各有优缺点，但是今天我们讨论的是可用性和可访问性，所以很显然第一种方案是不可取的。那为什么前端开发工程师还是选择了她呢？自然也有他的道理，如果采用第二种方案的话，势必要在页面结构加载完成后，再去初始化要隐藏的容器，当客户端网速不佳的情况下，会先显示企业注册信息的内容，几秒后又不见了，体验上有所折扣。但是就可用性和可访问性而言，是无懈可击的。假设，当前用户环境禁用了脚本，那么他访问这个页面的时候，企业注册信息不会被隐藏，会显示在当前页面上，易用性可能有一些缺失，但是功能上是可访问可用的，整个流程是健全的。相比两种情况，我想我会选择采用方案2。当然如果你不屑可用可访问性，那就砖头砸我吧！
很多交互设计师都会想当然的认为，类似这样的应用场景受重群体是很小的，也许真实的数据会让你大吃一惊！总而言之，多为用户想想，是设计师最起码的职业道德！
可用性和可访问性的重要还能表现在很多应用上，如语音阅读器，手机浏览器等，这些在ppk谈javascript中有比较详细的描述，有兴趣的话，可以查阅《ppk谈javascript》。总而言之，语义化的页面结构在以后互联网产品的可用性和可访问性中起着非常重要的作用！
说到这里，我相信看懂的都应该明白可用性和可访问性是咋会事了，除了明白，你是不是也看到了一些问题呢？没错，绝对是有问题的，交互设计和前端开发过程中都存在的问题，专业化路线绝对不是单一的，专业化cover的度很重要！
同发老鱼在线
其实我觉得把脚本直接紧跟着需要隐藏的元素后面效果会很好。
因为这种代码通常只有一行而已，传输量极小，即便在传输带宽很小的情况下也能很快加载完成，立即隐藏元素。
但这样的缺点也很显而易见：行为和结构混杂在一起，后期维护不方便。被同行看见似乎也会被耻笑。但无论如何，能够满足用户的可访问性以及用户体验。说的白一点，用户和开发人员，哪个更重要。
另一种解决方案是在页面头部最开始的地方写入脚本，这个脚本用于生成隐藏元素的css代码。那些需要隐藏的元素会在加载后由于刚生成的css而隐藏起来。而如果没有启用脚本自然就不会隐藏。
这个方案似乎比上一个更好一些。因为生成隐藏元素css的脚本会先于元素加载，所以不会造成突兀感。也兼顾了可访问性。但实现难度上比上一个略高一些。但显然，行为和样式也混杂在一起了（这是目前没法解决的问题……）。
以前好象从来没关注过这个问题,看来跟不上潮流了!恶补一下,哈哈
理念不错,但是在国内想要作到这样的话,估计没个5,6年是不行的……不过我支持楼主.挺你
提倡第一种解决方案。
如果不支持脚本，就转到另一个注册页面。
如果支持脚本，那一切都好，在脚本里屏蔽跳转。
就楼上的说法,那又牵引出另外一层,维护性的话题了,哈哈.
而且不要仅仅以developer的角度去看问题,你同样还是个designer
个人还是比较赞成一楼的说法,方案2有很大的提升空间…继续
感觉4楼的很”农民”啊,哈哈.以后互联网可用性和可访问性是 UI 必须关注的了
“潜”谈 还是“浅”谈 ，我想这里是潜水深谈。
^^，可用性除了访问者，应该还有维护者，客服等等角色
“很多交互设计师都会想当然的认为，类似这样的应用场景受重群体是很小的，也许真实的数据会让你大吃一惊！”
真实数据到底是多少？有人统计过吗？
回7楼: 不好意思,我又写错字了,已改
回8楼:我看到过一个数据,就如我例子中所举,互联网用户客户端不支持脚本或者对脚本支持不是很好的用户占所有用户的8%,当然这个百分比里有多少是和支付宝用户重合的,暂时没有办法统计出来
回楼上的:客户端脚本禁用的情况,这难道不是一种用户使用产品时的应用场景吗?这里说的不是用户有意识形态的去关闭脚本,而是确实存在不支持脚本的情况,可能理解的角度不同.看了你写的东西,有些费解!也许可以线下好好沟通一写.
其实对于这些看法,我也是站在先人的肩膀上去看问题,建议可以先去看看 ppk谈javascript
博主举的这个例子算是比较经典的,结合了前端和交互!
回一下10楼的,看了你写的文章,感觉你似乎理解错了,这跟软件工程,测试什么关系啊?这里说的又不是脚本引起的BUG,我相信测试情况下方案1也不会有可访问性的问题,只是不可预知的情况下,部分用户他的上网环境是不支持脚本的,这绝对是一类用户的应用场景啊!
不过博主这篇文章可能会让一些对前端支持不是很关注的人有所误解,哎,国人的悲哀啊!
这在说的不是脚本bug的测试,这是用户使用场景的一类分析啊…我哭!
还有,应该不是taobao UED吧! 看来支付宝UED的名号还是不够淘宝的响啊!
ppk谈js不错的,看过……是不是说的多了点,本来只是潜水看帖,不过10楼的观点确实让我有说话的冲动,哈哈
说实在的，我可以理解10楼所说的，现在国内大环境如此，技术和设计是被撇开的．看过很多老外的产品设计，觉得国内的思想还是很落后的，也可能是国人现阶段的能力就这个层次，google推崇的就是工程师文化，他们的开发工程师同时也是设计师，当然了，个人能力就相当重要了，国内应该能达到这种程度的人还是很稀疏的！所以我可以理解10楼的
我来解释一下语义话吧，就以老鱼提到的语音阅读器为例，语义化对盲人用户而言自然就非常重要了，em strong 对于他们对产品的理解意义是不一样的
总结时间：老鱼我很同情你，看样子国内交互设计，至少10年内是达不到你期望的水平的，可能永远也达不到，这其实也是跟国情有关系的，这叫具有中国特色的交互设计论！要接受现实，哈哈
12楼的好象有些偏激了!其实10楼说的也是有道理的,严格理论上来理解的话,没错,只是看问题的角度不一样,对于设计的理念也不同
设计,技术是否要区分的这么开,写这篇博文,最大的目的就在于此.我的中心思想其实是在最后一段，只是比较隐晦!
回,小新,多谢帮我解释语义化再产品设计中的作用,能不能理解,可能就表现在对技术的理解了吧,这或许从另一个面上说明了技术和设计是分不开的!至少不能完全分开!
真的没想到,随意的一些杂想,能激起浪花,罪过,罪过!
我盾悟了……每个人心里都有把尺,强求不得!没有对错之分的!
最后想对10楼的说一句,不要轻易的下判断说对或者错,我们都只是在摸索中成长!
13楼的发言很淫荡，所以不去批评了。
12楼的跟博主是一个意思，就是说js禁用是一种场景，而方案1因为不会产生任何问题所以没有场景。那也就是单纯的把用户无法正常完成任务的情况都看作场景了。这就是我说的：它们不是“一种”场景。它们只是一种“意外场景”的一个实例。不能以点带面。
楼上现在说的,让我想起高中时刚开始学”诡辩”的场景,哈哈,没别的意思,只是觉得挺亲切的!以前我也很喜欢以这种思维去和别人讨论问题,现在……,有兴趣的话,可以交个朋友,线下好好交流一下,旺旺:伯约. qq:36463746…
老板对不起,工作时间聊了那么久blog,哈哈,汗一个!好久没有讨论问题这么有激情了!不论怎么样,谢谢各位
原本我比较排斥设计和技术混搭在一起的模式，但是这篇文章倒是对我有所启发，某些情形下面设计师确实需要了解技术实现，反思中…
被老鱼抓来顶帖，发表几点看法：
1）就目前国内的情况来看，很多用户体验的问题都是常识问题，既然是常识，也就不需要高深的“交互”知识（如果真的存在那么高深的交互知识的话）；
2）设计师需要技术来武装自己的头脑。digg/facebook的设计师都要求xhtml/js/css和php/mysql知识的，facebook还特别强调unix背景；
3）其实比较起来，我觉得老鱼提的这个设计还是不错的，至少没有滥用js。最讨厌明明能用html解决的，非得用js，比如我曾提到的：
http://dingyu.me/blog/posts/view/when-no-javascript
4）其实就这个例子本身而言，老鱼倒不必太担心－有多少ie用户禁掉js？又有多少用户用ff访问支付宝？访问中文网站禁掉js简直就是自虐。退一步讲，可访问性更多考虑的是如残疾人这种无法正常访问网络的，但这种比例真的是小之又小，更不要说他们用的浏览器根本无法登录支付宝。
期待老鱼同学下篇大作！
果然还是丁宇同学最能理解我,觉得我们的交互理念还是比较合拍的,哈哈…下篇大作《全方位面向对象思维》,敬请期待
丁宇同学最后一句话说出了我的想法：禁用JS，你连支付宝都登录不了（密码输入框是用document.write出来的）~
所以我的想法是啥时候禁用JS，也能登录支付宝，用上所有功能，那就牛了。但是感觉或许有点画蛇添足了，大的趋势应该是用JS的网站、浏览器、用户会越来越多。
回20楼:JS不应该是增加功能，而是增强功能.
也就是说我们至少要保证,在JS被禁用的情况下,基础功能是不会受损的!js只是锦上添花的!也就是说,不支持脚本就进不了支付宝是多么的无耻啊,我们需要改进啊!
两边的文章我都看了,支持老鱼!
虽然个人觉得要做到这样挺难的,但是至少多了解一些技术实现对于整个设计的总体把握会好些
一个解决方案 http://blog.fouland.com/2009/01/noscript-for-css/
非常感谢这么多同学发表了看法,我最后总结一下,结帖吧:
[1]对于技术人员,本文提的其实没有太大的技术含量
[2]对于交互设计师,本文提到的可用性似乎又与技术挂了钩
之所以这么写,是为了想说明,技术和设计是不能完全分割的,这才是我的中心思想!希望前端开发工程师在做开发的时候多考虑一些产品体验上的东西,同时也希望交互设计师在做交互设计前多了解技术形态,这样对你最终的产出物是绝对起加法效果的!
之所以大公司会有一个UED团队，正是因为好的用户体验方案不是靠一门技术就可以研究出来的，每个步骤的人都需要思考、分享、交流，最后才是一个完善的方案。即使是再优秀的团队，推出来的方案也可能存在异议，总是没有最好，只有更好，这才是行业渐进之路。
感谢各位大师的分享和讨论^^
如果可以的话 在支付宝里加入用户参与改善体验的计划。那样我应该会是一个忠实的fans。看着支付宝的不断进步，我更加希望能以一个用户的角度给贵团队提出个人对业务的需求，供你们参考。
改进完善支付宝，更好的为用户服务。不光要靠设计师们，还要更多的依靠客户。
：） 祝福支付宝牛年更上一层楼！为老百姓带来更简单易用的网上购物体验！
这年头微软雅黑和wordpress很流行.整个集团都是用WP的.
我仔细看了2遍。明白了。的确很多站都是这么做变化的。是有这个问题。 一般技术不会想那么多。第一种会多点。
保证可用性的前提下追求易用性.
至于语义化,看看页面中泛滥的,…
最近想到，直接用noscript标签不就得了么。不过还是有一些值得探讨的地方的。
http://shawphy.com/2009/04/noscript-for-css.html
阿里巴巴的讨论氛围很好。。。。
上twitter经常体验到方案2的好处，没样式，没js的情况下直接可以填写登录信息进行登录。