WAI-ARIA basics

什么是WAI-ARIA？

让我们开始看看WAI-ARIA是什么，它可以为我们做什么。

一整套新的问题

随着网络应用开始变得更加复杂和动态，一组新的无障碍功能和问题开始出现。

例如，HTML5引入了一些语义元素来定义通用页面功能( < ; nav> ， < footer> 等)。在提供这些功能之前，开发人员只需使用 < div> 带有ID或类，例如 < div class ="nav"> ，但这些都有问题，因为没有简单的方法轻松地找到特定的页面功能，如主导航程序。

最初的解决方案是在页面顶部添加一个或多个隐藏链接，以链接到导航(或其他任何方式)，例如:

<a href="#hidden" class="hidden">Skip to navigation</a>

但是这还不是很精确，只能在屏幕阅读器从页面顶部读取时使用。

作为另一个示例，应用程序开始具有复杂的控件，如用于选择日期的日期选择器，用于选择值的滑块等。HTML5提供特殊的输入类型来呈现这样的控件:

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

这些在浏览器上不能很好地支持，并且也很难对它们进行风格化，使得它们对于与网站设计的集成不是非常有用。 因此，开发人员通常依赖于生成此类控件的JavaScript库，例如一系列嵌套的 < div> 或带有类名的表格元素，然后使用CSS对其进行样式化并使用JavaScript进行控制。

这里的问题是视觉上他们工作，但是screenreaders不能对任何东西有任何意义，他们的用户只是被告知他们可以看到一些没有语义的元素来描述他们的意思。

输入WAI-ARIA

WAI-ARIA 是W3C编写的规范，定义了一组额外的 HTML属性，可以应用于元素，以提供额外的语义，并提高无处不在的无障碍性。 规范中定义了三个主要特性:

• Roles — These define what an element is or does. Many of these are so-called landmark roles, which largely duplicate the semantic value of HTML5 structural elements e.g. role="navigation" (<nav>) or role="complementary" (<aside>), but there are also others that describe different pages structures, such as role="banner", role="search", role="tabgroup", role="tab", etc., which are commonly found in UIs.
• Properties — These define properties of elements, which can be used to give them extra meaning or semantics. As an example, aria-required="true" specifies that a form input needs to be be filled in to be valid, whereas aria-labelledby="label" allows you to put an ID on an element, then reference it as being the label for anything else on the page, including multiple elements, which is not possible using <label for="input">. As an example, you could use aria-labelledby to specify that a key description contained in a <div> is the label for multiple table cells, or you could use it as an alternative to image alt text — specify existing information on the page as an image's alt text, rather than having to repeat it inside the alt attribute. You can see an example of this at Text alternatives.
• States — Special properties that define the current conditions of elements, such as aria-disabled="true", which specifies to a screenreader that a form input is currently disabled. States differ from properties in that properties don't change throughout the lifecycle of an app, whereas states can change, generally programmatically via JavaScript.

关于WAI-ARIA属性的一个重要点是，它们不影响网页的任何内容，除了浏览器的辅助API(屏幕阅读器从其中获取信息)暴露的信息。 WAI-ARIA不影响网页结构，DOM等，虽然属性可以用于通过CSS选择元素。

WAI-ARIA在哪里支持？

这不是一个容易回答的问题。 很难找到一个结论性资源，说明WAI-ARIA的哪些特性得到支持，以及在哪里，因为:

1. There are a lot of features in the WAI-ARIA spec.
2. There are many combinations of operating system, browser, and screenreader to consider.

最后一点是关键 - 要首先使用屏幕阅读器，您的操作系统需要运行具有必要的可访问性API的浏览器，以公开屏幕阅读器需要完成工作的信息。 最流行的操作系统有一个或两个浏览器，屏幕阅读器可以使用。 Paciello集团有一个相当新的职位，为此提供数据 - 参见 和屏幕阅读器支持更新/"class ="外部">粗糙指南:浏览器，操作系统和屏幕阅读器支持更新。

接下来，您需要担心所讨论的浏览器是否支持ARIA功能并通过其API展示它们，还需要担心屏幕阅读器是否识别该信息并以有用的方式向用户展示。

