Основы WAI-ARIA

该翻译不完整. 请帮助翻译本文英文

根据上一篇文章,有时很难创建包含非语义HTML和使用JavaScript动态更新内容的复杂UI元素. WAI-ARIA是一项可以通过添加额外的标记来帮助解决此类问题的技术,浏览器和辅助技术可以识别并使用这些标记来让用户知道发生了什么. 在这篇文章中我们展示了如何从根本上使用这项技术来改善可访问性.

必备知识: 基本的计算机知识,对HTML,CSS和JavaScript的基本理解, 对课程中上一篇文章的理解.
Цель: 探索WAI-ARIA,了解如何将该技术用于合并有用的附加语义以增加可访问性.

Что такое WAI-ARIA?

让我们先来看一下WAI-ARIA是什么以及它如何有用.

Новый набор проблем

由于Web应用程序变得更加复杂和动态,因此出现了新的可访问性功能和挑战.

例如,HTML5引入了许多语义元素,定义一般页面布局(<nav><footer> 等等.). 直到它们可用,开发人员只是使用<div>带有标识符或类<div class="nav">但这造成了问题,因为没有简单的方法可以通过编程方式找到页面的特定部分.

最初的解决方案是在页面顶部为导航链接(或其他内容)添加一个或多个隐藏链接,例如:

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

但这仍然不是很准确,只能在屏幕阅读器从页面顶部读取时使用.

作为另一个示例,应用程序开始使用复杂的控件,例如日期选择器字段,用于选择值的滑块等. HTML5提供了用于显示此类控件的特殊输入类型:

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

它们在不同的浏览器中没有很好地支持,并且很难设置样式,这使得它们对于与网站设计集成不是很有用.结果,开发人员经常使用JavaScript库来生成控件,例如嵌套序列<div>элементов или ячеек таблиц с именами классов, которые затем стилизуются с помощью CSS и управляют с помощью JavaScript.

这里的问题是,它们在视觉上可以正常工作,但屏幕阅读器根本无法理解它们的含义,并且只是告诉用户,他们可以看到杂乱无序的元素,无法描述它们的含义.

Enter WAI-ARIA

WAI-ARIA是由W3C编写的规范,定义了一组附加的HTML属性,可以将这些属性应用于元素以提供附加的语义并改善缺少的地方的可访问性. 规范中定义了三个主要功能:

  • 角色 -这些角色定义元素是什么或做什么. 其中许多是所谓的地标性角色,它们在很大程度上复制了HTML5结构元素的语义值,例如role="navigation"<nav> )或role="complementary"<aside> ),但也有其他描述在UI中常见的不同页面结构,例如role="banner"role="search"role="tabgroup"role="tab"等.
  • 属性 -这些属性定义元素的属性,可用于为其赋予额外的含义或语义. 例如, aria-required="true"指定需要填写表格输入才有效,而aria-labelledby="label"允许您在元素上放置一个ID,然后将其引用为标签页面上的其他任何内容(包括多个元素),使用<label for="input">都是不可能的. 例如,您可以使用aria-labelledby来指定<div>包含的键描述是多个表单元格的标签,或者可以将其用作图像替代文本的替代品-在页面上将现有信息指定为图片的替代文字,而不必在alt属性内重复. 您可以在" 替代文本"中看到一个示例.
  • 状态 —定义元素当前条件的特殊属性,例如aria-disabled="true" ,它向屏幕阅读器指定当前禁用了表单输入. 状态与属性的不同之处在于,属性不会在应用程序的整个生命周期中发生变化,而状态通常可以通过JavaScript以编程方式进行更改.

关于WAI-ARIA属性的重要一点是,除了浏览器的可访问性API公开的信息(屏幕阅读器从中获取信息)之外,它们不会影响网页的任何内容. 尽管该属性对于通过CSS选择元素很有用,但WAI-ARIA不会影响网页结构,DOM等.

注意 :在WAI-ARIA规范中,您可以找到所有ARIA角色及其用途的有用列表,以及指向更多信息的链接—请参阅"角色定义" .

