为了使网站变得可访问，到目前为止，我的政策一直是遵循WCAG，不要再多了。我认为WCAG是彻底而完整的。因此，我认为，如果我遵循其中的每一项建议，从可访问性的 Angular 来看，我的网站都是无可指摘的。与许多残障人士交谈之后，我想知道是否应该重新考虑这项政策。
这些真实用户告诉我，根据他们的经验，以下技术对于任何网站都是绝对必要的:
aria-live="polite"，也不要在没有用户干预(例如由于远程事件)的情况下让DOM更新。 并非每个用户都引用了这些技术中的每一种。这只是所有用户提出的建议集的并集。还有其他令人惊讶的建议。这些只是我记得的。
就所有这些建议而言，值得注意的是，据我所知，它们不是WCAG的建议。您如何看待这种不和谐？
一方面，我没有理由怀疑这些技术对于与我交谈的用户很重要。他们没有理由不诚实或夸大他们的需求。他们似乎对所使用的辅助技术有扎实的了解，因此我也不认为他们只是在沟通不畅。
另一方面，如果某些人需要这些技术，为什么不加入WCAG？ WCAG是否不完整？还是这些需求如此特殊，对于这些特定用户而言如此独特，以至于将它们包含在WCAG中并在每个站点上实现它们都是不明智的？
能否将WCAG作为正确而完整的Web访问 list ？如果是这样，您是否对如何将其与用户的评论保持一致有什么想法，当他们要求使用这种技术时，什么是适当的回应？
根据与Dryden Long的对话进行编辑
我需要澄清的是，我不期望WCAG绝对完整，也不希望为每个最后一个残疾用户提供解决方案。而是，我要确定的是，Web开发人员是否可以合理地依靠WCAG来创建一个尽可能实际访问的网站。而且，是否需要将目光投向WCAG才能实现这一目标。
最佳答案
1. WCAG 2.0的缺点
WCAG 2.0很棒。 它们是approx. 200 people多年来工作的结果，其中包括大多数Web访问方面的最佳专家，残疾人代表等。对它们进行了长期讨论，以达成共识，以反射(reflect)出互联网专家的观点。不同的利益相关者(例如，可以以有效的方式创建可访问的内容，而不会牺牲美观性，而不会给浏览器造成很大的负担等)。他们综合了多年的研究成果，并克服了旧版WCAG 1.0的许多局限性。他们还获得了W3C以外社区的意见，每年通过public comments mailing list收到数百(甚至数千)份公共(public)评论。
也就是说，WCAG 2.0 themselves recognize they are not perfect:
从我的 Angular 来看，也许有认知，语言和学习障碍的人无法游说并在相关论坛上不能代表。另外，目前的研究正在取得有关例如阅读障碍。
2.成功标准与技术
由于在WCAG 2.0中所做的工作，编写了几十个成功标准，它们建立了可测试的要求，可访问内容必须遵守(“可访问”在这里应理解为“符合WCAG 2.0” )。这些成功标准是核心normative content of WCAG 2.0，与技术发展无关，因此随时间推移是相当稳定的。
然后，有数百个 techniques to implement these sucess criteria。技术取决于技术。它们取决于特定的内容类型(例如，您使用不同的技术在HTML页面和PDF文档中提供替代文本)，还取决于浏览器和辅助技术的发展，以及(而不是)网络的发展设计本身。
这意味着几件事:
此外，每一项技术都包含一个页脚，说明
鉴于有(也许)其他方式可以达到成功标准，因此技术不是规范的，这是有道理的。想象一下，例如用户代理(浏览器和辅助技术)开始使用IPTC IIM (International Press Telecommunications Council Information Interchange Model)支持嵌入在图片文件中的图片描述。它们完全可以成为满足成功标准1.1.1的可接受方式，但不会(至少目前没有)反射(reflect)在任何技术中。
3.一致性与使用中的可访问性
与用户进行测试
拥有标准化的建议进行检查和诉诸是很棒的，因为它可以在一个地方提炼行业知识，并就被认为是“可访问的”内容达成共识(嘿，标准适用于什么)。但是， Involving Users in Evaluating Web Accessibility是确保普遍可访问性的关键。这是有道理的:正如其他答案所指出的那样，具有广泛能力的不同人可能有不同的需求，而这些需求只能在实践中得到体现。我要补充一点，不同的网站有不同的要求，而单个的多用途文档无法满足这些要求。就是说，例如，如果您正在创建社区足球队的网页，则通常不会与残疾人一起评估您的网站，但是，如果您正在开发社区网站，则可以(当然)这样做(当然)英超球队。
所有这些与用于可用性的常规Web开发实践并没有多大区别:即使您的客户提交了带有网站要求和规范的报价单文档，您也将进行一次采访，并进行一些采访。进行了可用性测试，进行了焦点小组讨论等。但是您都不会为您的邻里团队这样做。
实践中的障碍和技巧
残疾人习惯于处理无法访问的站点。技术人员越熟练，他们越会使用“技巧”来访问本来无法访问的内容:“是的，您需要先按Alt-空格键然后向下滚动，然后菜单会弹出”，“如果您激活JAWS中的隐藏选项并激活虚拟光标，它将读取该页面中的字段。”不太懂技术的用户可能不知道这种技巧，但他们会在最常使用的网站上内心地学习到一些技巧:“我需要两次输入'k'才能选择King's Station。
研究发现，残疾人对的评估结果始终超过一致性测试的评估结果。也就是说，用户通过诉诸这些“技巧”克服了一些可访问性障碍。但是，这不应转移一致性的重点。许多人不会知道这些技巧，即使是那些易用性较差的人，也将花费更多时间来完成其任务，并且更容易离开(或下次选择竞争对手的站点)。
另一方面，某些技术依赖于辅助技术的支持，其辅助功能的使用可能需要用户的专业知识。例如，technique C22 deals with using CSS to control visual presentation of text。这个想法很简单(添加了黑体字):
但是，用户如何通过用户代理修改文本的视觉特征？这是通常可以通过不同平台上的不同方式使用的设置。一些用户可能对此不太熟悉，并发现使用页面内按钮切换到大字体，高对比度文本会更方便。或者某些用户希望该选项在页面中随时可用。
4.支持您的用户需求的技术
上面对WCAG 2.0可能不足的所有以上解释。但是，当前的WCAG 2.0技术确实考虑了您提出的许多情况
所有按钮周围的高对比度CSS边框(背景对比度不足)是让我感到困惑的唯一事情，值得进一步研究。
带回家的消息
经过长期但需要的解释之后，我的简要建议是:
就像您进行其他任何可用性测试一样进行测试。也就是说，不要专注于报告是否不应该指定CSS背景颜色的用户，而是要检查他们是否可以轻松地执行被认为在您的网站上执行的任务，或者是否卡在某个位置上。就像您不问是否将特定颜色的心理测量特性视为吸引人的方法一样，而是在A/B测试中测试红色按钮是否达到更高的转换率。
能否将WCAG作为正确而完整的Web访问 list ？显然，这不是确保每个人都能平等地访问您的网站的 final方法，该定理是可证明的。这是人机交互的问题，因此，不能由有限的准则完全捕获。但是，它是可靠的资源，可以清楚地涵盖大多数实际使用场景，并且如果按预期使用它，则可以利用它的巨大优势。
关于html - WCAG vs真实用户的意见，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/21415785/