HTML5 需要发言人来推动其发展。有很多人在承担着这个角色，而我们在 Mozilla 认为，通过一系列访谈和短视频将其中的一些人介绍给你们是一个好主意。格式很简单——我们向专家发送 10 个问题让他们回答，然后进行一个简短的视频访谈，让他们自我介绍并详细说明他们的一些答案。

今天，我们重点介绍的是 John Foliot，他是 HTML5 媒体元素可访问性小组委员会 的联合主席，也是广为人知的网络无障碍领域的斗士。

John 参与网络、邮件列表和 W3C 会议的时间之久，他自己都不愿回忆，并且在使网络对所有人都有可访问性并同时使用新技术方面始终是理性的声音。由于这是一个在 HTML5 上下文中不常讨论的话题，我们认为有必要提出它。

视频访谈

您可以在 此处在任何支持 HTML5 的设备上观看视频（由 vid.ly 提供）。

关于 HTML5 的十个问题，致 John Foliot

1) 关于什么是 HTML5，存在相当多的困惑。甚至 W3C 也在发布 HTML5 标识并将其描述为涵盖其他技术的现代开发品牌时犯了一个“乌龙球”。您对 HTML5 的定义是什么？

就我个人而言，HTML5 是 HTML——超文本标记语言——的下一个主要迭代，它将在适当的时候由 W3C 标准化。它将有效地取代 HTML4.01/XHTML1.1，自 1999 年 12 月以来一直没有更新。它是支持当今开放 Web 技术的核心标准之一。

我理解并接受，就市场营销和大规模传播而言，需要一个能够描述当前更大生态结构的抽象术语。关于命名的讨论已经持续了一段时间，我怀疑大多数远程感兴趣的开发者已经知道我们正在使用的开放 Web 技术堆栈需要一个名称（我的朋友 Bruce Lawson 将其称为 NEWT）。

但是，这匹马已经跑出了马厩，HTML5 就是这个名字。因此，在当今与开发者进行一般性交流时，我相信我们都理解 HTML5 的含义。HTML5 也成为了主流认为我们正在做的事情的方式，所以我真的不怎么担心营销名称。随着时间的推移，一个新的流行词将会出现，世界将会继续前进，HTML5 将意味着超文本标记语言的标准——第五个迭代。

2) 关于 HTML5，似乎有两个相互冲突的“真相来源”。WHATWG 和 W3C。您何时会认为哪个组织更重要？它们之间是什么关系？

它们之间的关系？复杂。

这种关系承认两个不同的群体可以拥有共同的目标，并且合作可以带来进步。但这是一项艰苦的工作。

WHAT WG 在许多开放 Web 技术的出现和发展中发挥着有益的——可能是至关重要的——作用。在许多（但不是全部）浏览器供应商的支持下，共同分享技术理念，包括多个团队的实验和评估，从而导致技术改进。这是工程师们的地方，他们习惯于在敏捷的环境中工作，这对于工程师来说非常有效。这是一个激动人心的场所，新的想法在这里出现并首先进行粗略的规范，然后进行完善，在开发浏览器中获得更大的支持，然后达到发布的浏览器版本。

然而，即使在初步工作中，这些规范也可能尚未完成，即使正在实施；通常，不同浏览器之间的实现方式各不相同，并且缺点（遗憾的是，通常与可访问性有关）往往很大。

WHAT WG 正在制定的规范在不断发展——这是好事——但这使得浏览器供应商之外的大型实体难以跟上。大型项目需要比“活文档”所能提供的更高的稳定性，因为根据其本质，该规范处于不断变化的状态。请注意 开发者博客上的这条最新评论

“最糟糕的是，您不能简单地搜索博客/论坛或查看文档来找出如何解决问题，因为“没有人”知道如何做这些事情，信息随着新 OS 版本的发布而很快过时，文档非常糟糕，而且没有涵盖边缘情况，规范在不断变化，并且不同版本的 iOS 采用了一套不同的规则……”——而这仅仅是为了让 <video> 在 iPad 上正常工作。

