随着互联网技术不断的革新，Web页面或应用不再局限于静态地向用户呈现文本或图片等内容。现在的Web页面或应用是一个 富应用，是一种具有近似于传统桌面应用软件系统功能和特性的网络应用系统。这也就是说，用户和Web应用的交互变得更丰富和更复杂。实现这些带有富交互的Web应用仅依靠HTML和CSS是无法实现了，换句话说，我们很多时候会使用一些非语义的HTML和动态的JavaScript脚本来构建，更新复杂的UI控制。Web应用变得更丰富的同时，可访问性的难度也就相应的更复杂了。

如果你阅读过该系列的前几篇文章，比如编写可访问性的Web应用在HTML和CSS需要注意哪些问题？那么你就或多或少知道在编写HTML和CSS时要注意的细节，以及这些细节怎么让一个Web应用更具可访问性。不过，话又说回来，构建一个可访问的Web应用并不是一件易事，其所涉及到的知识点非常的多，非常的细。比如，面对一个富应用，富交互的Web应用，仅仅依赖于HTML和CSS是无法知道他们所处的状态。那么这个时候就需要JavaScript的脚本来增强这方面的能力。而且很多时候会使用非语义化的HTML标签和动态的JavaScript脚本来构建或更新复杂UI控件，那么这些控件在可访问性方面就会更差。

不过幸运的是，WAI-ARIA技术的出现，让可访问性变得没有那么的难。因为WAI-ARIA技术可以通过浏览器和一些辅助技术来帮助我们进一步地识别以及实现语义化，除了帮助我们解决语义化的问题之外，还可以让用户知道发生了什么。

在接下来的内容中，将和大家一起初步的探讨WAI-ARIA技术给可访问性带来的变化。

WAI-ARIA是什么？

WAI-ARIA是Accessible Rich Internet Applications的一种简称，很多时候也被称为ARIA（即Accessible Rich Internet Applications首字母缩写）。它是W3C的Web无障碍推进组织（Web Accessibility Initiative / WAI）在2014年3月20日发布的可访问富互联应用实现指南。

W3C是这样定义WAI-ARIA的：

WAI-ARIA provides a framework for adding attributes to identify features for user interaction, how they relate to each other, and their current state. —— 来自于W3C

大致的意思是：WAI-ARIA提供了一个框架，用于添加属性来识别用户交互的特性，它们之间的关系以及它们当前状态。

而WAI是这样定义的：

A way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. —— 来自于WAI

大致意思是：WAI-ARIA是一种使Web内容和Web应用程序更容易被残障人士访问的方法。它特别有助于使用Ajax、HTML、JavaScript和相关技术开发动态内容和高级界面控件。

特别声明：可访问性（或无障碍）服务的用户群体不仅仅局限于残障人士，换句话说，WAI-ARIA也不仅是让残障人士更好的访问Web，而是应该让访问Web有障碍的用户群体更好的访问Web应用。有关于这方面更多的讨论，可以阅读《A11Y 101：构建可访问性应用的2W1H》一文。

简单地说，ARIA定义了一组属性来帮助修改不正确的标记并弥补HTML中的空白，从而为使用辅助技术（AT）的用户提供更方便的体验。正确地将ARAI合并到你的代码中可以确保辅助技术设备用户拥有使用你的网站或应用程序所有的信息。换句话说，构建一个可访问性的Web网站或Web应用就在原有的HTML、CSS和JavaScript基础上新增了ARIA：

ARIA技术方便你将有关元素的名称（Name）、角色（Role）、状态（State）、属性（Properties）或与其他元素的关系的信息传递给辅助技术。而且，ARIA对于辅助技术（比如屏幕阅读器）用户来说很像CSS，因为它纯粹是描述性的。它不会导致浏览器改变底层元素的外观或功能。比如下面这个示例：

<!-- 使用角色（role）定义了div元素是一个button -->
<div role="button">Here is a snazzy button</div>

<!-- 使用属性（Properties）描述了div元素的特征或关系 -->
<div role="button" aria-describedby="some-other-element">Here is a snazzy button</div> 
<div id="some-other-element">This page will self destruct in 10 seconds.</div>

<!-- 使用状态（State）定义与元素相关的当前条件或数据值 -->
<div role="button" aria-describedby="some-other-element" aria-pressed="false">Here is a snazzy button</div> 
<div id="some-other-element">This page will self destruct in 10 seconds.</div>

