scaactk

对无障碍网页应用(ARIA)的选择

scaactk · 2016-12-15翻译 · 750阅读 原文链接

让网站对每个人都能访问是一件相当艰难的工作,尤其是在我们使用自定义标记解决方案(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)的概念。

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 拓展 ,这可以帮助你发现这样的错误。要检查你的网站,你可以在开发者工具中轻松运行辅助功能审核。

Developer tools showing errors in accessibility audit

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

Developer tools showing accessibility panel for element inspection

总结

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

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

编辑

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

译者scaactk尚未开通打赏功能

相关文章