1. Browser support is generally quite good — at the time of writing, caniuse.com stated that global browser support for WAI-ARIA was around 88%.
2. Screenreader support for ARIA features isn't quite at this level, but the most popular screenreaders are getting there. You can get an idea of support levels by looking at Powermapper's WAI-ARIA Screen reader compatibility article.

在本文中，我们不会尝试覆盖每个WAI-ARIA功能及其确切的支持细节。 相反，我们将介绍最关键的WAI-ARIA功能，让您了解; 如果我们没有提及任何支持详细信息，您可以假定该功能得到了很好的支持。 我们将明确提到任何例外。

什么时候应该使用WAI-ARIA？

我们讨论了一些促使WAI-ARIA早期创建的问题，但本质上，WAI-ARIA有四个主要方面:

1. Signposts/Landmarks: ARIA's role attribute values can act as landmarks that either replicate the semantics of HTML5 elements (e.g. <nav>), or go beyond HTML5 semantics to provide signposts to different functional areas, e.g search, tabgroup, tab, listbox, etc.
2. Dynamic content updates: Screenreaders tend to have difficulty with reporting constantly changing content; with ARIA we can use aria-live to inform screenreader users when an area of content is updated, e.g. via XMLHttpRequest, or DOM APIs.
3. Enhancing keyboard accessibility: There are built-in HTML elements that have native keyboard accessibility; when other elements are used along with JavaScript to simulate similar interactions, keyboard accessibility and screenreader reporting suffers as a result. Where this is unavoidable, WAI-ARIA provides a means to allow other elements to receive focus (using tabindex).
4. Accessibility of non-semantic controls: When a series of nested <div>s along with CSS/JavaScript is used to create a complex UI-feature, or a native control is greatly enhanced/changed via JavaScript, accessibility can suffer — screenreader users will find it difficult to work out what the feature does if there are no semantics or other clues. In these situations, ARIA can help to provide what's missing with a combination of roles like button, listbox, or tabgroup, and properties like aria-required or aria-posinset to provide further clues as to functionality.

有一件事要记住 - 您只应在需要时才使用WAI-ARIA！理想情况下，您应该始终 使用本地 HTML功能，以提供屏幕阅读器需要的语义，告诉他们的用户发生了什么。 有时候这是不可能的，因为你对代码的控制有限，或者因为你创建的东西很复杂，没有一个简单的HTML元素来实现它。 在这种情况下，WAI-ARIA可以是一个有价值的辅助工具。

但是，再次，只有在必要时使用它！

实用的WAI-ARIA实现

在下一节中，我们将更详细地讨论这四个方面，以及实例。 在你继续之前，你应该得到一个screenreader测试设置到位，所以你可以测试一些例子，当你经历。

有关详细信息，请参阅我们的有关测试屏幕阅读器的部分。

路标/地标

WAI-ARIA添加了 角色属性 到浏览器，这允许您添加额外的语义值到您的网站上的元素，无论他们需要什么。 这是有用的第一个主要领域是为屏幕阅读器提供信息，以便他们的用户可以找到共同的页面元素。 让我们来看一个例子 - 我们的 website-no- 角色示例(查看实时 )具有以下结构:

<header>
  <h1>...</h1>
  <nav>
    <ul>...</ul>
    <form>
      <!-- search form  -->
    </form>
  </nav>
</header>

<main>
  <article>...</article>
  <aside>...</aside>
</main>

<footer>...</footer>

如果您在现代浏览器中尝试使用屏幕阅读器测试示例，您将获得一些有用的信息。 例如，VoiceOver为您提供以下内容:

• On the <header> element — "banner, 2 items" (it contains a heading and the <nav>).
• On the <nav> element — "navigation 2 items" (it contains a list and a form).
• On the <main> element — "main 2 items" (it contains an article and an aside).
• On the <aside> element — "complementary 2 items" (it contains a heading and a list).
• On the search form input — "Search query, insertion at beginning of text".
• On the <footer> element — "footer 1 item".

如果你去VoiceOver的地标菜单(使用VoiceOver键+ U访问，然后使用光标键在菜单选项之间循环)，你会看到，大多数元素被列出，以便他们可以快速访问。

alt ="">

