dstat wai_使用WAI-ARIA改善您网站的可访问性

dstat wai

The following is an extract from our book, HTML5 & CSS3 for the Real World, 2nd Edition, written by Alexis Goldstein, Louis Lazaris, and Estelle Weyl. Copies are sold in stores worldwide, or you can buy it in ebook form here.

以下摘自Alexis Goldstein，Louis Lazaris和Estelle Weyl编写的《现实世界HTML5和CSS3，第二版 》一书。 副本在世界各地的商店中都有出售，或者您可以在此处以电子书形式购买 。

In Chapter 2 and Chapter 3, we covered considerable ground explaining how our pages can become more semantic and potentially more accessible using HTML5’s new semantic elements. Improved semantics alone, however, is often insufficient to make a sophisticated web application fully accessible.

在第2章和第3章中，我们介绍了相当多的基础知识，它们解释了如何使用HTML5的新语义元素使页面变得更加语义化并可能更易于访问。 但是，仅改进的语义通常不足以完全访问复杂的Web应用程序。

In order to have the content and functionality of our pages as accessible as possible for our users, we need the boost that WAI-ARIA provides, extending what HTML5 already does. We’ll avoid going into an extensive discussion on WAI-ARIA here—that’s a topic that could fill many chapters—but we felt it was important to mention it here so that you’re aware of your options.

为了使我们的用户可以尽可能地访问我们页面的内容和功能，我们需要WAI-ARIA提供的增强功能，以扩展HTML5已经完成的工作。 我们将避免在此处进行有关WAI-ARIA的广泛讨论，因为该主题可能会涉及许多章节，但是我们认为在此处提及这一点很重要，这样您才能知道自己的选择。

WAI-ARIA stands for Web Accessibility Initiative-Accessible Rich Internet Applications. The overview of WAI-ARIA on the W3C site explains it as:

WAI-ARIA代表Web Accessibility Initiative-可访问的富Internet应用程序。 W3C网站上的WAI-ARIA概述将其解释为：

[…] a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced JavaScript-heavy user interface controls developed with Ajax, HTML, JavaScript, and related technologies.

[…]一种使残障人士更容易访问Web内容和Web应用程序的方法。 它尤其有助于动态内容和使用Ajax，HTML，JavaScript和相关技术开发的高级JavaScript繁重的用户界面控件。

Users who rely on screen reader technology, or who are unable to use a mouse, are often excluded from using certain website and web application functionality—for example, sliders, progress bars, and tabbed interfaces. With WAI-ARIA, you’re able to deal with these shortcomings in your pages—even if the content and functionality is trapped in complex application architecture. Thus, parts of a website that would normally be inaccessible can be made available to users who are reliant on assistive technology.

依赖屏幕阅读器技术或无法使用鼠标的用户通常被排除在使用某些网站和Web应用程序功能(例如，滑块，进度栏和选项卡式界面)之外。 使用WAI-ARIA，即使内容和功能陷入复杂的应用程序体系结构中，您也可以解决页面中的这些缺点。 因此，依赖于辅助技术的用户可以使用通常无法访问的网站部分。

WAI-ARIA如何补充语义 (How WAI-ARIA Complements Semantics)

WAI-ARIA assigns roles to elements, and gives those roles properties and states. Here’s a simple example:

WAI-ARIA将角色分配给元素，并为这些角色提供属性和状态 。 这是一个简单的例子：

<li role="menuitemcheckbox" aria-checked="true">Sort by Date</li>

The application might be using the list item as a linked element to sort content; yet without the role and aria-checked attributes, a screen reader would have no way to determine what this element is for. Semantics alone (in this case, a list item) tells it nothing. By adding these attributes, the assistive device is better able to understand what this function is for.

该应用程序可能使用列表项作为链接元素来对内容进行排序。 但是如果没有角色和经过aria-checked属性，屏幕阅读器将无法确定此元素的用途。 仅语义(在本例中为列表项)无法说明任何内容。 通过添加这些属性，辅助设备可以更好地理解此功能的用途。

For semantic elements—for example header, h1, and nav—WAI-ARIA attributes in most cases are unnecessary, as those elements already express what they are. Instead, they should be used for elements whose functionality and purpose cannot be immediately discerned from the elements themselves (or for elements that have little or no accessibility support in one or more of the major browsers).

