对无障碍网页应用（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属性. 不幸的是，它在写的时没能很好的支持。