该规范还包含所有属性和状态的列表,以及指向更多信息的链接—请参阅状态和属性的定义(所有aria- *属性) .

Where is WAI-ARIA supported?

这不是一个容易回答的问题. 很难找到一个确定的资源来说明支持WAI-ARIA的哪些功能以及在何处支持这些功能,因为:

  1. WAI-ARIA规范中有很多功能.
  2. 要考虑多种操作系统,浏览器和屏幕阅读器的组合.

最后一点很关键-首先要使用屏幕阅读器,您的操作系统需要运行具有适当辅助功能API的浏览器,以显示屏幕阅读器完成其工作所需的信息. 大多数流行的操作系统都具有一两个浏览器供屏幕阅读器使用. Paciello Group的文章很及时,为此提供了数据—请参阅" 粗糙指南:浏览器,操作系统和屏幕阅读器支持已更新" .

接下来,您需要担心所涉及的浏览器是否支持ARIA功能并通过其API公开它们,而且屏幕阅读器是否会识别该信息并将其以有用的方式呈现给用户.

  1. 浏览器支持通常是相当不错的–在撰写本文时, caniuse.com表示,全球对WAI-ARIA的浏览器支持约为88%.
  2. 屏幕阅读器对ARIA功能的支持还没有达到这个水平,但是最受欢迎的屏幕阅读器正在实现这一目标. 通过查看Powermapper的WAI-ARIA屏幕阅读器兼容性 文章,您可以了解支持级别.

在本文中,我们不会尝试涵盖每个WAI-ARIA功能及其确切的支持详细信息. 相反,我们将介绍最关键的WAI-ARIA功能,供您了解; 如果我们未提及任何支持详细信息,则可以假定该功能已得到很好的支持. 我们将明确提及任何例外情况.

注意 :一些JavaScript库支持WAI-ARIA,这意味着当它们生成复杂的表单控件之类的UI功能时,它们会添加ARIA属性以改善这些功能的可访问性. 如果您正在寻找用于快速UI开发的第三方JavaScript解决方案,那么在做出选择时,绝对应该考虑其UI小部件的可访问性. 很好的例子是jQuery UI(请参阅关于jQuery UI:深度可访问性支持 ), ExtJSDojo / Dijit .

When should you use 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. 动态内容更新 :屏幕阅读器往往难以报告不断变化的内容; 使用ARIA,我们可以使用aria-live来通知屏幕阅读器用户何时更新内容区域,例如通过XMLHttpRequestDOM API .
  3. 增强键盘的可访问性 :有些内置HTML元素具有本机键盘的可访问性. 当其他元素与JavaScript一起使用以模拟相似的交互时,键盘可访问性和屏幕阅读器报告会因此受到影响. 在不可避免的情况下,WAI-ARIA提供了一种使其他元素获得焦点的方法(使用tabindex ).
  4. 非语义控件的可访问性 :当使用一系列嵌套的<div>与CSS / JavaScript一起创建复杂的UI功能时,或者通过JavaScript大大增强/更改了本机控件时,可访问性可能会受到影响—屏幕阅读器用户将如果没有语义或其他线索,很难确定该功能的作用. 在这些情况下,ARIA可以通过结合诸如buttonlistboxtabgroup类的角色以及诸如aria-requiredaria-posinset来提供aria-posinset以提供有关功能的更多线索.

不过要记住一件事- 您仅在需要时才使用WAI-ARIA! 理想情况下,您应始终使用本机HTML功能来提供屏幕阅读器所需的语义,以告知其用户正在发生的事情. 有时这是不可能的,或者是因为您对代码的控制有限,或者是因为您正在创建复杂的东西,而没有简单的HTML元素来实现它. 在这种情况下,WAI-ARIA可以成为有价值的可访问性增强工具.

但是同样,仅在必要时使用它!

注意 :另外,请尝试确保与各种实际用户(非残障人士,使用屏幕阅读器的人,使用键盘导航的人)一起测试您的网站.与他们相比,他们将对您的网站运行状况有更好的见解.