此外，由于组织和政治原因，并非所有既得利益者都参与了 WHAT WG 过程，这可能存在问题，但并非不可克服。

微软不是 WHAT WG 的一部分，而且可能永远也不会成为一部分。我们可以抱怨 IE 带给我们的问题，但由于它目前拥有大部分市场份额，我们根本无法忽视它。因此，WHAT WG 在某种程度上受到这种情况的限制。

我以坚定支持 W3C 而闻名，因为我坚信他们在全球范围内最能代表 Web 技术。W3C 不仅仅是浏览器中的网站；他们的标准涵盖了广泛的相关技术，所有这些技术都利用了更大的网络，并且只要有可能，W3C 就会努力确保它们能够协同工作。这是一个全球性组织，得到国家政府、学术机构和依赖全球互联网网络的技术公司的财政支持和支持。然而，我承认，像任何大型实体一样，它有时难以快速行动——官僚主义是任何全球性组织中不可避免的弊端。

对于一个参与到这项新技术日常竞争中的年轻人来说，这种速度是可以理解的令人沮丧，但像 IBM、微软等大型公司中的工程师已经习惯了这一点。没有人必须喜欢它，但它确实存在。

WHAT WG 探讨想法并解决问题，W3C 稳定、审查并“发布”每个人都可以参考的基准。这两个角色都很重要，但每个角色都是独一无二的。

至于“真相”，我将其留给其他人来决定。

3) 您是一位无障碍的坚定倡导者。您是否认为新的开放技术有利于可访问性，或者我们是否忘记了
它？

我认为 HTML5 开始提供的许多内容将有利于所有用户，包括使用辅助技术的用户。然而，许多承诺的功能尚未在所有浏览器中得到支持，并且相关的技术——辅助技术——在利用这一优势方面还有很长的路要走。

例如，大多数浏览器渲染引擎不执行地标元素的本机处理（我相信 Firefox 4 使用 HTML5 渲染引擎），并且对其他 影响可访问性的新规范部分的支持仍然不足。更有理由让 HTML5 标准化；当然，在 W3C 中达到候选推荐。

我认为 WHAT WG 正在处理的一些新兴内容偶尔会在可访问性方面存在不足；值得庆幸的是，现在比一些早期的 HTML5 工作开展时要少得多。

总的来说，我通常很高兴看到对可访问性的认识程度有所提高，以及工程师和可访问性专家之间通常富有成效的对话。

4) 许多 HTML5 的展示案例都展示了某种效果，但在基本的可访问性方面却落后了。没有键盘交互，也没有针对支持进行测试。您会发现指向无处的空链接，以及存储在文档中以备后用（例如，在需要时显示和隐藏的整个错误消息列表）的 HTML。对此可以做些什么？您对开发人员的建议是什么，为什么键盘访问甚至非 JavaScript 回退很重要？

我认为问题的一部分，也许是最大的一部分，是缺乏教育。创建和发布到网络的门槛非常低：任何傻瓜都可以做到，所以即使是傻瓜也会去做——而不了解或理解他们真正做的事情。它也受到一些网站和博客的损害，这些网站和博客将其中一些糟糕的技术推荐为“这样做的方法”，从而进一步助长了不良的编码实践。

我认为另一个问题，尤其是在可访问性问题方面，是许多开发人员（拥有任何类型的工程背景）已经变得非常舒适，甚至依赖于敏捷开发流程：编写代码、测试、破坏、修复、测试、破坏、修复……我无法数清我听到过多少次“这只是我们的第一个迭代，我们将在未来的版本中处理可访问性内容”。这里的问题是，可访问性被降级为“功能请求”而不是“核心需求”。这里同样是一个更大的教育问题：主流开发者需要理解并承诺将可访问性作为核心需求，这将有助于塑造他们在项目发展过程中做出的功能和技术决策。

键盘访问是许多用户的必要要求，而且越来越多的不仅仅是残疾用户。为移动设备创建的网络内容的巨大增长正在帮助开发者更多地意识到这一事实。我挑战每一位阅读本文并创建网络内容的人，让他们有一天卸下无线鼠标的电池，然后测试他们的网站。这可能是任何开发人员可以执行的最简单的“可访问性测试”之一，因为它不需要任何特殊的工具（硬件或软件）来进行测试，但对视力障碍用户和各种行动不便的用户都有巨大影响。