对于语义元素(例如header ， h1和nav在大多数情况下，WAI-ARIA属性是不必要的，因为这些元素已经表达了它们的含义。 相反，它们应用于无法立即从元素本身识别功能和用途的元素(或用于在一个或多个主要浏览器中几乎没有或没有可访问性支持的元素)。

WAI-ARIA的现状 (The Current State of WAI-ARIA)

The WAI-ARIA specification is still improving, as is HTML5, so these technologies are yet to provide all the benefits we would like. Although we’ve described the way that WAI-ARIA can extend the semantics of our page elements, it may be necessary to include WAI-ARIA roles on elements that already express their meaning in their names, because assistive technology doesn’t support all the new HTML5 semantics yet. In other words, WAI-ARIA can serve as a sort of stopgap, to provide accessibility for HTML5 pages while screen readers are catching up.

WAI-ARIA规范以及HTML5仍在改进中，因此这些技术尚未提供我们想要的所有好处。 尽管我们已经描述了WAI-ARIA可以扩展页面元素的语义的方式，但是可能需要在已经在其名称中表达其含义的元素上包括WAI-ARIA角色，因为辅助技术并不支持所有新HTML5语义呢。 换句话说，WAI-ARIA可以作为一种权宜之计，以在屏幕阅读器赶上时为HTML5页面提供可访问性。

Let’s look at a site navigation, for example:

让我们看一下网站导航，例如：

<nav role="navigation"> <ul>… </ul>
</nav>

It would seem that we’re doubling up here: the nav element implies that the list of links contained within it make up a navigation control, but we’ve still added the WAI-ARIA role navigation to it. In many cases, this sort of doubling up will often be necessary. In the case of the nav element, Internet Explorer is the only browser that doesn’t correctly expose a role of “navigation” by default, so for now, adding this attribute is necessary.

似乎我们在这里加倍： nav元素表示其中包含的链接列表构成导航控件，但我们仍在其中添加了WAI-ARIA角色navigation 。 在许多情况下，通常需要这种加倍。 对于nav元素，默认情况下，Internet Explorer是唯一无法正确显示“导航”角色的浏览器，因此，现在必须添加此属性。

Does this mean that WAI-ARIA will become redundant once HTML5 semantics and accessibility are fully supported? No. There are roles in WAI-ARIA without corresponding HTML5 elements; for example, the timer role. While you might represent a timer using the HTML5 time element and then update it with JavaScript, you’d have no way of indicating to a screen reader that it was a timer, rather than just an indication of a static time.

这是否意味着一旦完全支持HTML5语义和可访问性，WAI-ARIA将变得多余？ 否。WAI-ARIA中有一些角色没有相应HTML5元素； 例如， 计时器角色。 尽管您可以使用HTML5 time元素来表示计时器，然后使用JavaScript对其进行更新，但您将无法向屏幕阅读器表明它是计时器，而不仅仅是静态时间的指示。

For a screen reader to access WAI-ARIA roles, the browser must expose them through an accessibility API. This allows the screen reader to interact with the elements similarly to how it would access native desktop controls.

为了使屏幕阅读器访问WAI-ARIA角色，浏览器必须通过可访问性API公开它们。 这使屏幕阅读器可以像访问本地桌面控件一样与元素进行交互。

Browser support for ARIA features has been growing and is currently very good. All the latest versions of browsers support WAI-ARIA at least partially. A fairly up to date guide for support of accessibility features like WAI-ARIA in browsers on certain OSes can be found on the Paciello Group’s website.

浏览器对ARIA功能的支持一直在增长，并且目前非常好。 所有最新版本的浏览器都至少部分支持WAI-ARIA。 可以在Paciello Group的网站上找到有关在某些OS的浏览器中支持WAI-ARIA等可访问性功能的最新指南。

Finally, it’s worth noting that not all users who could benefit from WAI-ARIA roles are utilizing them. In Janaury 2014, WebAIM (Web Accessibility In Mind) conducted their fifth screen reader user survey, which revealed that about 28% of participants either seldom or never navigated web pages by means of ARIA landmarks. The good news is, the number of users utilizing ARIA landmarks is increasing. In 2010, in a similar survey, more than 50% either didn’t use or didn’t know ARIA roles existed.

最后，值得注意的是，并非所有可以从WAI-ARIA角色中受益的用户都在使用它们。 2014年1月，WebAIM(头脑中的Web Accessibility)进行了第五次屏幕阅读器用户调查，该调查显示约28％的参与者很少或从未使用ARIA地标浏览过网页。 好消息是，利用ARIA地标的用户数量正在增加。 在2010 年的类似调查中 ，超过50％的人不使用或不知道ARIA角色存在。

In short, there is pretty good support for WAI-ARIA and you won’t hurt your HTML5 documents by including these attributes. They pass markup validation in HTML5 and even though the full benefits are yet to be seen, they’ll only increase over time.

简而言之，对WAI-ARIA有很好的支持，并且通过包含这些属性，不会损害HTML5文档。 它们通过HTML5中的标记验证，尽管尚未看到全部好处，但它们只会随着时间的推移而增加。