Practical WAI-ARIA implementations

在下一节中,我们将更详细地研究这四个领域以及实际示例. 在继续之前,您应该已准备好屏幕阅读器测试设置,以便可以在阅读过程中测试一些示例.

有关更多信息,请参见我们的测试屏幕阅读器部分.

Signposts/Landmarks

WAI-ARIA将role属性添加到浏览器,这使您可以在需要的地方为网站上的元素添加额外的语义值. 第一个有用的主要领域是为屏幕阅读器提供信息,以便他们的用户可以找到通用的页面元素. 让我们看一个示例-我们的无网站示例( 实时观看 )具有以下结构:

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

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

<footer>...</footer>

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

  • <header>元素上-"横幅,2个项目"(它包含一个标题和<nav> ).
  • <nav>元素上-"导航2项"(它包含一个列表和一个表单).
  • <main>元素上-"主要2个项目"(包含一篇文章和一个旁述).
  • <aside>元素上-"补充2个项目"(包含标题和列表).
  • 在搜索表单输入中-"搜索查询,在文本开头插入".
  • <footer>元素上-"页脚1项目".

如果转到VoiceOver的地标菜单(使用VoiceOver键+ U,然后使用光标键在菜单选项之间循环访问),您会看到大多数元素都已列出,因此可以快速访问它们.

但是,我们可以在这里做得更好. 搜索表单是人们想要查找的一个非常重要的地标,但是它没有在地标菜单中列出,也没有被视为显着的地标,超出了实际输入作为搜索输入( <input type="search"> ). 此外,某些较旧的浏览器(最著名的是IE8)无法识别HTML5元素的语义.

让我们通过使用一些ARIA功能对其进行改进. 首先,我们将一些角色属性添加到我们的HTML结构中. 您可以尝试获取我们原始文件的副本(请参见index.htmlstyle.css ),或导航至我们的website-aria-roles示例( 请参见实时演示 ),其结构如下:

<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>元素赋予了aria-label属性,即使我们没有包含<label>元素. 在这种情况下,这非常有用-像这样的搜索表单是一种非常常见且易于识别的功能,添加视觉标签会破坏页面设计.

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

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

  • 在浏览页面时以及在"地标"菜单中,搜索表单都作为单独的项目被调用.
  • 突出显示表单输入时,将读出aria-label属性中包含的标签文本.

除此之外,旧版浏览器(例如IE8)的用户更有可能访问该网站; 为此,值得包括ARIA角色. 并且,由于某种原因,如果您的站点仅使用<div>构建,则您绝对应该包括ARIA角色来提供这些非常需要的语义!

搜索表单的改进语义已经显示出,当ARIA超出HTML5中可用的语义时,将有可能实现. 您将在下面看到更多有关这些语义以及ARIA属性/属性的功能的信息 ,特别是在" 非语义控件可访问性"部分. 现在,让我们看看ARIA如何帮助动态内容更新.

Dynamic content updates

可以使用屏幕阅读器轻松访问加载到DOM中的内容,从文本内容到附加到图像的替代文本. 因此,具有大量文本内容的传统静态网站易于为视力障碍者提供访问.

问题在于,现代的Web应用程序通常不只是静态文本,它们往往具有大量动态更新的内容,即无需通过XMLHttpRequestFetchDOM API等机制重新加载整个页面即可更新的内容. 这些有时被称为活动区域 .

让我们看一个简单的示例-看到aria-no-live.html (也可以看到它正在实时运行 ). 在此示例中,我们有一个简单的随机引号框:

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

我们的JavaScript通过XMLHttpRequest加载一个JSON文件,其中包含一系列随机引号及其作者. 完成此操作后,我们将启动setInterval()循环,该循环每10秒将新的随机报价加载到报价框中:

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

这样做可以,但是对可访问性不利.屏幕阅读器无法检测到内容更新,因此其用户将不知道发生了什么. 这是一个相当琐碎的示例,但请想象一下,如果您正在创建一个包含大量不断更新内容的复杂UI,例如聊天室,策略游戏UI或实时更新购物车显示,那么您将无法使用应用程序以任何有效的方式进行,而无需通过某种方式提醒用户更新.