但是，我们可以在这里做得更好。 搜索形式是人们想要找到的一个非常重要的地标，但是它不被列在地标菜单中或者被视为一个显着的地标，超出实际输入被称为搜索输入(<输入类型 ="search"> )。 此外，一些旧的浏览器(最引人注目的是IE8)不能识别HTML5元素的语义。

让我们通过使用一些ARIA特性来改进它。 首先，我们将向HTML结构中添加一些角色属性。 您可以尝试复制我们的原始文件(请参阅 ="external"> index.html 和 class ="external"> style.css )，或导航到我们的 roles"class ="external"> website-aria-roles example( ="external"> see it live )，其具有如下结构:

<header>
  <h1>...</h1>
  <nav role="navigation">
    <ul>...</ul>
    <form role="search">
      <!-- search form  -->
    </form>
  </nav>
</header>

<main>
  <article role="article">...</article>
  <aside role="complementary">...</aside>
</main>

<footer>...</footer>

在此示例中，我们还为您提供了一个奖励功能 - < input&gt ; 元素已被赋予属性 "> aria-label ，它提供了一个描述性标签，供屏幕阅读器读取，即使我们没有包含 / zh-CN / docs / Web / HTML / Element / label"> < label> 元素。 在这样的情况下，这是非常有用的 - 像这样的搜索形式是一个非常常见的，容易识别的功能，添加一个视觉标签会破坏页面设计。

<input type="search" name="q" placeholder="Search query" aria-label="Search through site content">

现在如果我们使用VoiceOver来看这个例子，我们得到一些改进:

• The search form is called out as a separate item, both when browsing through the page, and in the Landmarks menu.
• The label text contained in the aria-label attribute is read out when the form input is highlighted.

除此之外，该网站更有可能访问旧版浏览器(如IE8)的用户; 它值得包括ARIA角色为此目的。 如果由于某种原因，你的网站是使用< div> 构建的，你必须包括ARIA角色来提供这些需要的语义！

搜索表单的改进语义表明当ARIA超越HTML5中可用的语义时，使得可能成为可能。 您将在下面看到更多关于这些语义和ARIA属性/属性的强大功能，特别是在非语义控件的辅助功能部分。 现在，让我们看看ARIA如何帮助动态内容更新。

动态内容更新

加载到DOM中的内容可以使用屏幕阅读器轻松访问，从文本内容到附加到图像的替代文本。 因此，具有大量文本内容的传统静态网站对于具有视觉障碍的人来说容易获得。

问题是，现代网络应用通常不只是静态文本 - 它们往往有很多动态更新内容，即更新内容，而不通过像 .org / zh-CN / docs / Web / API / XMLHttpRequest"> XMLHttpRequest ， 提取或 DOM API 。 这些区域有时称为有效区域。

让我们看一个快速示例 - 请参阅 aria -no-live.html (也 see 它运行实时)。 在这个例子中，我们有一个简单的随机引用框:

<section>
  <h1>Random quote</h1>
  <blockquote>
    <p></p>
  </blockquote>
</section>

我们的JavaScript通过 XMLHttpRequest 加载一个JSON文件，其中包含一系列 的随机引用及其作者。 完成后，我们开始创建 setInterval() / code>循环，每10秒将一个新的随机引用加载到引用框中:

var intervalID = window.setInterval(showQuote, 10000);

这工作正常，但它不利于辅助功能 - 内容更新不被屏幕阅读器检测，所以他们的用户不会知道发生了什么。 这是一个相当微不足道的例子，但只是想象如果你是创建一个复杂的UI，有很多不断更新的内容，如聊天室，战略游戏UI或实时更新购物车显示 - 这将是不可能使用 应用程序以任何有效的方式，没有某种方式提醒用户更新。

WAI-ARIA幸运地提供了一个有用的机制来提供这些警报 - > aria-live 属性。 将此应用于元素会导致屏幕阅读器读取更新的内容。 如何紧急地读取内容取决于属性值:

• off: The default. Updates should not be announced.
• polite: Updates should be announced only if the user is idle.
• assertive: Updates should be announced to the user as soon as possible.
• rude: Updates should be announced straight away, even if this interrupts the user.

通常，一个 assertive 设置足以让你的更新在显示时按顺序读出，所以如果一次更改多个东西，你最终会得到所有的更新。 只对真正高优先级的更新使用 rude ，应该覆盖所有其他。

