译文对无障碍网页应用（ARIA）的选择

//本文编辑格式为Markdown，译文同时发布在众成翻译

对无障碍网页应用（ARIA）的选择

让网站对每个人都能访问是一件相当艰难的工作，尤其是在我们使用自定义标记解决方案（custom markup solutions）的那些日子。我很高兴#a11y(可访问性的简称)的话题最近获得了越来越多的关注，因为#a11y没有什么好的,但是正如James Williamson今天发布的twitter:

我们对提高可访问性最大的误解是认为那是在帮别人，但是你错了，这是你的职责。(The biggest misconception about accessibility is that by adding it you're doing somebody a favor. You're not, you're doing your job.)

为了使你的网站更便于访问，你可以使用 WAI-ARIA（无障碍网页应用）来提供更多语义化的信息，去支持一些访问辅助技术。

WAI-ARIA背后的想法很伟大，但不幸的是它可能有超乎想象的使用难度。最近，我遇到了一个分页部件（pagination component）的例子，并且我在其中发现了一个常见的错误，我想在这篇文章中讨论一些相关的细节。

如何不（！）去使用 `aria-selected`

所以让我们一起来看如下的例子：

<nav role="navigation" aria-label="Pagination Navigation">

  <ul>

    <li>

      <a href="/page-1" aria-label="Go to Page 1">1</a>

    </li>

    <li>

      <a href="/page-2" aria-label="Current Page, Page 2"

         aria-selected="true">2</a>

    </li>

    <li>

      <a href="/page-3" aria-label="Go to Page 3">3</a>

    </li>

  </ul>

</nav>

这个例子中的许多元素都用aria-label属性进行了适当的标记。这是一件好事，因为一个链接如果它只包含一段数字的话，它无法给盲人提供足够多的信息。对于盲人们来说，他们很难理解全是数字的链接背后的意义。

我想深入分析的是这第二个链接。它有一个aria-selected被设置成true.这是ARIA的一个缺陷—————它很容易被弄错。当你想要将正确的页面标记为selected时，用它似乎有意义，但事实上这样做并不对，对于像VoiceOver之类的屏幕朗读辅助器并不起作用。

为了理解为什么这样做是不行的，我们需要理解ARIA中角色（role）的概念。

ARIA中“link”及其含义

WAI-ARIA 角色模型是一种向辅助技术提供有关如何处理给定元素信息的方法。

在我们的例子中，我们在处理一个锚点元素（anchor），浏览器会自动将它与“link”相关联。标准的HTML元素通常有正确的角色关联。浏览器知道这些元素什么意思，并且能以最好最方便的方式对待它们。

标准的HTML元素能呈现包括适当的焦点处理、对键盘和点击交互的反应。

标准标记默认情况下是可以访问的.

所以，让我们看一下“link”的定义 :

对内部或者外部资源的交互式引用，在被点击的情况下，会导致用户代理导航到该资源。（An interactive reference to an internal or external resource that, when activated, causes the user agent to navigate to that resource.）

可能对你而言，这个定义中并没有什么新的东西，但是在它的右边，你会发现关于支持状态以及性能的信息，这通常是通过HTML属性来设置的。

使用这些你可以向辅助技术提供额外的信息。“link”的定义列出了一系列的ARIA属性，你可以使用像aria-label,aria-hidden或者aria-disabled等。

aria-selected 并不在其中。

那么，什么才是正确的用法呢？我们一起来看它的规范。

`aria-selected`的含义

aria-selected的定义包括:

此属性用于单选以及多选部件。（This attribute is used with single-selection and multiple-selection widgets.）

所以关于使用aria-selected必须有一些选择。

在处理选择时，我首先想到了选择元素以及单选按钮。另一方面，链接并不提供任何选择交互。

事实上一些“Pagination Navigation”（分页导航）内的链接在这个例子中并不起效。当你点击其中的一个链接通常是加载下一页，这种情况，这里的分页并没有真正的选择交互。

`aria-selected`的实际用例

aria-selected 支持许多的role，包括 "tab"，这对你来说可能是新的，但你我打赌你知道你从中期待什么。如果你看这个例子你将会看到“tab”的用法和aria-selected背后确切的推理。

<ul class="tablist" role="tablist">

  <li id="tab1" class="tab" aria-controls="panel1"

      aria-selected="true" role="tab" tabindex="0">Prices</li>

  <li id="tab2" class="tab" aria-controls="panel2"

      role="tab" aria-selected="false" tabindex="0">Features</li>

</ul>

这个例子展示了一个"tab component"（标签组件），它是由许多控制着可见的内容的列表项组成。这列表本身有“tablist”的role，并且每个列表项都有“tab”来确保辅助技术知道去处理什么。

列表项在被聚焦的状态下能对点击和键盘导航做出反应。这是通过tabindex以及一点Javascript。这个组件总体上是易访问的，并且为了向用户提供关于当前哪一个tab正被选择的附加信息，每一个tab的aria-selected属性都是被设定了的。屏幕阅读器现在已经能够识别出“selected”，因为它们能理解元素的“tab”属性。

还有更多的内容，这里我就不细展开了（你能在这个例子中找到解释），但是要建立标签的可访问性并不像一眼看上去的那样琐碎。

要记住最重要的事情，aria-selected 能给选择交互提供额外的信息像这个例子中当前的标签。

开发者工具来救援

正如你所见，处理WAI_ARIA是棘手的，但是幸好这里有许多解决的办法。例如，谷歌提供了一个非常漂亮的Chrome 拓展，这可以帮助你发现这样的错误。要检查你的网站，你可以在开发者工具中轻松运行辅助功能审核。

除了可访问性审核以外，这个拓展还通过可访问性面板扩大了元素检查。在那里你可以看一下应用的属性、角色，还可以看一下辅助技术是如何大声朗读出这个元素的。这确实很有帮助，实际上我经常使用它。

总结

可访问性处理起来可能比较麻烦，但是WAI_ARIA的规则值我们得去读，在使用了合适的工具后，我想我们可以使网站变得更易访问。

我希望你能喜欢这篇文章，如果你有什么问题欢迎你能告诉我。

编辑

结果，分页中当前页面例子的正确属性是WAIARIA 1.1中定义的 aria-current属性. 不幸的是，它在写的时没能很好的支持。