幸运的是,WAI-ARIA提供了一种有用的机制来提供这些警报aria-live属性. 将其应用于元素会导致屏幕阅读器读出更新的内容. 读取内容的紧急程度取决于属性值:

  • off:默认. 更新不应该宣布.
  • polite :仅当用户空闲时,才应宣布更新.
  • assertive :应尽快向用户发布更新.

我们希望您复制一份aria-no-live.htmlquotes.json ,并如下更新您的<section>标记:

<section aria-live="assertive">

这将导致屏幕阅读器在内容更新时读出内容.

注意 :如果您尝试从file:// URL进行XMLHttpRequest调用,则大多数浏览器都会抛出安全异常,例如,如果您只是通过直接将文件加载到浏览器中(通过双击等)来加载文件. 要使其运行,您需要将其上传到Web服务器,例如使用GitHub或本地Web服务器(如Python的SimpleHTTPServer) .

这里还有一个额外的注意事项-仅读取更新的部分文本. 如果我们也总是读出标题,那就太好了,这样用户就可以记住正在读出的内容. 为此,我们可以将aria-atomic属性添加到该部分. 再次更新您的<section>标记,如下所示:

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

aria-atomic="true"属性告诉屏幕阅读器将整个元素的内容作为一个原子单位读出,而不仅仅是被更新的位.

注意 :您可以在aria-live.html上 看到完成的示例( 请参见实时运行 ).

注意aria-relevant属性对于控制在更新实时区域时读取的内容也非常有用. 例如,您只能读出内容添加或删除的内容.

Enhancing keyboard accessibility

正如该模块中其他一些地方所讨论的那样,HTML在辅助功能方面的主要优势之一是内置的键盘辅助功能,例如按钮,表单控件和链接. 通常,您可以使用Tab键在控件之间移动,使用Enter / Return键选择或激活控件,并根据需要偶尔使用其他控件(例如,上下光标在<select>框中的选项之间移动).

但是,有时您最终不得不编写使用非语义元素作为按钮(或其他类型的控件)的代码,或者出于不太正确的目的使用可聚焦控件的代码. 您可能正在尝试修复一些继承的错误代码,或者您可能正在构建某种需要它的复杂小部件.

在使非焦点代码可焦点化方面,WAI-ARIA用一些新值扩展了tabindex属性:

  • tabindex="0" -如上所述,此值允许通常不可标签的元素变为可标签的. 这是tabindex的最有用的值.
  • tabindex="-1" -这通常不允许可制表元素以编程方式接收焦点,例如通过JavaScript或作为链接目标.

我们对此进行了更详细的讨论,并在HTML可访问性文章中介绍了一种典型的实现-请参阅中的构建键盘可访问性 .

Accessibility of non-semantic controls

这是上一节的后续内容-当使用一系列嵌套的<div>与CSS / JavaScript一起创建复杂的UI功能,或者通过JavaScript大大增强/更改了本机控件时,不仅键盘可访问性会受到影响,但如果没有语义或其他线索,屏幕阅读器用户将很难确定该功能的作用. 在这种情况下,ARIA可以帮助提供那些缺少的语义.

Form validation and error alerts

首先,让我们重新看一下我们在CSS和JavaScript可访问性文章中首先看过的表单示例(请阅读保持不打扰的完整概述). 在本节的最后,我们表明我们在错误消息框中包含一些ARIA属性,当您尝试提交表单时出现验证错误时,该消息框中将出现:

<div class="errors" role="alert" aria-relevant="all">
  <ul>
  </ul>
</div>
  • role="alert"自动将其应用于的元素转换为活动区域,因此可以读出对其所做的更改; 它还在语义上将其标识为警报消息(重要的时间/上下文敏感信息),并且表示向用户传递警报的更好,更易用的方式(类似alert()调用的模式对话框存在许多可访问性问题;请参见弹出窗口Windows by WebAIM).
  • aria-relevantall指示屏幕阅读器在对其进行任何更改时(即,添加或删除错误时)读出错误列表的内容. 这很有用,因为用户不仅要知道列表中已添加或删除的错误,还希望知道还剩下什么错误.