关于 JavaScript，W3C Web 内容可访问性指南 2 (WCAG 2) 对 JavaScript 的要求比 WCAG 1 更宽松。当今几乎所有浏览器都支持 JavaScript，并且客户端脚本是当今现代 Web 基础设施的必要组成部分：请记住，大多数自适应技术都与这些 Web 浏览器交互，因此依赖 JavaScript 执行“关键任务”功能的陷阱和问题对于所有用户来说都是一样的。同样，解决此问题的真正答案是教育。

5) 让我们谈谈辅助技术。由于标记和脚本不应该仅针对某些浏览器，我们需要知道例如屏幕阅读器现在可以做什么。对新技术的支持如何？

首先，我将辅助技术定义为一系列现成的软件工具、专门的程序和硬件的替代组合；所有这些都是辅助技术：Dragon 不仅在您说话时打字，还为行动不便的用户提供了一种免手动操作的 UI 交互解决方案；屏幕阅读器是程序，它们在浏览器和其他 UI 工具以及操作系统之间进行通信，利用操作系统的可访问性 API；连接到各种设备的盲文输出条为需要它的人提供了专门的输出。操作系统级别的功能（如 VoiceOver）一直是视力障碍用户的福音（允许他们与 iPhone 和 iPad 交互），也可以被视为辅助技术。

屏幕阅读器是复杂的软件，虽然一些屏幕阅读器（如 NVDA）正在积极努力跟上 HTML5 的改进，但大多数（我相信）都在等待更正式的标准稳定下来，然后再投入资源重构其软件。这是否是正确的决定并不是真正的问题——这不是一个问题，而是一个明显的事实。

这是一个困难的“先有鸡还是先有蛋”的场景，这也是我一直建议在使用许多新的“HTML5”技术时谨慎进行生产级开发的原因之一。这个故事中的一线曙光在于，ARIA 在当前的屏幕阅读器中得到了很好的支持，因此开发人员今天可以安全地依赖 ARIA 的大部分功能，并结合许多 HTML5 的优点。许多当前的 UI JavaScript 库（如 YUI3 和 jQuery UI）也正在这里提供帮助，因此工作的开发人员应该考虑使用当前和新技术解决方案的稳健组合。

6) 使文档易于辅助技术理解的一件非常重要的事情是保持逻辑顺序，尤其是在标题方面。使用 HTML5，我们有部分文档而不是完整文档中的部分、文章、hgroup 和标题顺序。甚至还有文档的隐式轮廓。辅助技术如何处理这种情况？我们是否通过做正确的事情来阻碍用户？

这实际上是一个非常热门的话题，因为最近（2011 年 1 月），许多人开始 质疑 HTML5 中 hgroup 元素的可行性和实用性。W3C 流程就是这样，关于此问题的任何真正的对话和讨论都被推迟到今年晚些时候，因为工作组正在努力解决在 2010 年 9 月底截止日期之前提出的旧错误和问题。我相信目前没有浏览器支持 hgroup

标题的轮廓算法是一个很棒的想法，但目前在自适应技术中还没有实现或得到支持。这个想法是浏览器能够根据其周围的“继承”关系，启发式地判断``元素应该处于哪个合适的级别（例如`

`）。

这使得组合文档的大纲和结构更容易阅读和理解，从 DOM 到用户界面，无论是浏览器的图形用户界面还是自适应技术。实际上，浏览器会“重写”标题级别。对类似操作的需求已经存在并被理解了一段时间了：XHTML2 曾提出一个无编号的``元素，有助于实现相同目标，但由于某些原因（可能是简单地反对 XHTML2“错误”），这个想法并没有被 HTML5 工作组采纳。尽管目前不支持此功能，但使用标题来“分块”内容仍然是用户（尤其是屏幕阅读器用户）的重要需求——即使 DOM 中的实际标题顺序“不正确”，屏幕阅读器也可以并确实使用标题来促进页面内导航。目前，它并不美观（有时——经常——堆叠不正确），但仍然有用。