不难发现，上面的HTML代码中有一些新的属性，比如role、aria-describedby和aria-pressed等。你可能现在还不知道这些标签属性有何用，怎么用？其实也不必着急，随着后面的学习，你会明白他们具体的含义和作用。在这里，你只需要知道它们是ARIA中的相关特性即可。

从上面的代码中你可能发现了，ARIA通过更改和补充标准DOM的属性来发挥作用，这些属性可以修改元素转换成无障碍树的方式：

用一个小示例简单地向大家演示AOM树(Accessibility Object Tree)的形成过程：

在浏览器渲染地过程中，可访问树（AOM Tree）和 DOM树是并行结构。粗略地说，可访问树是DOM树的子集。它包括用户代理的用户接口对象和文档的对象。可访问对象是在可访问树中为每个应该暴露给辅助技术的DOM元素创建的，因为它可能触发一个可访问事件，或者因为它有一个需要暴露的属性、关系和特性。通常情况下，如果某些内容可以被删除，那么它就会被删除，这是出于性能和简单性的考虑。例如，只有样式更改而没有语义的<span>可能无法获得自己的可访问对象，但是样式更改将通过其他方式来处理。

有关于AOM树，我们在后续会专门和大家一起探讨。

所以说，大家不必担心ARIA会更改你的Web页面功能或整体外观（除非你的CSS中使用属性选择器用来控制ARIA相关的属性，比如[role="button"]）。如果我们了解了AOM树的话，可以清楚的地知道ARIA可以看作是HTML和ATs之间的另一层理解。这也意味着，除了ATs（以及使用它们的人），没有人会注意到有ARIA的网页或应用程序与没有ARIA的网页或应用程序之间会存在任何的区别。

当然，对于开发者而言，如果借助ARIA技术来增强可访问性的构建，那么有ARIA和无ARIA的区别还是很大的。最起码，你的代码会越来越复杂。因此了解ARIA的角色、属性和状态的基本规则可以帮助你在HTML标签中如何正确的使用ARIA技术。

时至今日，WAI-ARIA规范主要有两个版本，一个是1.0版本，另一个是1.1版本，其中1.1版本只是包含了1.0版本的一些更改。

在2.0版本中将会涵盖大多数的更改。

有关于WAI-ARIA当前的情况和发展更详细的介绍，可以点击这里进行了解。

为什么要使用WAI-ARIA

随着Web应用变得越来越复杂和动态化，一堆全新的Web可访问性问题和特性也接踵而至。

例如，HTML5提出了几种语义化标签用于定义常规页面的特性（比如header、main、footer、nav等）。在这些标签可用之前，我们一般是在div元素上命名带有语义化的类名（class）或ID名称。比如<div class="header"></div>。但是这种实践是问题丛生的，因为没有简单的方法可以轻松地用可编程的方法找到特定页面功能，例如主导航。

最早的解决方案是加一个或多个隐藏的链接来跳转到我们想要的位置，例如：

<div id="skip-link">
    <a href="#main-content" class="visible-hidden">跳转到主要内容</a>
</div>

<div id="main-content"></div>

.visible-hidden {
    clip: rect(1px, 1px, 1px, 1px);
    height: 1px;
    overflow: hidden;
    position: absolute;
    white-space: nowrap;
    width: 1px;
}

.visible-hidden:focus {
    clip: auto;
    height: auto;
    overflow: auto;
    position: absolute;
    width: auto;
}

但这仍然是不准确的，而且只能在屏幕阅读器开启页面顶部读取时使用。

另一个例子：应用开始支持一些复杂的类型（<input />）输入，像是日期选择器可选择日期，或是范围选择器可以用滑块选择值，HTML5 提供了以下的类型：

<input type="date" />
<input type="range" />

他对于跨浏览器的支持并不好，而且他的样式修改也很麻烦，这使得他在网页的集成设计上难以有所用途。我们常常会用JavaScript 库来做这事，所以会用一系列嵌套的div 或者带有class的table元素，然后用CSS来制定样式，JavaScript 来控制行为。

这样的问题是视觉上这样做事可行的，但屏幕阅读器对此会感到一无所知，他只能告诉用户她看到一堆复杂结构的元素，且毫无语义可言。

这个时候我们就需要依赖于ARIA技术，在DOM元素上添加适当的ARIA属性，让屏幕阅读器也能感知到这些UI控件是什么？

WAI-ARIA可以做什么？

