初出茅庐的设计师和开发人员应该知道的基本技能之一是艺术网站验证。
网站验证包括使用一系列工具，如W3C的工具标记验证服务这可以积极地找出并解释我们工作中的问题和不一致。
虽然使用这些工具有好处(从成为自动的新鲜眼睛的意义上说)，但使用这些工具的好处是过度依赖或不依赖的令人担忧的趋势不断抬头．
这篇文章旨在强调内在的通过自动web服务/工具验证网站的问题而如何使用这些工具来满足特定的需求则可能完全忽略了要点。
当前实践
在我们开始批评我们高尚的代码验证者所做的勇敢努力之前(至少他们的意图是好的)，重要的是要注意，对于生活中的所有事情，必须在验证的实际应用而且常识。
我们生活在一个思想开明的现代时代，网络标准已经成为一名白衣骑士，总是冲向杀死那些不能最好地代表我们工作的代码。
但是，尽管目前的实践积极要求并促进使用这些验证工具，但没有任何基于web的工具可以替代上面的代码可能无法验证，但如果没有更好的替代方案，可以使用它。
未使用有效代码
依赖性不足的情况可以通过检查Alexa前100个网站并使用一些基本的W3C验证测试。
这些受欢迎的网站所产生的令人瞠目结眼的错误数量(逐步升级到数百个)让一些人相当不安。
那些完全忽视验证的问题已经被充分记录下来，损害了终端用户的利益(正如遵循web标准的理由一样)因为完全忽视验证会让你和那些把它当作拐杖的人一样内疚，值得建议的是不要放弃这些工具，即使它们有缺点。
亚马逊的首页没有验证，但这并不意味着他们不在乎。
盲目遵循“规则”
过度依赖的情况也是我们需要担心的。那些形成毒品一样的成瘾，使一切都符合某种标准，只是为了满足一种天生的被认可的需求，这种人正在上升。
虽然确保代码的有效性通常是一件好事，但也有一些专业人士把它搞到这样的地步，他们求助于破解代码，忽视新的和不断发展的标准，或破坏他们的设计，只是为了得到“有效”的确认。
一个警徽可真贵。
甚至有人认为确认自动意味着一切都很完美，这更糟。
有很多工具，但您应该对所依赖的工具保持警惕。
上下文是王
关于验证工具，初学者(和一些经验丰富的专业人士)经常忽略的是背景下的价值。
验证工具遇到的最常见的问题可以总结为它们是只有机器,而不是人类。
你看，检查你写的代码是否正确，从表面上看，可能是一个简单的任务，网站是否满足残疾用户的需求，或者屏幕上的文本是否翻译正确——非常简单显而易见的真理(对于那些了解相关机制的人来说)是如何操作的复杂性人类适应无法有效复制。
这个设计对机器说了什么?
没有什么!它只看到代码，仅此而已。
你可以做机器人做不到的决定
如果你看过"《终结者》的电影，你的脑海中可能会浮现出这样的画面:在不久的将来，机器可以像人类一样思考，并据此做出决定适应性思维过程比如能够理智地、情绪化地知道什么是有意义的。
但不像这类工具能够理解上下文和含义的级别(超出物理上的内容)现在根本不存在——尽管这可能是一件好事，因为我们不希望W3C验证器对其进行疯狂的杀戮<眨眼>标签的用户,对吧?
也许有一天机器会和人类一样聪明，但那不是今天。
代码验证
目前使用的最著名的代码验证形式是W3C超文本标记语言而且CSS验证器。
一些设计人员和开发人员为了确保他们的代码是有效的，他们的服从程度最好地反映在许多网站向最终用户宣称(通过使用徽章)他们的代码是完美的(可能达到无菌的程度)。
声明代码的有效性并不意味着您所生成的代码是完美的。
这让我想起了软件开发者从下载网站获得奖励作为使用他们产品的理由。然而，正如我前面提到的，W3C验证器(尽管它有关联)是不完美。
因为未来的标准而失败
众所周知，W3C验证器不仅要检查站点的结构，还要检查元素或属性本身(尽管它们不理解语义值!)
这些工具的这种尽职调查的关键问题是，没有被识别的元素(如即将出台的标准，比如CSS3或同等有效的私有扩展)经常被开发人员误解为“不可用”或“未获批准”，因此被拒绝。
为了警徽把东西拿出来
我觉得很有趣的是，人们愿意忽略一些可接受但非标准的代码的值——例如，特定于特定浏览器的CSS3属性——来满足验证者，就像他们试图不激怒Tiki之神一样。
最后发生的事情是验证器自己使它看起来像违背惯例的合法做法自然是错误的这就导致了一种奇怪的心理状态，人们会为了一台机器(或它提供的意识形态)而过快地限制自己的行为。
虽然不使用已弃用的/未来标准代码是有意义的，但验证器只能根据它们所知道的进行测试。
没有什么比这些来自W3C的著名荣誉徽章更能说明“我需要批准”了。
需要明确的是，在页面上声明HTML和CSS验证的人这样做是为了让自己感觉更好。不幸的是，你的用户(除非你特别严格地迎合网页设计师和开发人员)甚至不可能知道HTML是什么，更不用说理解或信任那些奇特的验证器徽章告诉他们什么了!
网页可及性的验证
如果您想要一个验证者完全忽略了要点并且滥用了他们有限的测试能力的情况(宣布正在测试的工作已经完成)，您只需看看可访问性验证服务比如辛西娅，现在被揭穿的“鲍比”和他们的亲戚。
验证器的一个关键问题是，它们只能根据它们看到的内容进行测试(在几乎所有情况下，这只说明了源代码)。
虽然WCAG中的一些问题可以通过一些有用的编码来解决(比如alt图像上的属性)，代码不能解释所有的可访问性。
Cynthia说:“你的网站符合WCAG的指导方针，但是它经常缺少几点!”
测试易用性和可用性的唯一方法是通过人员
可访问性和可用性是非常主观的问题，会以许多不同的方式影响许多人，通常代码的呈现方式(甚至内容)并不能确定关键问题所在。
初学者经常积极地使用这些服务的检查清单性质，声称他们的工作是可访问的，基于验证器覆盖了它所能覆盖的内容(忽略了它无法解释的复杂性——例如感觉标准及其抑制因素)。这种关键的缺乏理解和希望快速解决的愿望表明，对这些工具的依赖并不理想。
有多少验证器可以告诉您阅读您的内容有多容易?它们中有多少在你的网站顶部运行屏幕阅读器，以指示盲人用户可能找到你的信息的方式?
虽然有些因素可以机械地复制，但问题是工具主要只关注代码，因此错过了更大的图景(依赖它们的人也会陷入这种意识的缺乏)。
在不了解这些网络或软件应用程序如何运作的背景知识的情况下，相当多的人只是把它们作为一种替代方法，而不是正确地学习自己在做什么。
<跨类" figure-caption>你会说拉丁语吗?没有?这些内容将通过可访问，可读和有效!
可访问性工具的状态是如此糟糕，我建议人们不要使用它们，而是要进行适当的人工检查。
的神话说工具可以在与人类技能水平相当的情况下完成任务，这远非事实，虽然W3C验证器可能很有帮助，但可访问性工具太过偏颇，难以得到信任。
翻译问题
与这种验证工具相关的混淆(如上所述)以多种形式出现。无论是W3C验证器产生的神秘消息(初学者可能无法理解)，还是缺乏关于这些工具应该“作为均衡饮食的一部分”使用的合理警告，或者这些工具所能提供的功能通常比您所认为的要有限得多。
自动化工具变得疯狂的一个比较滑稽的例子是Babel fish或谷歌提供的翻译工具，这再次证明了没有什么比人类更好。
谷歌Translate在提供“粗略”语言翻译的网站中很受欢迎。
人类语言的一个关键元素是，单词可以有不止一个意思(对于机器来说，决定使用哪个实例是很棘手的——这是一个上下文的例子)。
在可达性方面，视力问题可以是任何情况，从完全失明到色盲。
正因为如此，语言翻译人员会简单地寻找单词的字面意思，而不是使用它的上下文，这可能会使你的内容变成混乱的难以辨认的混乱，这对访问者没有帮助(特别是当他们有学习困难时)。
当然还有翻译工具不代码验证器，实际上是这样执行类似的服务。通过获取已知的标准列表(无论是代码、单词还是其他东西)，他们试图检查某些东西是否准确地描述了它的意图。
但是，如果您使用了它没有预料到的东西(比如翻译工具中的新单词或W3C验证器中的新属性)，它将代表您报告它的失败。
因此，这种依赖于验证工具来获得“完美”结果的做法是不合理的，而且可能会对您的受众造成损害。
一个翻译练习来测试这个想法
如果你从网站上截取一段内容，把它粘贴进去谷歌翻译,翻译成另一种语言，然后再翻译回英语，你就会发现这些内容转换的验证者在工作中有多糟糕。它可以给你几个小时的时间(如果你真的那很多的极客)喜剧在几个会议!
<跨类" figure-caption>看到这句话是怎么被翻译错的吗?它并不少见!
银子弹
知道验证工具远非完美是很重要的一课。许多人认为这些工具是无所不知的oracle，可以解释用户或浏览器可能遭受的所有问题。
虽然它的说这些工具没用是错误的，重要的是要明白，验证工具不应该被用作保证准确性，一致性或可访问性(为了访客的最佳利益)。
如果一个有效的网站牺牲了网络标准的进步，不公正地充当了荣誉的徽章，或者试图证明构建过程的结束是正当的，那么它就永远不应该实现。
了解如何和何时使用代码以及两者的区别在对与错之间是我们在接受教育时都经历过的一个艰难的过程。
关于验证器的真相是有时候生病是对的在很多情况下，一个“有效的”网站并不像你想的那样有效认为它涉及到代码语义、可访问性或用户体验。
我希望所有这些都能给那些忽视或滥用验证服务的程序员们敲响警钟。这些工具不是灵丹妙药或者是人类的替代品!
相关内容
- 2010年将继续塑造网络的五项技术
- Web表单提示和验证的最佳实践
- Web开发的未来是什么?