我们可以进一步使用ARIA,并提供更多的验证帮助. 如何指出是否首先需要填写字段以及年龄应在什么范围内?

  1. 此时,请获取我们的form-validation.htmlvalidation.js文件的副本,并将其保存在本地目录中.
  2. 在文本编辑器中将它们打开,然后看一下代码的工作方式.
  3. 首先,在开始的<form>标记上方添加一个段落,就像下面的标记一样,并用星号标记两个<label>形式. 通常,这是我们标记可见用户的必填字段的方式.
    <p>Fields marked with an asterisk (*) are required.</p>
  4. 这具有视觉上的意义,但对于屏幕阅读器用户而言并不容易理解. 幸运的是,WAI-ARIA提供了aria-required属性,以向屏幕阅读器提供提示,告知他们应该告诉用户需要填写表格输入.更新<input>元素,如下所示:
    <input type="text" name="name" id="name" aria-required="true">
    
    <input type="number" name="age" id="age" aria-required="true">
  5. 如果您现在保存该示例并使用屏幕阅读器进行测试,则应该听到类似"输入您的名字,必须输入文字,编辑文本"之类的信息.
  6. 如果我们让屏幕阅读器用户和有视力的用户了解年龄值应该是有用的,这也可能很有用. 这通常作为工具提示或占位符出现在表单字段中. WAI-ARIA确实包含aria-valueminaria-valuemax属性以指定最小值和最大值,但是目前似乎并没有很好的支持. 更好地支持的功能是HTML5 placeholder属性,该属性可以包含一条消息,当未输入任何值时,该消息将显示在输入中,并由许多屏幕阅读器读取. 像这样更新您的号码输入:
    <input type="number" name="age" id="age" placeholder="Enter 1 to 150" aria-required="true">

注意 :您可以在form-validation-updated.html上实时查看完成的示例.

除了经典的<label>元素之外,WAI-ARIA还启用了一些高级表单标签技术. 我们已经讨论过使用aria-label属性来提供标签,而我们不希望该标签对有视力的用户可见(请参见上方的" 路标/地标"部分). 还有其他一些使用其他属性的标签技术,例如aria-labelledby如果您要将非<label>元素指定为标签或使用同一标签来标记多个表单输入),以及aria-describedby (如果要关联)带有表单输入的其他信息,并使其读出. 有关更多详细信息,请参见WebAIM的"高级表单标签"文章 .

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

如果输入的禁用状态可能会发生变化,那么最好指出输入发生的时间以及结果是什么. 例如,在我们的form-validation-checkbox-disabled.html演示中,有一个复选框,当选中该复选框时,它将启用另一个表单输入以允许输入更多信息. 我们设置了一个隐藏的实时区域:

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

使用绝对定位将其隐藏在视图中. 选中/取消选中此复选框时,我们将更新隐藏活动区域内的文本,以告知屏幕阅读器用户选中此复选框的结果,并更新aria-disabled状态以及一些视觉指示器:

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来重新添加键盘可访问性,而在很多情况下都不会造成太大麻烦.

但是屏幕阅读器呢? 他们仍然不会将元素视为按钮. 如果我们在屏幕阅读器中测试fake-div-buttons.html示例,则将使用" Click me !, group"之类的短语来报告我们的假按钮,这显然很令人困惑.

我们可以使用WAI-ARIA角色解决此问题. 制作一个本地的fake-div-buttons.html副本,并在每个按钮<div>添加role="button" ,例如:

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

现在,当您使用屏幕阅读器尝试进行此操作时,将使用"点击我!,按钮"之类的短语来报告按钮-更好.

注意 :但是不要忘记,尽可能使用正确的语义元素总是更好. 如果要创建按钮并可以使用<button>元素,则应使用<button>元素!