通过前面的学习，我们知道WAI-ARIA是W3C编写的一套规范，定义了一组可用于其他元素的HTML特性（Attributes），用于提供额外的语义化以及改善缺乏的可访问性。比如前面示例中的代码：

<div role="button">回到首页</div>

div标签是属性无语义化的一个HTML标签，通过ARIA技术，即给div标签加上role（角色），这样一来一些辅助技术（比如屏幕阅读器）就知道这个div不是一个普通的标签，而一个具有按钮角色的标签。

正如上面示例所示，ARIA就是这么简单易于。虽然ARIA是一套独立的规范，但对于一个Web页面或Web应用程序而言，ARIA始终离不开HTML，哪怕是通过JavaScript动态来控制ARIA，也最终附加到HTML标签元素上。如果不想思考太多，可以简单地理解成：

ARIA所有特性都是HTML的附加属性（Attributes）。

ARIA整个规范中有三个主要的特性：角色（Role）、状态（State）和属性（Property）：

这三个主要特性涉及较多的内容，后续我们还会分章节阐述，感兴趣的同学可以持续关注后续相关更新。在这篇文章中只会简单的介绍这三个特性。

进入WAI-ARIA的世界

我身边很多小伙伴都喜欢玩游戏，比如王子荣耀，如果你和我一样不太熟悉这些游戏也不要紧，没吃过猪肉总看过猪跑吧。在游戏中有很多人物角色的扮演：

这些角色在奇幻游戏世界中进行战斗和完成相应任务。虽然我自己并不太喜欢玩这些游戏，但我注意到游戏中的角色扮演的方式与Web应用程序中的HTML元素的行为方式有着相似之处。因此，我将使用这个角色扮演来比喻ARIA中的角色、属性和状态更有助于大家理解。

角色（Roles）

游戏中的每个角色都有一个“角色表”，列表所扮演角色的重要特征。比如王子荣耀中的“西施”所具备的重要特征如下：

在HTML中元素可能会有属性，属性会有名称，名称可能是一串字符串，比如id的属性名称footer。在HTML中的id这样的属性是唯一的。但是字符比工作表中包含的信息要多得多。例如，在游戏中的角色通常属于一个或一个“种族”。该角色可能会有很多种替身（比如“精灵”、“矮人”和“巨魔”，这些可能在王子荣耀游戏中没有，因为我不懂游戏，但性质是类似的）。游戏中这些类似于HTML元素类型：具有共同特征的参与者的广泛分组，是不是有点像HTML元素周期表：

在ARIA中，角色属性覆盖了元素类型，就像游戏中“矮人”。在前面我们的示例代码中看到过role="button"，其实就是把div充当了button的角色：

ARIA中的角色就像游戏中扮演角色中的“种族”一样，是我们可能感兴趣的角色身份的一部分。我们可能期望“矮人”们强壮并且擅长构造机器，就好比我们期望在非<button>元素上具有特征和行为一样。通过role="button"让一个实际上不是<button>的元素在辅助技术（比如屏幕阅读器）上可以将其识别成一个<button>，并且让其具备相应的特征和行为。

如果用术语来描述的话，ARIA中的角色是用于定义用户界面（UI）元素的类型，一旦为元素设置了角色，它就不会更改。ARIA规范中明确的描述和罗列了所有角色相关的信息。

为了支持当前用户场景，ARIA规范将定义用户界面小部件（比如滑块，树控件等）和定义页面结构（比如节、导航等）的角色分类。注意，一些辅助技术为带朋角色应用程序或文档的区域提供了特殊的交互模式。在ARIA中所有角色的分类可以用下图来描述：

可能很多角色到目前为止不一定能全部用上，我们可以像HTML元素周期表一样，整理一份类似ARIA角色的周期表，它可能像下面这样：

具体的ARIA角色可以分为以下几种类型：

抽象的角色（Abstract Roles）

抽象的角色是所有其他角色的基础，但是浏览器使用抽象角色不应该在代码中使用。相反，它们用于在上下文中赋予角色意义，并帮助添加新角色。在ARIA中被列表抽象角色的主要有：command、composite、input、landmark、range、roletype、section、sectionhead、select、structure、widget和window。

部件的角色（Widget Roles）

当HTML没有定义元素时，部件角色为元素和用户界面（UI）添加语义，无论大小。根据W3C的 ARIA 5.3.2 Widget Roles所描述，可以用多个独立的UI小部件组合成更大的小部件，而复合UI小部件充当管理其他包含小部件的容器。

独立的小部件主要有：button、checkbox、gridcell、link、