我们希望您复制 > aria-no-live.html 和 quotes.json ，并更新您的< section> 标记，如下所示:

<section aria-live="assertive">

这将使屏幕阅读器在更新时读出内容。

注意:如果您尝试从 file:// 网址(例如，http://www.google.com/intl/zh-CN/)下载 XMLHttpRequest 调用，大多数浏览器都会抛出安全性异常。 如果你只是加载文件通过直接加载到浏览器(通过双击等)。 要使其运行，您需要将其上传到网络服务器，例如使用GitHub 或本地网络服务器，例如 //www.pythonforbeginners.com/modules-in-python/how-to-use-simplehttpserver/"class ="external"> Python的SimpleHTTPServer 。...

<section aria-live="assertive" aria-atomic="true">

aria-atomic ="true"属性指示屏幕阅读器将整个元素内容读取为一个原子单位，而不仅仅是已更新的位。

增强键盘辅助功能

如模块中的其他几个地方所讨论的，HTML的关于可访问性的一个关键优势是内置键盘辅助功能，如按钮，表单控件和链接。 通常，您可以使用Tab键在控件之间移动，使用Enter / Return键选择或激活控件，偶尔还可以根据需要使用其他控件(例如，上下光标可以在< ;选择> 框)。

然而，有时你最终不得不编写代码，使用非语义元素作为按钮(或其他类型的控件)，或使用可聚焦控件不完全正确的目的。 你可能试图修复你继承的一些坏代码，或者你可能正在构建一些需要它的复杂的窗口小部件。

在使不可聚焦代码可聚焦的方面，WAI-ARIA使用一些新值来扩展 tabindex 属性:

• tabindex="0" — as indicated above, this value allows elements that are not normally tabbable to become tabbable. This is the most useful value of tabindex.
• tabindex="-1" — this allows not normally tabbable elements to receive focus programmatically, e.g. via JavaScript, or as the target of links. 

我们详细讨论了这一点，并在HTML辅助功能文章中显示了一个典型的实现 - 请参阅构建键盘辅助功能。

非语义控制的可访问性

从上一节开始，当使用一系列嵌套的< code>< div> 以及CSS / JavaScript来创建复杂的UI特征时，或者通过 JavaScript，不仅可以让键盘的可访问性受损，而且如果没有语义或其他线索，那么screenreader用户会发现很难找出该功能的作用。 在这种情况下，ARIA可以帮助提供那些缺失的语义。

Form validation and error alerts

首先，让我们重温一下我们在CSS和JavaScript辅助功能文章中首先查看的表单示例(请参阅保持不引人注目的完整回顾)。 在本节结束时，我们显示在尝试提交表单时出现验证错误时，我们在错误消息框中包含了一些ARIA属性:

<div class="errors" role="alert" aria-relevant="all">
  <ul>
  </ul>
</div>

• role="alert" automatically turns the element it is applied to into a live region, so changes to it are read out; it also semantically identifies it as an alert message (important time/context sensitive information), and represents a better, more accessible way of delivering an alert to a user (modal dialogs like alert() calls have a number of accessibility problems; see Popup Windows by WebAIM).
• An aria-relevant value of all instructs the screenreader to read out the contents of the error list when any changes are made to it — i.e. when erros are added or removed. This is useful because the user will want to know what errors are left, not just what has been added or removed from the list.

我们可以进一步与我们的ARIA使用，并提供一些更多的验证帮助。 如何指示字段是否需要在第一位置，年龄应该是什么范围？

1. At this point, take a copy of our form-validation.html and validation.js files, and save them in a local directory.
2. Open them both in a text editor and have a look at how the code works.
3. First of all, add a paragraph just above the opening <form> tag, like the one below, and mark both the form <label>s with an asterisk. This is normally how we mark required fields for sighted users.

   <p>Fields marked with an asterisk (*) are required.</p>

4. This makes visual sense, but it isn't as easy to understand for screenreader users. Fortunately, WAI-ARIA provides the aria-required attribute to given screenreaders hints that they should tell users that form inputs need to be filled in. Update the <input> elements like so:

   <input type="text" name="name" id="name" aria-required="true">
   
   <input type="number" name="age" id="age" aria-required="true">