Sections 和 Articles 是两个尚未在浏览器中真正实现的元素（尽管我相信 Firefox 4 将开始“原生”地支持它们），所以在目前，它们在所有实际用途上都还处于“从概念上讲这是一个好主意”的阶段。但是，对于不支持这些元素的浏览器，它们会将这些元素视为非语义的 div，因此通过添加 ARIA 地标角色，可以使它们对辅助技术具有良好的导航性和可访问性。作为一种面向未来的最佳实践，我认为这是开发人员今天可以开始实施的事情之一——只需不要忘记 ARIA 地标角色。

7) 在 HTML5 规范中发现图和标题的定义时，我真的很喜欢。但是，当您使用它们并希望辅助技术支持时，需要使用 ARIA labeled-by 并为每个图分配一个唯一的 ID，以便将其与标题逻辑地连接起来。这对许多开发人员来说是额外的努力，他们不会去完成。我发现很多 ARIA 东西都很冗长。是否有任何努力简化不同标准机构之间的沟通？

绝对的！

ARIA 作为规范/技术已经存在很长时间了——将近 10 年了——但直到过去 3 到 5 年，我们才看到屏幕阅读器等工具中出现了真正的支持。然而，ARIA 作为一种桥接技术构建，其设计既是为了修复现有问题，也是为了面向未来的发展：回过头去添加以下一些内容，使您现有的组件可访问。正因为如此，是的，它很难做到优雅或简洁。然而，自从它第一次被提出以来，它一直是一个“先有鸡还是先有蛋”的问题。

W3C 可访问性工作组关注的重要工作之一是确保 ARIA 功能正在集成并映射回新兴的 HTML5 元素和属性。虽然这项工作尚未完成，但承诺在 HTML5（标记语言）成为正式推荐之前完成。

看看您指出的两个示例——图和标题——更长远的计划是，这些将直接映射到浏览器解析器和可访问性 API，这样，在未来，它们将像宣传的那样“正常工作”。

今天添加 ARIA 属性是一种“双保险”的方法，既可以使您的内容面向未来，又可以确保它在今天即可访问。在许多方面，这与CSS3 中使用的供应商前缀非常相似：理想情况下，只需声明该属性即可，但由于它仍然是新兴技术，因此今天我们需要在属性前面加上供应商前缀（例如：-moz-margin-end、-webkit-margin-end——您必须在样式表中声明两次以同时定位这两个浏览器）。基本思想相同：是的，开发人员需要做更多工作，但没有简单的答案。

8) 您认为迄今为止 HTML5 视频和音频最大的问题是什么？是缺乏保护高级内容的选项吗？还是缺乏支持字幕和隐藏字幕的格式？编码问题？

实际上，我认为以上所有因素都导致了目前的不成熟。

我相信，编码问题在未来相当长一段时间内都将是一个复杂的政治博弈，平均内容制作者如果想原生地使用`

我担心时间戳格式的争论还没有结束（尽管 WHAT WG overwhelmingly 支持 WebSRT，或者 WebVTT，或者他们接下来决定叫什么）。我认为，当 SMTPE（电影和电视工程师协会）宣布他们行业支持的基于 TTML 的 SMPTE 时间文本格式时，这种情况几乎是必然的。当商业内容提供商自己决定时间格式时，人们会怀疑浏览器供应商（在在线内容分发商的压力下）会关注这个问题（尤其是在华盛顿目前对网络字幕的态度下）。虽然目前还没有浏览器在这里采取明确的立场，但我感觉至少微软可能会同时支持两者。

围绕 DRM 和家长控制的问题——不可否认，对于习惯于 Pirate Bay 和 torrent 馈送的一代人来说，这并不受欢迎——都是应该解决的问题，但可能不会很快解决，在我看来，这将进一步阻碍广泛的实施和采用：商业内容提供商会希望某种形式的 DRM，即使它可以被破解——破解行为与获取数字资产一样是犯罪行为。

同时，从 Flash 和 Silverlight 到 QuickTime 本身，针对原生`