Guiding users through complex widgets

还有其他一大堆的角色 ,它可以识别非语义元素结构为常见的UI功能,超越什么是标准的HTML中可用,例如comboboxslidertabpaneltree . 您可以在Deque大学代码库中看到许多有用的示例,以使您了解如何使此类控件可访问.

让我们来看一个自己的例子. 我们将返回到简单的绝对定位的选项卡式界面(请参见CSS和JavaScript可访问性文章中的隐藏内容 ),您可以在" 选项卡式"信息框示例 (请参见源代码 )中找到它.

就键盘可访问性而言,此示例按原样可以正常工作-您可以在不同的标签之间愉快地使用标签,然后选择它们以显示标签内容. 它也很容易访问-您可以滚动浏览内容并使用标题导航,即使您看不到屏幕上正在发生的事情. 但是,内容到底是什么还不是很明显-屏幕阅读器当前将内容报告为链接列表,并且某些内容带有三个标题. 它不会让您知道内容之间的关系. 向用户提供有关内容结构的更多线索总是好的.

为了改善这一点,我们创建了该示例的新版本,称为aria-tabbed-info-box.html请参见实时运行 ). 我们已经更新了选项卡式界面的结构,如下所示:

<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>

注意 :此处最引人注目的变化是,我们删除了示例中原来存在的链接,而只是将列表项用作选项卡-之所以这样做,是因为它使屏幕阅读器用户不那么困惑(链接不会t真的可以带您到任何地方;它们只是改变视图),它可以使set功能中的setsize /位置更好地工作-将这些功能放置在链接上后,浏览器一直在报告" 1之1",而不是" 1 of 3"," 2 of 3"等

新功能如下:

  • 新角色tablisttabtabpanel这些标识了选项卡式界面的重要区域-选项卡的容器,选项卡本身以及相应的选项卡面板.
  • aria-selected —定义当前选择的选项卡. 由于用户选择了不同的选项卡,因此通过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" -删除链接后,我们需要为列表项提供此属性,以使其具有键盘焦点.
  • aria-setsize此属性使您可以向aria-setsize指定元素是系列的一部分,以及该系列具有多少项.
  • aria-posinset此属性允许您指定元素在系列中的哪个位置.与aria-setsize ,它向aria-setsize提供足够的信息,以告诉您您当前处于项目" 3之1"中, aria-setsize .在许多情况下,浏览器应该能够从元素层次结构中推断出此信息,但是它无疑有助于提供更多线索.

在我们的测试中,这种新结构确实可以改善整体状况. 现在,这些选项卡被识别为选项卡(例如,屏幕阅读器说出"选项卡"),通过用选项卡名称读出"已选择"来指示所选的选项卡,并且屏幕阅读器还会告诉您当前正在使用的选项卡编号. 此外,由于具有aria-hidden设置(只有非隐藏选项卡设置了aria-hidden="false" ),所以非隐藏内容是唯一可以导航到的内容,这意味着所选内容更加容易找到.

Note: If there is anything you explicitly don't want screen readers to read out, you can give them the aria-hidden="true"  attribute.

Summary

本文决不会涵盖WAI-ARIA中所有可用的内容,但它应该已经为您提供了足够的信息来理解如何使用它,并且知道您将遇到需要它的一些最常见的模式.

See also

  • Definition of Roles — ARIA roles reference.
  • 状态和属性的定义(所有aria- *属性) -属性和状态参考.
  • Deque大学代码库 -一个非常有用的实际示例库,显示了使用WAI-ARIA功能可访问的复杂UI控件.
  • WAI-ARIA创作实践 —来自W3C的非常详细的设计模式,解释了如何实现不同类型的复杂UI控件,同时使它们可以使用WAI-ARIA功能进行访问.
  • HTML中的ARIA —一种W3C规范,它为每个HTML功能定义了浏览器隐式设置的该功能的哪些可访问性(ARIA)语义,以及如果需要其他语义时可以对其设置的WAI-ARIA功能.

В этом модуле