5. If you save the example now and test it with a screenreader, you should hear something like "Enter your name star, required, edit text".
6. It might also be useful if we give screenreader users and sighted users an idea of what the age value should be. This is often presented as a tooltip, or placeholder inside the form field perhaps. WAI-ARIA does include aria-valuemin and aria-valuemax properties to specify min and max values, but these currently don't seem very well supported; a better supported feature is the HTML5 placeholder attribute, which can contain a message that is shown in the input when no value is entered, and is read out by a number of screenreaders. Update your number input like this:

   <input type="number" name="age" id="age" placeholder="Enter 1 to 150" aria-required="true">

<label&gt\">除了经典的 < label>之外，WAI-ARIA还提供了一些高级表单标签技术 element.\">; 元素。aria-label\">我们已经讨论过使用 aria-label property to provide a label where we don\'t want the label to be visible to sighted users (see the Signposts/Landmarks section, above).\">属性，以提供标签，以便我们不希望标签对目击的用户可见(请参阅上面的路标/地标部分)。aria\">还有一些其他标签技术使用其他属性，例如 aria if you want to designate a non-<label> element as a label or label multiple form inputs with the same label, and -labelledby ，如果您要将非< label> 元素指定为具有相同标签的标签或标签多个表单输入，以及 aria-describedby, if you want to associate other information\">="https://www.w3.org/TR/wai-aria-1.1/#aria-describedby"class ="external"> aria-describedby ，如果您要关联其他信息与表单输入并且它读出。WebAIM\'s Advanced Form Labeling article for more details.\">有关详细信息，请参见 WebAIM的高级表单标签文章 。\">>

还有许多其他有用的属性和状态，用于指示表单元素的状态。 例如， aria-disabled ="true "可用于指示表单字段已禁用。 许多浏览器将跳过过去禁用的表单字段，它们甚至不会被屏幕阅读器读出，但在某些情况下它们会被感知到，因此最好包含此属性以让屏幕阅读器知道禁用的输入 实际上已停用。

如果输入的禁用状态可能改变，那么指示它何时发生，以及结果是什么也是一个好主意。 例如，在我们的表单验证 - disabled.html 演示中有一个复选框，当选中时，启用另一个表单输入，以允许输入更多的信息。 我们已设置了隐藏的活动区域:

<p class="hidden-alert" aria-live="assertive"></p>

使用绝对定位隐藏视图。 当选中/取消选中时，我们更新隐藏的活动区域内的文本，告诉屏幕阅读器用户检查此复选框的结果，以及更新 aria禁用状态，以及一些可视指示器 太:

function toggleMusician(bool) {
  var instruItem = formItems[formItems.length-1];
  if(bool) {
    instruItem.input.disabled = false;
    instruItem.label.style.color = '#000';
    instruItem.input.setAttribute('aria-disabled', 'false');
    hiddenAlert.textContent = 'Instruments played field now enabled; use it to tell us what you play.';
  } else {
    instruItem.input.disabled = true;
    instruItem.label.style.color = '#999';
    instruItem.input.setAttribute('aria-disabled', 'true');
    instruItem.input.removeAttribute('aria-label');
    hiddenAlert.textContent = 'Instruments played field now disabled.';
  }
}

Describing non-semantic buttons as buttons

在本课程中已经有几次，我们已经提到了(以及使用其他元素伪造的辅助功能问题)按钮，链接或表单元素(参见 HTML无障碍文章中的UI控件和上面的增强键盘辅助功能)。 基本上，您可以添加键盘辅助功能，在很多情况下，使用 tabindex 和一点JavaScript，而不会有太多的麻烦。

但是screenreaders呢？ 他们仍然不会看到按钮的元素。 如果我们测试我们的假 -div-buttons.html 示例在屏幕阅读器中，我们的假按钮将使用像"Click me !, group"这样的短语进行报告，这显然令人困惑。

我们可以使用WAI-ARIA角色解决这个问题。 制作本地副本 "external"> fake-div-buttons.html ，然后添加 外部">角色="按钮" 到每个按钮< div> ，例如:

<div data-message="This is from the first button" tabindex="0" role="button">Click me!</div>

现在，当你使用屏幕阅读器尝试这个，你会有按钮报告使用短语，如"点击我！"按钮 - 更好。

Guiding users through complex widgets