9) Canvas 似乎是另一个重大的可访问性问题。您是否知道有任何措施正在采取，使您绘制到 Canvas 元素上的更改对辅助技术可理解？SVG 是否也存在同样的缺点？

是的，Canvas 仍然是一个棘手的可访问性挑战。遗憾的是，我并没有像关注媒体方面那样专注于这个方面，但我相信并信任正在解决这些问题的可访问性专家。Richard Schwerdtfeger（IBM）是 Canvas 可访问性子团队的主席，是一位非常聪明的工程师，所有浏览器供应商都在该子团队中积极讨论。据我了解，大家普遍认同子树 DOM，但浏览器之间的解决方案支持尚未到位。屏幕放大镜与插入符号焦点和文本度量交互仍然存在问题，以及如何将所有内容的绝对定位传达给使用盲文的屏幕放大镜和屏幕阅读器。

SVG 作为一项技术，与 Canvas 非常不同，而且在大多数情况下，SVG 几乎没有可访问性问题。有一个关于 SVG 可访问性功能的良好概述。

10) 安全使用新技术的灵丹妙药似乎是对象检测。在应用之前，您会测试浏览器是否支持某些内容。但这在辅助技术方面从未奏效。这是为什么？为什么我们不能简单地说`if(window.screenreader)`？

这样做不可行有很多原因。

首先，“屏幕阅读器”是一类软件工具，它们的行为略有不同。是的，如今在英语为母语的“西方”世界，JAWS 软件包占据着主导地位，但 WindowEyes、Hal/Supernova、ZoomText 以及像NVDA和 Serotek 的SAToGo这样的后起之秀正在挑战现状。然而，这些工具中没有一个的行为完全相同，而且有时它们的用户交互方式可能大不相同。再加上像韩国的Sense Reader Professional和巴西的Leitor de Telas这样的外语工具——仅举两例——探测屏幕阅读器就变得有些徒劳：如果您知道我正在使用 SAToGo（例如），这对您作为开发人员来说意味着什么，确切地说？

然而，情况变得更糟，因为您不仅需要考虑屏幕阅读器的“品牌”，还需要考虑版本。虽然 WebAIM 的屏幕阅读器调查去年证实，大多数用户会及时更新软件（74.6% 在第一年内），但仍然有近四分之一的用户使用可能长达 3 年或更旧的软件。开发人员还需要记住，屏幕阅读器不是浏览器的一部分，而是一个操作系统级别的软件工具，它不仅与浏览器交互，还与文本编辑器、电子表格应用程序和其他计算机上的生产力工具交互。

最后是 VoiceOver？苹果公司提供的操作系统级别的屏幕阅读选项几乎存在于他们今天发行的每个系统上，从 OSx 到 iOS——并不能保证仅仅因为它存在，它就被使用——或者使用它的人实际上是盲人。事实上，许多视力正常的用户也会有合法需要或愿望使用屏幕阅读技术，正如 VoiceOver 所证实的那样，因此专门针对屏幕阅读器定制“体验”的努力令人遗憾地不值得追求——您将继续错过与命中一样多的机会。（这有点让人想起那些会强制提供针对移动设备并针对其进行优化的网站替代版本的网站，并且不提供任何访问网站实际桌面版本的方法，即使用户想要这样）。

我告诉开发人员的是：按照标准编写代码，考虑优雅降级和渐进增强，并记住 Web 开发的最初“三条腿凳子”方法：内容、设计和脚本的分离。我提醒他们，残疾人士也负有社会责任，需要保持其软件相对更新（不多不少，就像任何其他用户一样——今天谁还在使用 Netscape 4？）以及/但是作为设计人员/开发人员，您必须始终考虑用户交互的“备用方案”——如果“方案 A”失败，那么“方案 B”是什么？

图片由 Dirk Ginader 提供

您是否知道我应该采访谁来参加“HTML5 人物”？请在 Twitter 上告诉我：@codepo8