还有很多其他角色可以识别非语义 元素结构作为超越标准HTML中可用的常见UI功能，例如 "> combobox ， slider a> ， tabpanel >， 树 。 您可以在 Deque大学代码库中查看一些有用的示例，以了解这些控件如何 可以访问。

让我们通过一个我们自己的例子。 我们将返回到我们简单的绝对定位标签式界面(请参阅我们的CSS和JavaScript辅助功能文章中的隐藏内容)，您可以在 ="http://mdn.github.io/learning-area/css/css-layout/practical-positioning-examples/info-box.html"class ="external-icon external">标签式信息框示例 >(请参阅 外部">源代码)。

此示例原样在键盘辅助功能方面工作正常 - 您可以愉快地在不同的选项卡之间选择并选择它们以显示选项卡内容。 它也是相当容易访问 - 你可以滚动内容和使用标题导航，即使你看不到屏幕上发生了什么。 然而，这不是显而易见的内容是什么 - 屏幕阅读器当前报告内容作为链接的列表，一些内容与三个标题。 它不会给你任何想法的内容之间的关系。 给予用户关于内容的结构的更多线索总是好的。

为了改进这些，我们创建了一个新版本的示例，名为 html"class ="external"> aria-tabbed-info-box.html ( -box.html"class ="external">看到它正在运行)。 我们更新了标签式界面的结构，如下所示:

<ul role="tablist">
  <li class="active" role="tab" aria-selected="true" aria-setsize="3" aria-posinset="1" tabindex="0">Tab 1</li>
  <li role="tab" aria-selected="false" aria-setsize="3" aria-posinset="2" tabindex="0">Tab 2</li>
  <li role="tab" aria-selected="false" aria-setsize="3" aria-posinset="3" tabindex="0">Tab 3</li>
</ul>
<div class="panels">
  <article class="active-panel" role="tabpanel" aria-hidden="false">
    ...
  </article>
  <article role="tabpanel" aria-hidden="true">
    ...
  </article>
  <article role="tabpanel" aria-hidden="true">
    ...
  </article>
</div>

新功能如下:

• New roles — tablist, tab, tabpanel — these identify the important areas of the tabbed interface — the container for the tabs, the tabs themselves, and the corresponding tabpanels.
• aria-selected — Defines which tab is currently selected. As different tabs are selected by the user, the value of this attribute on the different tabs is updated via JavaScript.
• aria-hidden — Hides an element from being read out by a screenreader. As different tabs are selected by the user, the value of this attribute on the different tabs is updated via JavaScript.
• tabindex="0" — As we've removed the links, we need to give the list items this attribute to provide it with keyboard focus.
• aria-setsize — This property allows you to specify to screenreaders that an element is part of a series, and how many items the series has.
• aria-posinset — This property allows you to specify what position in a series an element is in. Along with aria-setsize, it provides a screenreader with enough information to tell you that you are currently on item "1 of 3", etc. In many cases, browsers should be able to infer this information from the element hierarchy, but it certainly helps to provide more clues.

在我们的测试中，这种新结构确实有助于改善整体。 这些标签现在被识别为标签(例如，屏幕阅读器说出"标签")，所选标签由"选择"指示，并且标签名称被读出，并且屏幕阅读器还告诉您当前正在使用哪个标签号码。 此外，由于 aria-hidden 设置(只有非隐藏选项卡具有 aria-hidden ="false"设置)，所以非隐藏内容是 只有一个您可以向下导航，这意味着所选内容更容易找到。

概要

这篇文章并没有涵盖WAI-ARIA中的所有内容，但它应该给你足够的信息来了解如何使用它，并且知道一些你将遇到的最常见的模式。

也可以看看

• Definition of Roles — ARIA roles reference.
• Definitions of States and Properties (all aria-* attributes) — properties and states reference.
• Deque university code library — a library of really useful practical examples showing complex UI controls made accessible using WAI-ARIA features.
• WAI-ARIA Authoring Practices — very detailed design patterns from the W3C, explaining how to implement different types of complex UI control whilst making them accessible using WAI-ARIA features.
• ARIA in HTML — A W3C spec that defines, for each HTML feature, what accessibility (ARIA) semantics that feature implicitly has set on it by the browser, and what WAI-ARIA features you may set on it if extra semantics are required.