免责声明:

本文档是 W3C工作备忘 1.1 的中文翻译。

由于翻译者的局限性,翻译可能存在不准确之处,本翻译内容仅做为参考,若有争议应以原始英文版本为官方权威版本,原始英文版本地址: WAI-ARIA Authoring Practices 1.1

译者:

李文举(jace li)、 练小习(jiraa)、秧歌(yang)、蒸包(zhengbao)、考拉(cola) (排名不分先后)

校对:

信息无障碍研究会

This document provides readers with an understanding of how to use WAI-ARIA 1.1 [[WAI-ARIA]] to create accessible rich internet applications. It describes considerations that might not be evident to most authors from the WAI-ARIA specification alone and recommends approaches to make widgets, navigation, and behaviors accessible using WAI-ARIA roles, states, and properties. This document is directed primarily to Web application developers, but the guidance is also useful for user agent and assistive technology developers.

This document is part of the WAI-ARIA suite described in the WAI-ARIA Overview.

This is an editor's draft by the Accessible Rich Internet Applications Working Group of the Web Accessibility Initiative. It supports the WAI-ARIA 1.1 [WAI-ARIA] specification, providing detailed advice and examples beyond what would be appropriate to a technical specification but which are important to understand the specification.

This draft includes only a portion of content planned for WAI-ARIA Authoring Practices 1.1. To see plans for the complete guide, review the Authoring Practices Milestone Plan.

Feedback on the information provided here is essential to the ultimate success of Rich Internet Applications that afford full access to their information and operations. The Accessible Rich Internet Applications Working Group asks in particular:

To comment, file an issue in the W3C ARIA Practices GitHub repository, or if that is not possible, send email to public-aria@w3.org (comment archive).

Introduction

This section is informative.

WAI-ARIA Authoring Practices is a guide for understanding how to use WAI-ARIA 1.1 to create an accessible Rich Internet Application. It provides guidance on the appropriate application of WAI-ARIA, describes recommended WAI-ARIA usage patterns, and explains concepts behind them.

Languages used to create rich and dynamic web sites, e.g., HTML, JavaScript, CSS, and SVG, do not natively include all the features required to make sites usable by people who use assistive technologies (AT) or who rely on keyboard navigation. The W3C Web Accessibility Initiative's (WAI) Accessible Rich Internet Applications working group (ARIA WG) is addressing these deficiencies through several W3C standards efforts. The WAI-ARIA Overview provides additional background on WAI-ARIA, summarizes those efforts, and lists the other documents included in the WAI-ARIA suite.

After a brief Read Me First section, the guide begins with ARIA implementation patterns for common widgets that both enumerate expected behaviors and demonstrate those behaviors with working code. The implementation patterns and examples refer to detailed explanations of supporting concepts in subsequent guidance sections. The guidance sections cover more general topics such as use of ARIA landmarks, practices for keyboard interfaces, grid and table properties, and the effects of role presentation.

Read Me First

No ARIA is better than Bad ARIA

Functionally, ARIA roles, states, and properties are analogous to a CSS for assistive technologies. For screen reader users, ARIA controls the rendering of their non-visual experience. Incorrect ARIA misrepresents visual experiences, with potentially devastating effects on their corresponding non-visual experiences.

Before using ARIA or any of the guidance in this document, please take time to understand the following two essential principles.

Principal 1: A role is a promise

This code:


        <div role="button">Place Order</div>
           

Is a promise that the author of that <div> has also incorporated JavaScript that provides the keyboard interactions expected for a button. Unlike HTML input elements, ARIA roles do not cause browsers to provide keyboard behaviors or styling.

Using a role without fulfilling the promise of that role is similar to making a "Place Order" button that abandons an order and empties the shopping cart.

One of the objectives of this guide is to define expected behaviors for each ARIA role.

Principle 2: ARIA Can Both Cloak and Enhance, Creating Both Power and Danger

The information assistive technologies need about the meaning and purpose of user interface elements is called accessibility semantics. From the perspective of assistive technologies, ARIA gives authors the ability to dress up HTML and SVG elements with critical accessibility semantics that the assistive technologies would not otherwise be able to reliably derive.

Some of ARIA is like a cloak; it covers up, or overrides, the original semantics or content.


        <a role="menuitem">Assistive tech users perceive this element as an item in a menu, not a link.</a>
        <a aria-label="Assistive tech users can only perceive the contents of this aria-label, not the link text">Link Text</a>

On the other hand, some uses of ARIA are more like suspenders or belts; they add meaning that provides essential support to the original content.


        <button aria-pressed="false">Mute</button>
      

This is the power of ARIA. It enables authors to describe nearly any user interface component in ways that assistive technologies can reliably interpret, thus making components accessible to assistive technology users.

This is also the danger of ARIA. Authors can inadvertently override accessibility semantics.

        
          <table role="log">
            <!--
              Table that assistive technology users will not perceive as a table.
              The log role tells browser this is a log, not a table.
            -->
          </table>
          <ul role="navigation">
            <!-- This is a navigation region, not a list. -->
            <li><a href="uri1">nav link 1</li>
            <li><a href="uri2">nav link 2</li>
            <!-- ERROR! Previous list items are not in a list! -->
          </ul>
        
      

Browser and Assistive Technology Support

Testing assistive technology interoperability is essential before using code from this guide in production. Because the purpose of this guide is to illustrate appropriate use of ARIA 1.1 as defined in the ARIA specification, the design patterns, reference examples, and sample code intentionally do not describe and implement coding techniques for working around problems caused by gaps in support for ARIA 1.1 in browsers and assistive technologies. It is thus advisable to test implementations thoroughly with each browser and assistive technology combination that is relevant within a target audience.

Similarly, JavaScript and CSS in this guide is written to be compatible with the most recent version of Chrome, Firefox, Internet Explorer, and Safari at the time of writing. In particular, some JavaScript and CSS may not function correctly in Internet Explorer version 10 or earlier.

Except in cases where the ARIA Working Group and other contributors have overlooked an error, examples in this guide that do not function well in a particular browser or with a specific assistive technology are demonstrating browser or assistive technology bugs. Browser and assistive technology developers can thus utilize code in this guide to help assess the quality of their support for ARIA 1.1.

Mobile and Touch Support

Currently, this guide does not indicate which examples are compatible with mobile browsers or touch interfaces. While some of the examples include specific features that enhance mobile and touch support, some ARIA features are not supported in any mobile browser. In addition, there is not yet a standardized approach for providing touch interactions that work across mobile browsers.

More guidance about touch and mobile support is planned for future releases of the guide.

Design Patterns and Widgets

This section demonstrates how to make common rich internet application patterns and widgets accessible by applying WAI-ARIA roles, states, and properties and implementing keyboard support.

手风琴(有展开/折叠功能的模块)

手风琴是个垂直罗列的元素组合,例如标签或缩略图,这允许用户切换内容模块的展示。每个标签元素可以被用来展开折叠、暴露隐藏其相关内容。手风琴一般被用来减少页面滚动,当在单个页面中呈现很多内容模块时。

通过以下术语来理解手风琴:

手风琴标题:
呈现内容模块的标签或缩略图,同时也用来展开内容,在某些实现中,也用来隐藏内容模块。
手风琴面板:
与手风琴标题相关联的内容

在某些手风琴中,总会有其他元素与手风琴标题视觉临近。例如,每个手风琴标题都伴随一个菜单按钮来提供每个模块的访问操作。而且,在某些案例中,隐藏内容的标识可能具有一样的视觉特性。

示例

手风琴示例:演示把一个表单分成三部分,并使用手风琴导航一次展开其中一部分

键盘交互

  • EnterSpace:
    • 当焦点在折叠状态的手风琴标题上,使用Enter或Space键可以展开相关联面板。如果实现只允许一个面板被展开,如果另一个面板被展开,折叠这个面板。
    • 当焦点在展开状态的手风琴标题上,如果实现支持折叠,折叠该面板。某些实现总是只有一个面板展开,并且只允许一个面板展开,这样,他们不需要支持折叠功能。
  • Down Arrow (可选地): 如果焦点在一个手风琴标题上,使用下光标可将焦点移动到下一个手风琴标题上。如果焦点在最后一个手风琴标题上,不响应下光标的操作或将焦点移动到手风琴的第一个标题。
  • Up Arrow (可选地): 如果焦点在一个手风琴标题上,使用上光标键可将焦点移动到下一个手风琴标题上,不响应下光标的操作或将焦点移动到手风琴的最后一个标题。
  • Home (可选地): 当焦点在手风琴的标题,将焦点移到手风琴的第一个标题
  • End (可选地): 当焦点在手风琴的标题,将焦点移动到手风琴最后一个标题
  • Control + Page Down (可选地): 如果焦点在手风琴面板内,将焦点移动到面板标题上。如果焦点在手风琴标题上,将焦点移动到前一个手风琴标题。如果焦点在第一个手风琴标题上,不响应Control + Page Up或将焦点移动到手风琴的最后一个标题。
  • Control + Page Up (可选地): 如果焦点在手风琴面板内,将焦点移动到该面板的标题。如果焦点在手风琴标题,将焦点移动到手风琴前一个标题。如果焦点在第一个手风琴标题,允许不响应操作或将焦点移动到手风琴的最后一个标题

WAI-ARIA 角色,状态和属性:

  • 每个手风琴标题包含在一个角色为 button 的元素内。
  • 每个手风琴标题 button 都被具有 heading 角色的元素包裹,且该元素设置了合适的 aria-level 值,适配页面的信息架构。
    • 如果原生语言具有默认 headingaria-level 元素,例如HTML标题标签,可以使用原生语言元素。
    • button 元素是 heading 元素内的唯一元素。也就是说,如果有其他视觉一致性元素,他们不能被包含在 heading 元素中。
  • 如果与手风琴标题关联的手风琴面板是展开的,标题的 button 元素的 aria-expanded 属性设置为 true。如果面板折叠的,aria-expanded 属性设置为 false
  • 手风琴标题的 button 元素 aria-controls 设置为包含手风琴面板的内容元素的ID。
  • 如果与手风琴标题关联的手风琴面板是展开的,如果不允许该面板折叠,那标题的 button 元素的 aria-disabled 设置为 true
  • 可选地,每个面板容器的元素,都有 region 角色,且使用 aria-labelledby值索引控制面板呈现的按钮。
    • 避免在创建路标 region 扩展的情况下,使用region角色,例如在一个包含超过6个面板的手风琴中,可能会同时展开。
    • 当面板包含标题元素或嵌套手风琴时,region 角色对屏幕阅读器用户对于结构的感知特别有帮助。

Alert

alert 是一个呈现简短、重要信息的元素,以一种引起用户注意而不打断用户任务的方式。动态渲染的警告,会被大多数屏幕阅读器自动朗读,在某些操作系统中,警告会触发警告提示音。与此同时,需要注意的是屏幕阅读器不会告知用户在加载完成前已经存在的警告。

因为警告是用来提供重要和潜在的时间敏感信息,而不会打扰用户继续工作,重要的一点是它不会影响键盘焦点。警告框 为那些必须打断工作流的情况设计的。

同样重要的是,避免设计自动消失的警告。一个消失太快的警告,可能导致不符合 WCAG 2.0 success criterion 2.2.3。另一个重要的设计考虑是警告引起的终端频率。频繁打断会降低视障和认知障碍用户的可用性,这让满足 WCAG 2.0 success criterion 2.2.4 的需求更加困难。

示例

警告框示例

Keyboard Interaction

一个警告框(WAI-ARIA 活动区域)不需要任何键盘交互。

WAI-ARIA 角色,状态和属性

该组件的角色为 alert

警告和消息对话框

一个警告对话框是一个 模态对话框,可中断用户的工作流程,以传达一个重要的信息,并获得响应。包含操作确认提示和错误消息确认。 alertdialog 角色能够让辅助技术和浏览器从其他对话框中区分出警告对话框,这样就能给予警告对话框特殊对待,例如播放一个系统警告提示音。

示例

issue 101 是这个模式的一个正在开发的实现案例。

键盘交互

请参阅 modal dialog pattern键盘交互部分。

WAI-ARIA 角色,状态和属性

  • 包含对话框所有元素的元素,包括警告信息和任何对话框按钮,具有 alertdialog 角色。
  • 角色设置为 alertdialog 的元素拥有以下情况中的一种:
    • 如果对话框具有一个可见标题,具有一个 aria-labelledby 索引包含具有对话框标题的元素。
    • aria-label 的值,如果对话框没有可见的标题。
  • 角色为 alertdialog 的元素,具有 aria-describedby 属性来索引包含警告信息的元素。

按钮

button是一个组件,能够让用户触发一个操作或事件,例如提交一个表单、打开一个对话框、取消操作、或执行删除操作。告知用户一个按钮会打开对话框的惯用方法是将“...”(省略号)添加到按钮上,例如“另存为...”。

除了常规按钮组件外,WAI-ARIA还支持其他2种按钮类型:

按钮执行的动作类型与链接的功能截然不同 (参见 link pattern)。组件的外观和角色与其提供的功能相匹配,这非常重要。但是,偶尔某些元素会有链接的视觉样式,却执行按钮的操作。在这种情况下,为元素添加 button 角色,可以帮助辅助技术用户理解元素的功能。但是,更好的解决方案是调整其视觉设计,以匹配其功能和ARIA角色。

示例

Button 示例: 将可点击的HTML divspan 元素作为可访问命令和切换按钮的示例。

键盘互动

当按钮有焦点时:

  • Space: 激活按钮.
  • Enter: 激活按钮.
  • 按钮激活后,根据按钮的操作类型设置焦点。例如:
    • 如果激活按钮打开一个对话框,焦点将移动到对话框内。(见 dialog pattern
    • 如果激活按钮会关闭一个对话框,焦点通常会返回到打开该对话框的按钮上,除非该对话框执行的功能会遵从上下文的逻辑,去到一个不同的元素。例如,激活对话框中的取消按钮将焦点返回到打开对话框的按钮。但是,如果对话框是确认删除其来自页面的操作,焦点将会根据逻辑移动到一个新的上下文。
    • 如果激活按钮不会关闭当前上下文,按钮激活后,焦点仍停留在该按钮上,例如,一个应用或重新计算的按钮。
    • 如果按钮操作会导致上下文变更,例如,转到向导中的下一步,或添加其他搜索条件,此时,可以将焦点移动到新操作的起点。
    • 如果使用快捷键激活按钮,焦点通常保留在激活快捷键的上下文中。例如,如果把快捷键Alt + U分配给“向上”按钮,该按钮会将当前聚焦的列表项目移动到列表中的较高位置,当焦点在列表中时, 按Alt + U 不会将焦点移出列表。

WAI-ARIA角色,状态和属性

  • 按钮具有的角色 button
  • button 有一个可访问的标签默认情况下,可访问名称是从按钮元素内部的所有内容计算得来。但是,无障碍名称也可以使用aria-describedby或aria-label提供。而且,它也可以通过 aria-labelledby"aria-label
  • 如果按钮有功能描述,则将按钮元素的aria-describedby 的值设置为包含描述的元素的ID。
  • 当与按钮相关联的动作不可用时,该按钮的aria-disabled 设置为 true
  • 如果按钮是一个切换按钮,则其具有 aria-pressed s状态属性。当按钮被打开时,该状态属性的值为 true,当被关闭时,该状态属性的值为 false

复选框

WAI-ARIA支持两种类型的 checkbox

  1. 双态: 最常见的复选框类型,它允许用户在两个状态间切换——选中、未选中.
  2. 三态: 这种类型的复选框支持额外的第三种状态 - 部分选中.

三态复选框的一种常见使用场景是在软件安装时,一个单独的三态复选框用来代表和控制整个安装选项组的状态。并且,该组中的每个选项都可以单独使用双态复选框开启或关闭。

用户仅使用一个操作,就可以改变三态复选框组中所有选项的状态:

示例

键盘交互

当复选框拥有焦点时, 按 Space 键来改变复选框的状态

WAI-ARIA角色,状态和属性

  • 复选框有角色(role) checkbox.
  • 复选框具有可访问标签,最好的方式是使用aria-labelledby关联可见标签:
    • Visible text content contained within the element with role checkbox.
    • A visible label referenced by the value of aria-labelledby set on the element with role checkbox.
    • aria-label set on the element with role checkbox.
  • 选中后,复选框元素状态 aria-checked 设置为 true.
  • 如果未选中,它的状态 aria-checked 设置为false.
  • 当部分选中,它的状态 aria-checked 设置为 mixed.
  • 如果使用一个可见标签可将一组复选框标识为一个逻辑组,这些复选框应该被包含在一个具有 group 角色的元素中,且该元素的 aria-labelledby设置为包含标签的元素的ID。
  • 如果复选框或复选框组包括额外的相关联静态描述文案,复选框或复选框组的属性aria-describedby 设置为包含描述元素的ID。

Combo Box

A combobox is a widget made up of the combination of two distinct elements: 1) a single-line textbox, and 2) an associated pop-up element for helping users set the value of the textbox. The popup may be a listbox, grid, tree, or dialog. Many implementations also include a third optional element -- a graphical button adjacent to the textbox, indicating the availability of the popup. Activating the button displays the popup if suggestions are available.

The popup is hidden by default, and the conditions that trigger its display are specific to each implementation. Some possible popup display conditions include:

Combobox widgets are useful for setting the value of a single-line textbox in one of two types of scenarios:

  1. The value for the textbox must be chosen from a predefined set of allowed values, e.g., a location field must contain a valid location name. Note that the listbox and menu button patterns are also useful in this scenario; differences between combobox and alternative patterns are described below.
  2. The textbox may contain any arbitrary value, but it is advantageous to suggest possible values to the user, e.g., a search field may suggest similar or previous searches to save the user time.

The nature of the suggested values and the way the suggestions are presented is called the autocomplete behavior. Comboboxes can have one of four forms of autocomplete:

  1. No autocomplete: When the popup is triggered, the suggested values it contains are the same regardless of the characters typed in the textbox. For example, the popup suggests a set of recently entered values, and the suggestions do not change as the user types.
  2. List autocomplete with manual selection: When the popup is triggered, it presents suggested values that complete or logically correspond to the characters typed in the textbox. The character string the user has typed will become the value of the textbox unless the user selects a value in the popup.
  3. List autocomplete with automatic selection: When the popup is triggered, it presents suggested values that complete or logically correspond to the characters typed in the textbox, and the first suggestion is automatically highlighted as selected. The automatically selected suggestion becomes the value of the textbox when the combobox loses focus unless the user chooses a different suggestion or changes the character string in the textbox.
  4. List with inline autocomplete: This is the same as list with automatic selection with one additional feature. The portion of the selected suggestion that has not been typed by the user, a completion string, appears inline after the input cursor in the textbox. The inline completion string is visually highlighted and has a selected state.

With any form of list autocomplete, the popup may appear and disappear as the user types. For example, if the user types a two character string that triggers five suggestions to be displayed but then types a third character that forms a string that does not have any matching suggestions, the popup may close and, if present, the inline completion string disappears.

When constructing a widget that is both visually compact and enables users to choose one value from a set of discrete values, often either a listbox or menu button is simpler to implement and use. One feature of combobox that distinguishes it from both listbox and menu button is that the value of the combobox is presented in an edit field. Thus, the combobox gives users one function that both listbox and menu button lack, namely the ability to select some or all of the value for copying to the clipboard. One feature that distinguishes both combobox and menu button widgets from listbox widgets is their ability to provide an undo mechanism. In many implementations, users can navigate the set of allowed values in a combobox or menu and then decide to revert to the value the widget had before navigating by pressing escape. In contrast, navigating a listbox immediately changes its value, and escape does not provide an undo mechanism.

The options for a combobox to popup a grid, tree, or dialog were introduced in ARIA 1.1. Changes made in the ARIA 1.1 specification also add support for a code pattern that enables assistive technologies to present the textbox and popup as separately perceivable elements. both ARIA 1.0 and 1.1 patterns are described in the following sections. While using the ARIA 1.1 pattern is recommended as soon as assistive technology support is sufficient, there are no plans to deprecate the ARIA 1.0 pattern.

Examples

Keyboard Interaction

  • Tab: The textbox is in the page Tab sequence.
  • Note: The popup indicator icon or button (if present), the popup, and the popup descendants are excluded from the page Tab sequence.
Textbox Keyboard Interaction

When focus is in the textbox:

  • Down Arrow: If the popup is available, moves focus into the popup:
    • If the autocomplete behavior automatically selected a suggestion before Down Arrow was pressed, focus is placed on the suggestion following the automatically selected suggestion.
    • Otherwise, places focus on the first focusable element in the popup.
  • Up Arrow (Optional): If the popup is available, places focus on the last focusable element in the popup.
  • Escape: Dismisses the popup if it is visible. Optionally, clears the textbox.
  • Enter: If an autocomplete suggestion is automatically selected, accepts the suggestion either by placing the input cursor at the end of the accepted value in the textbox or by performing a default action on the value. For example, in a messaging application, the default action may be to add the accepted value to a list of message recipients and then clear the textbox so the user can add another recipient.
  • Printable Characters: Type characters in the textbox. Note that some implementations may regard certain characters as invalid and prevent their input.
  • Standard single line text editing keys appropriate for the device platform (see note below).
  • Alt + Down Arrow (Optional): If the popup is available but not displayed, displays the popup without moving focus.
  • Alt + Up Arrow (Optional): If the popup is displayed:
    1. If the popup contains focus, returns focus to the textbox.
    2. Closes the popup.

Standard single line text editing keys appropriate for the device platform:

  1. include keys for input, cursor movement, selection, and text manipulation.
  2. Standard key assignments for editing functions depend on the device operating system.
  3. The most robust approach for providing text editing functions is to rely on browsers, which supply them for HTML inputs with type text and for elements with the contenteditable HTML attribute.
  4. IMPORTANT: Be sure that JavaScript does not interfere with browser-provided text editing functions by capturing key events for the keys used to perform them.
Listbox Popup Keyboard Interaction

When focus is in a listbox popup:

  • Enter: Accepts the focused option in the listbox by closing the popup and placing the accepted value in the textbox with the input cursor at the end of the value.
  • Escape: Closes the popup and returns focus to the textbox. Optionally, clears the contents of the textbox.
  • Right Arrow: Returns focus to the textbox without closing the popup and moves the input cursor one character to the right. If the input cursor is on the right-most character, the cursor does not move.
  • Left Arrow: Returns focus to the textbox without closing the popup and moves the input cursor one character to the left. If the input cursor is on the left-most character, the cursor does not move.
  • Any printable character: Returns the focus to the textbox without closing the popup and types the character.
  • Backspace (Optional): Returns focus to the textbox and deletes the character prior to the cursor.
  • Delete (Optional): Returns focus to the textbox, removes the selected state if a suggestion was selected, and removes the inline autocomplete string if present.
  • Down Arrow: Moves focus to and selects the next option. If focus is on the last option, either returns focus to the textbox or does nothing.
  • Up Arrow: Moves focus to and selects the previous option. If focus is on the first option, either returns focus to the textbox or does nothing.
  • Home (Optional): Either moves focus to and selects the first option or returns focus to the textbox and places the cursor on the first character.
  • End (Optional): Either moves focus to the last option or returns focus to the textbox and places the cursor after the last character.
  1. DOM Focus is maintained on the combobox textbox and the assistive technology focus is moved within the listbox using aria-activedescendant as described in Managing Focus in Composites Using aria-activedescendant.
  2. Selection follows focus in the listbox; the listbox allows only one suggested value to be selected at a time for the textbox value.
Grid Popup Keyboard Interaction

In a grid popup, each suggested value may be represented by either a single cell or an entire row. See notes below for how this aspect of grid design effects the keyboard interaction design and the way that selection moves in response to focus movements.

  • Enter: Accepts the currently selected suggested value by closing the popup and placing the selected value in the textbox with the input cursor at the end of the value.
  • Escape: Closes the popup and returns focus to the textbox. Optionally, clears the contents of the textbox.
  • Any printable character: Returns the focus to the textbox without closing the popup and types the character.
  • Backspace (Optional): Returns focus to the textbox and deletes the character prior to the cursor.
  • Delete (Optional): Returns focus to the textbox, removes the selected state if a suggestion was selected, and removes the inline autocomplete string if present.
  • Right Arrow: Moves focus one cell to the right. Optionally, if focus is on the right-most cell in the row, focus may move to the first cell in the following row. If focus is on the last cell in the grid, either does nothing or returns focus to the textbox.
  • Left Arrow: Moves focus one cell to the left. Optionally, if focus is on the left-most cell in the row, focus may move to the last cell in the previous row. If focus is on the first cell in the grid, either does nothing or returns focus to the textbox.
  • Down Arrow: Moves focus one cell down. If focus is in the last row of the grid, either does nothing or returns focus to the textbox.
  • Up Arrow: Moves focus one cell up. If focus is in the first row of the grid, either does nothing or returns focus to the textbox.
  • Page Down (Optional): Moves focus down an author-determined number of rows, typically scrolling so the bottom row in the currently visible set of rows becomes one of the first visible rows. If focus is in the last row of the grid, focus does not move.
  • Page Up (Optional): Moves focus up an author-determined number of rows, typically scrolling so the top row in the currently visible set of rows becomes one of the last visible rows. If focus is in the first row of the grid, focus does not move.
  • Home (Optional): Either:
    • Moves focus to the first cell in the row that contains focus. Or, if the grid has fewer than three cells per row or multiple suggested values per row, focus may move to the first cell in the grid.
    • Returns focus to the textbox and places the cursor on the first character.
  • End (Optional): Either:
    • Moves focus to the last cell in the row that contains focus. Or, if the grid has fewer than three cells per row or multiple suggested values per row, focus may move to the last cell in the grid.
    • Returns focus to the textbox and places the cursor after the last character.
  • Control + Home (optional): moves focus to the first row.
  • Control + End (Optional): moves focus to the last row.
  1. DOM Focus is maintained on the combobox textbox and the assistive technology focus is moved within the grid using aria-activedescendant as described in Managing Focus in Composites Using aria-activedescendant.
  2. The grid allows only one suggested value to be selected at a time for the textbox value.
  3. In a grid popup, each suggested value may be represented by either a single cell or an entire row. This aspect of design effects focus and selection movement:
    1. If every cell contains a different suggested value:
      • Selection follows focus so that the cell containing focus is selected.
      • Horizontal arrow key navigation typically wraps from one row to another.
      • Vertical arrow key navigation typically wraps from one column to another.
    2. If all cells in a row contain information about the same suggested value:
      • Either the row containing focus is selected or a cell containing a suggested value is selected when any cell in the same row contains focus.
      • Horizontal key navigation may wrap from one row to another.
      • Vertical arrow key navigation does not wrap from one column to another.
Tree Popup Keyboard Interaction

In some implementations of tree popups, some or all parent nodes may serve as suggestion category labels so may not be selectable values. See notes below for how this aspect of the design effects the way selection moves in response to focus movements.

When focus is in a vertically oriented tree popup:

  • Enter: Accepts the currently selected suggested value by closing the popup and placing the selected value in the textbox with the input cursor at the end of the value.
  • Escape: Closes the popup and returns focus to the textbox. Optionally, clears the contents of the textbox.
  • Any printable character: Returns the focus to the textbox without closing the popup and types the character.
  • Right arrow:
    • When focus is on a closed node, opens the node; focus and selection do not move.
    • When focus is on a open node, moves focus to the first child node and selects it if it is selectable.
    • When focus is on an end node, does nothing.
  • Left arrow:
    • When focus is on an open node, closes the node.
    • When focus is on a child node that is also either an end node or a closed node, moves focus to its parent node and selects it if it is selectable.
    • When focus is on a root node that is also either an end node or a closed node, does nothing.
  • Down Arrow: Moves focus to the next node that is focusable without opening or closing a node and selects it if it is selectable.
  • Up Arrow: Moves focus to the previous node that is focusable without opening or closing a node and selects it if it is selectable.
  • Home: Moves focus to the first node in the tree without opening or closing a node and selects it if it is selectable.
  • End: Moves focus to the last node in the tree that is focusable without opening a node and selects it if it is selectable.
  1. DOM Focus is maintained on the combobox textbox and the assistive technology focus is moved within the tree using aria-activedescendant as described in Managing Focus in Composites Using aria-activedescendant.
  2. The tree allows only one suggested value to be selected at a time for the textbox value.
  3. In a tree popup, some or all parent nodes may not be selectable values; they may serve as category labels for suggested values. If focus moves to a node that is not a selectable value, either:
    • The previously selected node, if any, remains selected until focus moves to a node that is selectable.
    • There is no selected value.
    • In either case, focus is visually distinct from selection so users can readily see if a value is selected or not.
  4. If the nodes in a tree are arranged horizontally:
    1. Down Arrow performs as Right Arrow is described above, and vice versa.
    2. Up Arrow performs as Left Arrow is described above, and vice versa.
Dialog Popup Keyboard Interaction

When focus is in a dialog popup:

  • There are two ways to close the popup and return focus to the textbox:
    1. Perform an action in the dialog, such as activate a button, that specifies a value for the textbox.
    2. Cancel out of the dialog, e.g., press Escape or activate the cancel button in the dialog. Canceling either returns focus to the text box without changing the textbox value or returns focus to the textbox and clears the textbox.
  • The dialog implements the keyboard interaction defined in the modal dialog pattern.

Unlike other combobox popups, dialogs do not support aria-activedescendant so DOM focus moves into the dialog from the textbox.

WAI-ARIA Roles, States, and Properties

The role, state, and property guidance where the ARIA 1.1 and ARIA 1.0 patterns differ is listed first. The subsequent guidance applies to both patterns.

  • In a combobox implementing the ARIA 1.1 pattern:
    • The element that serves as the combobox container has role combobox.
    • The element with role combobox contains or owns a textbox element that has either role textbox or role searchbox.
    • When the combobox popup is visible, the combobox element contains or owns an element that has role listbox, tree, grid, or dialog.
    • If the combobox popup has a role other than listbox, the element with role combobox has aria-haspopup set to a value that corresponds to the popup type. That is, aria-haspopup is set to grid, tree, or dialog. Note that elements with role combobox have an implicit aria-haspopup value of listbox.
    • When the combobox popup is visible, the textbox element has aria-controls set to a value that refers to the combobox popup element.
  • In a combobox implementing the ARIA 1.0 pattern:
    • The element that serves as the textbox has role combobox.
    • When the combobox popup is visible, the element with role combobox has aria-owns set to a value that refers to an element with role listbox.
    • the element with role combobox has a value for aria-haspopup of listbox. Note that elements with role combobox have an implicit aria-haspopup value of listbox.
  • The textbox element has a value for aria-multiline of false. Note that the default value of aria-multiline is false.
  • When the combobox popup is not visible, the element with role combobox has aria-expanded set to false. When the popup element is visible, aria-expanded is set to true. Note that elements with role combobox have a default value for aria-expanded of false.
  • When a combobox receives focus, DOM focus is placed on the textbox element.
  • When a descendant of a listbox, grid, or tree popup is focused, DOM focus remains on the textbox and the textbox has aria-activedescendant set to a value that refers to the focused element within the popup.
  • In a combobox with a listbox, grid, or tree popup, when a suggested value is visually indicated as the currently selected value, the option, gridcell, row, or treeitem containing that value has aria-selected set to true.
  • If the combobox has a visible label, the element with role combobox has aria-labelledby set to a value that refers to the labeling element. Otherwise, the combobox element has a label provided by aria-label.
  • The textbox element has aria-autocomplete set to a value that corresponds to its autocomplete behavior:
    • none: When the popup is displayed, the suggested values it contains are the same regardless of the characters typed in the textbox.
    • list: When the popup is triggered, it presents suggested values that complete or logically correspond to the characters typed in the textbox.
    • both: When the popup is triggered, it presents suggested values that complete or logically correspond to the characters typed in the textbox. In addition, the portion of the selected suggestion that has not been typed by the user, known as the completion string, appears inline after the input cursor in the textbox. The inline completion string is visually highlighted and has a selected state.
  1. When referring to the roles, states, and properties documentation for the below list of patterns used for popups, keep in mind that a combobox is a single-select widget where selection always follows focus in the popup.
  2. The roles, states, and properties for popup elements are defined in their respective design patterns:

对话框(模态)

对话框 是叠加在主窗口或另一个对话框上的窗口。Window下的模态对话框是惰性的。也就是说,用户不能与对话框之外的内容进行交互。当前活跃窗口之外的非活跃内容,一般是模糊不清或灰暗的,这样就让这些内容很难被辨别,并且在某些实现中,如果试图与非活跃内容进行交互将导致对话框被关闭。

与非模态对话框类型类似,模态对话框限制了TAB顺序。也就是说,TabShift + Tab 不会把焦点移出对话框。但是,与非模态对话框不同的是,模态对话框没有提供在不关闭当前对话框的情况下,将键盘焦点移出对话框窗口的方法。

alertdialog 角色是特殊情况的对话框角色,被专门设计用来将用户的注意力转移到简短、重要的信息上。其用法被描述在 警告对话框设置模块

示例

模态对话框例子

键盘交互

在以下的描述中,术语 tabbable element 是指 tabindex 值大于等于0的元素。注意:强烈不建议使用大于0的值。

  • 当对话框被打开时,焦点移动到对话框内的元素。请参阅下面关于初始焦点处理的注释。
  • Tab:
    • 将焦点移到对话框内的下一个可聚焦元素。
    • 如果焦点是最后一个元素,将焦点移动到对话框内的第一个可聚焦元素。
  • Shift + Tab:
    • 将焦点移到对话框内的上一个可聚焦元素。
    • 如果焦点是在第一个元素,将焦点移动到对话框内的最后一个可聚焦元素。
  • Escape: 关闭对话框。
  1. 当对话框被打开时,根据内容的性质和大小放置焦点。
    • 在任何情况下,焦点都应该移动到对话框中的一个元素上。
    • 除非建议某个操作的情况,焦点应该被初始设置在第一个可聚焦的元素上。
    • 如果对话框里面的内容非常多,聚焦第一个交互元素会导致起始内容滚出视窗,建议给对话框顶部的静态元素添加 tabindex=-1
    • 如果对话框内容是一个不容易逆转的流程的最后一步,例如删除数据或者完成资金交易,建议将焦点设置在最小的破坏性操作上,特别是撤销比较困难或不可撤销的操作。通常这种情况下使用 警告对话框
    • 如果对话框内容仅包含提供额外信息或是继续处理的交互,则建议将焦点设置为最有可能使用的元素上,例如 OKContinue 按钮。
  2. 当一个对话框关闭时,焦点返回到唤起该对话框的元素上,除了:
    • 唤起元素不复存在,此时,焦点被设置在逻辑工作流程中的另一个元素上。
    • 包含以下场景的工作流程设计,可以聚焦到一个更加符合逻辑的、不同的元素。
      1. 用户不太可能需要立即重新唤起对话框。
      2. 对话框中完成的任务与工作流程中的后续步骤直接相关。
      例如,网格包含一个具有用于添加行的按钮的相关工具条。Add Row按钮打开一个提示输入行数的对话框。对话框关闭以后,焦点应该放在新增行的第一个单元格中。
  3. 强烈建议在所有对话框中的Tab序列中,包含一个具有 button 角色的可见元素来关闭对话框,例如一个关闭图标,或者取消按钮。

WAI-ARIA 角色,状态和属性

  • 作为对话框容器的元素具有 dialog 角色。
  • 需要操作对话框的所有元素都是 dialog 角色元素的后代。
  • 对话框容器元素的 aria-modal 被设置为 true
  • 该对话框包括:
  • 可选的,aria-describedby 属性被设置在具有 dialog 角色的元素上,指明对话框中的哪些元素包含描述对话框的主要目的或信息的内容。指定描述元素,当对话框打开时,能够让屏幕阅读器在朗读对话框标题和初始聚焦元素的同时,朗读该描述。
  • 通过将 aria-modal 设置为 true,将对话框标记为模态对话框,可以防止某些辅助技术用户感知到对话框外的内容,如果一个对话框被标记为模态对话框,但对其他用户来说又不表现为模态对话框,这些辅助技术的用户将会得到不好的体验。所以, 以下两点同时出现时,标记为模态对话框:
    1. 应用程序代码防止所有用户以任何方式和对话框外的元素进行交互。
    2. 视觉样式模糊了对话框外的内容。
  • ARIA1.1中引入的 aria-modal 属性替代了 aria-hidden,为了告知辅助技术对话框的内容是不可交互的。然而,但传统对话框的实现中,aria-hidden 被用来让对话框外的内容变得让辅助技术用户不可访问,更重要的是:
    1. 在每个包含无效内容的元素上都将 aria-hidden 设置为 true
    2. 对话框元素不是任何 aria-hiddentrue 的元素的后代。

Disclosure (Show/Hide)

A disclosure is a button that controls visibility of a section of content. When the controlled content is hidden, it is often styled as a typical push button with a right-pointing arrow or triangle to hint that activating the button will display additional content. When the content is visible, the arrow or triangle typically points down.

Examples

Keyboard Interaction

When the disclosure control has focus:

  • Enter: activates the disclosure control and toggles the visibility of the disclosure content.
  • Space: activates the disclosure control and toggles the visibility of the disclosure content.

WAI-ARIA Roles, States, and Properties

  • The element that shows and hides the content has role button.
  • When the content is visible, the element with role button has aria-expanded set to true. When the content area is hidden, it is set to false.
  • Optionally, the element with role button has a value specified for aria-controls that refers to the element that contains all the content that is shown or hidden.

Feed

A feed is a section of a page that automatically loads new sections of content as the user scrolls. The sections of content in a feed are presented in article elements. So, a feed can be thought of as a dynamic list of articles that often appears to scroll infinitely.

The feature that most distinguishes feed from other ARIA patterns that support loading data as users scroll, e.g., a grid, is that a feed is a structure, not a widget. Consequently, assistive technologies with a reading mode, such as screen readers, default to reading mode when interacting with feed content. However, unlike most other WAI-ARIA structures, a feed establishes an interoperability contract between the web page and assistive technologies. The contract governs scroll interactions so that assistive technology users can read articles, jump forward and backward by article, and reliably trigger new articles to load while in reading mode.

For example, a product page on a shopping site may have a related products section that displays five products at a time. As the user scrolls, more products are requested and loaded into the DOM. While a static design might include a next button for loading five more products, a dynamic implementation that automatically loads more data as the user scrolls simplifies the user experience and reduces the inertia associated with viewing more than the first five product suggestions. But, unfortunately when web pages load content dynamically based on scroll events, it can cause usability and interoperability difficulties for users of assistive technologies.

The feed pattern enables reliable assistive technology reading mode interaction by establishing the following interoperability agreement between the web page and assistive technologies:

  1. In the context of a feed, the web page code is responsible for:
    • Appropriate visual scrolling of the content based on which article contains DOM focus.
    • Loading or removing feed articles based on which article contains DOM focus.
  2. In the context of a feed, assistive technologies with a reading mode are responsible for:
    • Indicating which article contains the reading cursor by ensuring the article element or one of its descendants has DOM focus.
    • providing reading mode keys that move DOM focus to the next and previous articles.
    • Providing reading mode keys for moving the reading cursor and DOM focus past the end and before the start of the feed.

Thus, implementing the feed pattern allows a screen reader to reliably read and trigger the loading of feed content while staying in its reading mode.

Another feature of the feed pattern is its ability to facilitate skim reading for assistive technology users. Web page authors may provide both an accessible name and description for each article. By identifying the elements inside of an article that provide the title and the primary content, assistive technologies can provide functions that enable users to jump from article to article and efficiently discern which articles may be worthy of more attention.

Example

Example Implementation of Feed Pattern

Keyboard Interaction

The feed pattern is not based on a desktop GUI widget so the feed role is not associated with any well-established keyboard conventions. Supporting the following, or a similar, interface is recommended.

When focus is inside the feed:

  • Page Down: Move focus to next article.
  • Page Up: Move focus to previous article.
  • Control + End: Move focus to the first focusable element after the feed.
  • Control + Home: Move focus to the first focusable element before the feed.
  1. Due to the lack of convention, providing easily discoverable keyboard interface documentation is especially important.
  2. In some cases, a feed may contain a nested feed. For example, an article in a social media feed may contain a feed of comments on that article. To navigate the nested feed, users first move focus inside the nested feed. Options for supporting nested feed navigation include:
    • Users move focus into the nested feed from the content of the containing article with Tab. This may be slow if the article contains a significant number of links, buttons, or other widgets.
    • Provide a key for moving focus from the elements in the containing article to the first item in the nested feed, e.g., Alt + Page Down.
    • To continue reading the outer feed, Control + End moves focus to the next article in the outer feed.
  3. In the rare circumstance that a feed article contains a widget that uses the above suggested keys, the feed navigation key will operate the contained widget, and the user needs to move focus to an element that does not utilize the feed navigation keys in order to navigate the feed.

WAI-ARIA Roles, States, and Properties

  • The element that contains the set of feed articles has role feed.
  • If the feed has a visible title, the feed element has aria-labelledby referring to the element containing the title. Otherwise, the feed element has a label specified with aria-label.
  • Each unit of content in a feed is contained in an element with role article. All content inside the feed is contained in an article element.
  • Each article element has aria-labelledby referring to elements inside the article that can serve as a distinguishing label.
  • It is optional but strongly recommended for each article element to have aria-describedby referring to one or more elements inside the article that serve as the primary content of the article.
  • Each article element has aria-posinset set to a value that represents its position in the feed.
  • Each article element has aria-setsize set to a value that represents either the total number of articles that have been loaded or the total number in the feed, depending on which value is deemed more helpful to users. If the total number in the feed is undetermined, it can be represented by a aria-setsize value of -1.
  • When article elements are being added to or removed from the feed container, and if the operation requires multiple DOM operations, the feed element has aria-busy set to true during the update operation. Note that it is extremely important that aria-busy is set to false when the operation is complete or the changes may not become visible to some assistive technology users.

网格:交互式表格数据和布局容器

网格 组件是一个容器,能够让用户使用方向导航键,例如光标键、 HomeEnd,来浏览其包含的信息和与其包含的元素进行交互。作为提供灵活键盘导航的通用容器小部件,它可以满足各种各样的需求。它可以用于简单的组合复选框或导航链接的集合,也可用于复杂的目的,例如完整功能的电子应用表格。尽管 WAI-ARIA 属性和辅助技术使用"row" 和 "column" 的术语,描述和呈现 grid 角色元素的逻辑结构,但是在元素上使用 grid 角色,并不需要将其视觉呈现实现为表格。

当呈现的内容是表格时,从 gridtable 中选择实现模式时,考虑以下因素。

grid 模式的使用大致可分为两类:展示表格信息(数据表格)和集合其他部件(布局栅格)。尽管数据网格和布局栅格使用相同的ARIA角色、状态和属性,它们内容和目的中的不同是考虑键盘交互设计的重要因素。为了强调这些因素,以下两节分别介绍了数据网格和数据栅格的键盘交互模式。

示例

  • 布局网格示例: 用于布局窗口小部件的网格的三个示例实现,包括导航链接的集合,邮件收件人列表和一组搜索结果。
  • 数据网格示例: 网格的三个示例实现,包括与呈现表格信息(如内容编辑,排序和列隐藏)相关的功能。
  • 高级数据网格示例: 具有类似于典型电子表格的行为和功能的网格示例,包括单元格和行选择。

呈现表格信息的数据网格

grid 可用于显示具有列标题,行标题或两者均有的表格信息。如果表格信息是可编辑的或可交互的, grid 模式特别有用。例如,当数据元素是更多信息的链接时,不是将它们呈现在静态表格中并在页面tab序列中包含所有链接,实现 grid 模式提供给用户更加直观和有效的键盘导航方式,同时缩短了页面的tab序列的长度。 grid 还可以提供诸如单元格内容编辑,选择,剪切,复制和粘贴等功能。

在一个呈现表格数据的grid中,每一个单元格都包含一个可聚焦的元素或其单元格本身可聚焦,无论单元格内容是否可编辑或可交互。有一个例外:如果行列的表头单元格没有提供功能,例如排序或过滤,它们不需要可聚焦。一个原因是当用户与grid交互时,屏幕阅读器需要处于应用阅读模式,而不是文档阅读模式,这非常重要。在应用阅读模式时,屏幕阅读器用户只能发现可聚焦的元素和标记可聚焦元素的内容。因此,屏幕阅读器用户可能会在不知情的情况下忽略网格中包含的元素,当它们不可聚焦或不用于标记列或行。

数据网格键盘交互

以下键通过在网格的单元格之间移动焦点来提供网格导航。默认情况下,这些键盘命令在网格元素接收到焦点后默认可用。例如,用户将焦点移动具有 Tab 的网格后。

  • Right Arrow: 将焦点向右移动一个单元格。如果焦点位于行中最右侧的单元格,则焦点不会移动。
  • Left Arrow: 将焦点向左移动一个单元格。如果焦点位于行中最左侧的单元格,则焦点不会移动。
  • Down Arrow: 将焦点往下移动一个单元格。如果焦点位于列中的底部单元格上,则焦点不会移动。
  • Up Arrow: 将焦点往下移动一个单元格。如果焦点位于列中的顶部单元格上,则焦点不会移动。
  • Page Down: 以开发者设定的行数移动焦点,一般滚动时,当前可见行集合中的最后一行会变为第一次滚动后可见行中的一行。
  • Page Up: 移动焦点到开发者设定的行数,一般滚动时,当前可见行集合中的第一行会变为滚动后可见行中的一行。
  • Home: 将焦点移动到包含焦点所在行的第一个单元格。
  • End: 将焦点移动到包含焦点所在行的最后一个单元格。
  • Control + Home: 将焦点移动到第一行中的第一个单元格。
  • Control + End: 将焦点移动到最后一行的最后一个单元格。
  • 当使用以上网格导航键移动焦点时,根据单元格内容,在单元格内元素或网格单元格上设置焦点。 请参阅 是否聚焦单元格或其内部的元素
  • 当使用导航键在单元格间移动焦点,例如光标键,它们不能用于某些操作,例如操作组合框或在单元格内移动编辑光标。如果需要此功能,请参阅 单元格内的编辑和导航
  • 如果导航功能可以动态地向DOM添加更多的行或列,则将焦点移动到网格的开头或结尾的键盘事件(例如 control + End),可将焦点移动到DOM中的最后一行,而不是先前可用数据的最后一行。

如果网格支持单元格、行、列的选择,一般使用以下的键实现这些功能。

  • Control + Space: 选择包含焦点的列。
  • Shift + Space: 选择包含焦点的行。如果网格包含带有用于选择行的复选框的列,则该键可以用作在焦点不在复选框时勾选框的快捷方式。
  • Control + A: 选择所有单元格。
  • Shift + Right Arrow: 向右扩展选择一个单元格。
  • Shift + Left Arrow: 向左扩展选择一个单元格。
  • Shift + Down Arrow: 向下扩展选择一个单元格。
  • Shift + Up Arrow: 向上扩展选择一个单元格。

有关剪切,复制和粘贴键的分配,请参阅

组合部件的布局栅格

grid 模式可被用于组合一组可交互元素,例如链接、按钮、和复选框。由于整个网格只有一个元素包含在tab序列中,所以使用网格进行分组可以显著减少页面上的tab步骤。如果滚动元素列表会从一个大数据集中动态地加载更多的元素,例如在购物类网站中的推荐产品的连续列表中,该模式尤其有用。如果像这样的列表元素都在tab序列中,键盘用户会被困在列表中。如果组中的任何元素在鼠标悬停时都会出现关联元素, grid 模式用来为用户界面的上下文元素提供键盘访问。

与用于呈现数据的网格不同,用于布局的 grid 不一定具有用于标记行或列的标题单元格,并且可能只包含单个行或单个列。即使有多个行和列,它也可能呈现一个独立、逻辑上相同的元素集合。例如,消息的收件人列表可能是个网格,其每个单元格包含一个代表收件人的链接。网格最初可能只有一行,但是随着收件人的添加,会变为多行。在这样的情况下,网格导航键也需要换行,以便用户可以使用 Right ArrowDown Arrow 来从列表开头阅读到末尾。虽然在布局栅格中这种类型的焦点移动换行非常有用,但是如果在数据网格中使用就会让用户迷失方向,尤其是辅助技术的用户。

因为光标键被用来在 grid 中移动焦点,如果其包含的元素不需要光标键来操作, grid 将会更容器构建和使用。如果一个单元格包含类似listbox的元素,则需要额外的键盘命令来聚焦和激活 listbox,和恢复网格导航功能的命令。支持这个需求的方法在“ 在单元格内部编辑和导航 ”部分进行描述。

布局栅格的键盘互动

以下键通过在网格的单元格之间移动焦点来提供网格导航。这些键盘命令在 Tab 中的元素接收焦点后默认可用。

  • Right Arrow: 将焦点向右移动一个单元格。可选地,如果焦点位于行中最右侧的单元格上,则焦点可能会移动到下一行中的第一个单元格。如果焦点位于网格中的最后一个单元格上,则焦点不会移动。
  • Left Arrow: 将焦点向左移动一个单元格。可选地,如果焦点位于行中最左侧的单元格上,则焦点可能会移动到上一行中的最后一个单元格。如果焦点位于网格中的第一个单元格上,则焦点不会移动。
  • Down Arrow: 将焦点向下移动一个单元格。可选地,如果焦点位于列中的底部单元格上,则焦点可能会移动到下一列的顶部单元格。如果焦点位于网格中的最后一个单元格上,则焦点不会移动。
  • Up Arrow: 将焦点向上移动一个单元格。可选地,如果焦点位于当前列的顶部单元格上,则焦点可能会移动到前一列的最后一个单元格。如果焦点位于网格的第一个单元格上,则焦点不会移动。
  • Page Down (可选地): 以开发者设定的行数向上移动焦点,一般情况下,当前可见行中的第一行会成为滚动后可见行中的一行。
  • Page Up (可选地): 将对象移动到作者确定的行数上,通常是滚动的,因此当前可见的行行中的顶行将成为最后一个可见行之一。如果焦点位于网格的第一行,则焦点不会移动。
  • Home: 将焦点移动到包含焦点的行中的第一个单元格。可选地,如果网格具有单列或每行少于三个单元格,则焦点可以替代地移动到网格中的第一单元格。
  • End: 将焦点移动到包含焦点的行中的最后一个单元格。可选地,如果网格具有单个列或每行少于三个单元格,则焦点可以替代地移动到网格中的最后一个单元格。
  • Control + Home (可选地): 将焦点移动到第一行中的第一个单元格。
  • Control + End (可选地): 将焦点移动到最后一行的最后一个单元格。
  • 当使用以上网格键移动焦点时,根据单元格内容,决定焦点是否设置在单元格内的元素上或网格单元格上。 请参阅 是否聚焦单元格或其内部的元素.
  • 当使用导航键在单元格间移动焦点时,它们不可用于类似操作组合框或在单元格内移动输入光标等的事情。如果需要此功能,请参阅 单元格内的编辑和导航
  • 如果导航功能可以动态地向DOM中添加更多的行或列,则移动焦点到网格的开头或结尾的键盘事件(例如 control + End ),可将焦点移动到DOM中的最后一行,而不是后端数据中可用的最后一行。

为栅格布局提供需要单元格选择功能,是不常见的。虽然如此,但当确实需要时,这些功能一般使用以下的键:

  • Control + Space: 选择包含焦点的列。
  • Shift + Space: 选择包含焦点的行。如果网格包含用于选择行的复选框的列,当焦点不在复选框上时,可作为选中复选框的快捷键。
  • Control + A: 选择所有单元格。
  • Shift + Right Arrow: 向右扩展选择一个单元格。
  • Shift + Left Arrow: 向左扩展选择一个单元格。
  • Shift + Down Arrow: 向下扩展选择一个单元格。
  • Shift + Up Arrow: 向上扩展选择一个单元格。

有关剪切,复制和粘贴键的分配,请参阅

键盘交互 — 设置焦点和导航单元格内容

本节介绍了数据和布局网格模式共有的键盘交互设计的两个重要方面:

  1. 选择单元格或单元格内元素接收焦点,来响应网格导航键盘按键事件。
  2. 启用网格导航键,用来与单元格内元素进行交互。
是否聚焦单元格或其包含的元素

对于辅助技术用户,导航网格时的体验质量很大程度上取决于单元格包含的内容以及设置键盘焦点的位置。例如如果一个单元格包含一个按钮,网格导航键在单元格上放置焦点,而不是按钮上,屏幕阅读器会朗读出按钮的标签,但不会告知用户存在一个按钮。

有两种最佳的单元格设计和聚焦行为组合:

  1. 一个单元格包含一个组件,其操作不需要光标键和网格导航键,在该组件上设置焦点。这些小部件的示例包括链接,按钮,菜单栏,切换按钮,单选按钮(不是单选按钮组),开关和复选框。
  2. 一个单元格包含文本或一个单独的图形,网格导航键在单元格上设置焦点。

但是组件、文本和图像的任意组合都可能被包含在一个单元格中,不遵循以上两种设置和焦点移动模式的网格,会增加开发者或用户或两者的复杂性。下面样例部分中包含的参考实现,给出了让其他单元格设计尽可能可访问的一些策略,但是使用以上两种模式,才能获得最大程度的无障碍体验。

在单元格内编辑和导航

当使用导航键在单元格间移动焦点,它们不能用来执行像操作组合框或在单元格内移动光标的操作。用户可能需要用于网格导航的键来操作单元格内的元素,如果单元格包含:

  1. 可编辑内容。
  2. 多个小部件。
  3. 在交互模式中使用光标键交互的组件,例如单选按钮或滑块。

以下为禁用和恢复网格导航功能的惯用键盘操作。

  • Enter: 禁用网格导航以及:
    • 如果单元格包含可编辑内容,将焦点放置在输入框中,例如 textbox。如果输入框是个单行文本框,连续按 Enter ,会重置网格导航功能,或移动焦点到附近单元格的输入框中。
    • 如果单元格包含一个或多个组件,将焦点放置在第一个组件上。
  • F2:
    • 如果单元格包含可编辑的内容,则会将焦点放在输入字段中,例如 textbox。随后按下 F2 恢复网格导航功能。
    • 如果单元格包含一个或多个组件,将焦点放置在第一个组件上。随后按下 F2 恢复网格导航功能。
  • 字母数字键: 如果单元格包含可编辑的内容,则会将焦点放在输入框中,例如 textbox

当网格导航被禁用时,导航行为的常规更改包括:

  • Escape: 恢复网格导航。如果正在编辑内容,它也可能会撤消修改。
  • Right Arrow 或者 Down Arrow: 如果单元格包含多个小组件,将焦点移动到单元格的内下一个小组件,如果焦点在最后一个组件上,可选地,将焦点返回给第一个小组件,或者,传递按键事件到当前聚焦的组件。
  • Left Arrow 或者 Up Arrow: 如果单元格包含多个小组件,将焦点移动到单元格的内前一个小组件,如果焦点在最后一个组件上,可选地,将焦点返回给第一个小组件,或者,传递按键事件到当前聚焦的组件。
  • Tab: 将焦点移动到网格中的下一个组件。可选地,焦点可能会在一个单元格内循环,或在网格内循环。
  • Shift + Tab: 将焦点移动到网格中的上一个组件。可选地,焦点可能会在一个单元格内循环,或在网格内循环。

WAI-ARIA 角色,状态和属性

  • 网格容器具有角色 grid
  • 每个行容器都具有 row 角色,并且是 grid 元素或 rowgroup 角色元素的后代,或被其拥有。
  • 每个单元格是 row 元素的DOM后代,或被row元素拥有,并且具有以下角色之一:
    • columnheader 如果单元格包含标题或列的标题信息。
    • rowheader 如果单元格包含标题或行的标题信息。
    • gridcell 如果单元格不包含列或行的标题信息。
  • 如果在用户界面中有一个元素是网格的标签,在网格元素上设置 aria-labelledby 属性,该属性的值指向该标签元素。否则,使用 aria-label 为网格元素指定一个标签。
  • 如果网格具有一个说明或描述,在网格元素上设置 aria-describedby 属性,其值指向包含描述的元素。
  • 如果网格提供排序功能,则在头部单元格上为 aria-sort 属性设置合适的值,来对行或列进行排序,如 网格和表格属性 部分所述。
  • 如果网格支持选择,当单元格或行被选择时,被选择元素的 aria-selected 设置为 true
  • 如果网格提供内容编辑功能,并且包含在某些条件下禁用编辑功能的单元格,在编辑功能被禁用时,设置aria-readonly为true。如如果所有单元格的编辑功能都被禁用,在网格元素上设置 aria-readonlytrue。不提供编辑功能的网格在任何元素上都不包含 aria-readonly 属性。
  • 如果存在某些行或列在DOM中被隐藏或不存在的情况,例如当滚动时自动加载数据,或者网格提供了隐藏行或列的功能,使用以下属性,如 网格和表格属性 所述。
  • 如果网格包含跨多行或多列的单元格,并且如果 grid 角色未应用于HTML table 元素,则应用 aria-rowspanaria-colspan,如 网格和表属性 所述。
  • 如果具有 grid 角色的元素是HTML table 元素,那么不必为行和单元格使用ARIA角色,因为HTML元素暗含了ARIA语义。例如,HTML <TR> 具有隐含的ARIA角色 row。一个从HTML table 构建的 网格,包含跨越多行或多列的单元格,必须使用HTML rowspancolspan 属性,不能使用 aria-rowspanaria-colspan
  • 如果通过aria-owns属性将行或列包含在网格中,它们将在网格元素的DOM后代之后呈现给辅助技术,除非DOM后代也被包含在给 aria-owns 属性中。请参阅使用 aria-owns 进行详细说明。

Listbox

listbox 控件呈现了一个选项列表,并允许用户选择一个或多个。允许选择一个选项的列表框是一个单选列表框;允许选择多个选项的列表框是一个多选列表框。

当屏幕阅读器呈现一个列表框,可能会渲染出其名称、状态和每个选项在列表中的位置。选项的名称是一个由浏览器计算得到的字符串,一般来自选项元素的内容。作为一个平面字符串(flat string),名称不包含任何语义信息。因此,如果选项包含一个语义元素,例如一个标题,屏幕阅读器用户不会访问到该语义。另外,listbox角色传递给辅助技术的交互模型,不支持选项内元素的交互。因为listbox组件的这些特性,它并没有提供可访问方式来呈现交互元素的列表,例如链接、按钮或复选框。为了呈现这些交互元素的列表,参见 网格模块

为了让屏幕阅读器用户容易感知和理解,避免使用长选项名称。当选项被朗读时,选项的整体名称作为一个独立语音单元被朗读。当一次按键操作就朗读太多的信息,将会很难理解。长的名称会增加朗读中断的发生,而抑制信息的感知,因为用户一般不得不重新朗读整个选项。而且,如果用户不理解说了什么,在listbox组件中,屏幕阅读器用户很难实现按字、词、短语朗读。

选项集中每个选项名称使用相同的单词或短语开头也可以显著降低键盘和屏幕阅读器用户的可用性。滚动列表来找到特定选项,对屏幕阅读器用户来说非常费时,因为他们在听到每个选项的不同之前,都必须听到重复的单词或短语。例如,如果一个选择城市的列表框,其选项的每个城市名称前面都有国家名称,如果每个国家都列出了很多城市,屏幕阅读器用户将要不得不在听到城市名称之前听到国家名称。在这种情况下,最好有2个列表框,一个用于国家,一个用于城市。

示例

键盘交互

对于一个垂直向的列表框:

  • 当一个单选列表框接收到焦点:
    • 如果在列表框接收焦点前,没有选择任何选项,第一个选项获得焦点。可选的,第一个选项可以自动选择。
    • 如果列表框获得焦点之前选择了一个选项,焦点设置在所选择的选项上。
  • 当一个多选列表框接收到焦点:
    • 如果列表框接收焦点之前没有选择任何选项,焦点设置在第一个选项并且选择状态不会自动改变。
    • 如果列表框接收焦点之前选择一个或多个选项,焦点设置在已选择选项的第一个。
  • Down Arrow: 移动焦点到上一个选项。可选地,在一个单选列表框中,选择也可以跟随焦点移动。
  • Up Arrow: 将焦点移到前一个选项。通常,一个单选列表框,选择也可以跟随焦点移动。
  • Home (可选地): 将焦点移到第一个选项。通常,一个单选列表框,选择也可以跟随焦点移动。对于超过5个选项的列表,强烈建议支持此键。
  • End (可选地): 将焦点移到最后一个选项。通常,一个单选列表框,选择也可以跟随焦点移动。对于超过5个选项的列表,强烈建议支持此键。
  • 建议所有列表框都支持键入提示。尤其是那些拥有超过七个选项的列表:
    • 键入字符:焦点移动到名称以键入字符开头的下一个项目上。
    • 快速键入多个字符:焦点移动到名称以键入字符串开头的下一个项目上。
  • 多选:开发者可以实现以下两种交互模型中的一种来支持多项选择:一个是推荐模型,当导航列表时不需要用户按住修饰键,例如 ShiftControl ,或一种替代模型,当导航时需要用户按住修饰键,防止丢失选择状态。
    • 推荐的选择模型 - 没有必要按住辅助键:
      • Space: 改变焦点选项的选择状态。
      • Shift + Down Arrow (可选地): 将焦点移动到下一个选中项并且切换选项的选中状态。
      • Shift + Up Arrow (可选地): 将焦点移到前一选中项并且切换选项的选中状态。
      • Shift + Space (可选地): 从最近选中的项目中选择相邻的元素聚焦。
      • Control + Shift + Home (可选地): 选择从聚焦的选项到第一个选项的所有的选项。
      • Control + Shift + End (可选地): 选择从聚焦的选项到最后一个选项的所有选项。
      • Control + A (可选地): 选择列表中的所有选项。或者,如果选择了所有选项,它也可能取消选择所有选项。
    • 替代选择模型 —— 在不按住 ShiftControl 修饰键移动焦点不会取消选择所有已选择节点,除非当前聚焦节点:
      • Shift + Down Arrow: 将焦点移到下一个选项并切换选项的选择状态。
      • Shift + Up Arrow: 将焦点移到上一个选项并切换选项的选择状态。
      • Control + Down Arrow: 将焦点移到下一个选项但不改变选项的选择状态。
      • Control + Up Arrow: 将焦点移到上一个选项但不改变选项的选择状态。
      • Control + Space 改变焦点选项的选择状态。
      • Shift + Space (可选地): 从最近选中的项目中选择相邻的元素聚焦。
      • Control + Shift + Home (可选地): 选择从聚焦的选项到第一个选项的所有的选项。
      • Control + Shift + End (可选地): 选择从聚焦的选项到最后一个选项的所有选项。
      • Control + A (可选地): 选择列表中的所有选项。或者,如果选择了所有选项,它也可能取消选择所有选项。
  1. DOM焦点(活跃元素)与选择状态有功能上的区别。更多细节,请参阅 this description of differences between focus and selection.
  2. listbox 角色支持 aria-activedescendant 属性,当通过键盘导航(keybord navigation)时,它提供一种非传统方式在 treeitem 元素间移动DOM焦点。有关详细信息,请参阅 Managing Focus in Composites Using aria-activedescendant
  3. 在单选列表框中,移动焦点可以选择性的取消先前选择选项的选择,并选择新聚焦的选项。这样的选择模型被称之为 "选择跟随焦点"。具有选择跟随焦点在某些情况下非常有用,但会严重降低其他情况中的可访问性。有关指南,请参阅 Deciding When to Make Selection Automatically Follow Focus
  4. 如果全选或取消全选是个重要功能,使用不同控件实现这些操作,例如 "全选" 和 "取消全选按钮",会显著提升可用性。
  5. 如果在一个列表框的选项水平排列:
    1. Down Arrow 行为和上面描述的 Right Arrow 一样,反之亦然。
    2. Up Arrow 行为和上面描述的 Left Arrow 一样,反之亦然。

WAI-ARIA 角色,状态和属性

  • 包含或拥有所有列表框选项的元素拥有角色 listbox
  • 列表框中的每个选项都有 option 角色,并且是 listbox 角色元素的DOM后代,或者在列表框元素上使用 aria-owns 属性索引。
  • 如果列表框不是另一个部件的一部分,那么它有一个可见的label通过 aria-labelledby 与有 listbox 角色的元素相关联。
  • 单选列表框中,选中的选项 aria-selected 设置为 true
  • 如果列表框支持多选:
  • 如果可用选项的集合没有完整地显示在DOM中,而是根据用户滚动动态加载,它们的 aria-setsizearia-posinset 适当设定。
  • 如果选项是水平排列的, listbox 角色元素的 aria-orientation 设置为 horizontal

单选按钮组

单选按钮组,是一个可选中按钮的组合,被称为单选按钮,且在该组合中,只有一个按钮处于选中状态。

示例

键盘交互

  • 在单选按钮组获取焦点时:
    • 如果有一个单选按钮被选中,那么焦点设置在这个按钮上。
    • 如果没有被选中的单选按钮,那么将焦点设置在第一个单选按钮上。
  • Space: 如果该按钮还没有被选中,则选中当前聚焦的单选按钮。
  • Right ArrowDown Arrow: 移动焦点到组合中的下一个单选按钮,取消选中先前聚焦的按钮,并且选中新聚焦的按钮。如果焦点在最后一个按钮上,焦点移动到第一个按钮。
  • Left ArrowUp Arrow: 移动焦点到组合中的上一个单选按钮,取消选中先前聚焦的按钮,并选中新聚焦的按钮。如果焦点在第一个按钮上,焦点移动到最后一个按钮。

上文所述的初始聚焦行为,与一些浏览器为原生HTML按钮组所提供的行为略有不同。在某些浏览器中,如果没有选中任何一个单选按钮,使用 Shift+Tab 将焦点移动到单选按钮组,焦点将会被放置在最后一个单选按钮,而不是第一个单选按钮。

WAI-ARIA 角色,状态和属性

  • 单选按钮被具有 radiogroup 角色的元素包含或拥有。
  • 每个单选按钮的role值都为 radio
  • 如果一个单选按钮被选中,那么该 radio 元素的 aria-checked 将被设置为 true。 如果没有被选中,aria-checked 设置为 false
  • 每一个 radio 元素由其内容标记,使用 aria-labelledby,索引一个可见标签,或使用 aria-label 指定一个标签。
  • radiogroup 使用 aria-labelledby 索引一个可见标签,或者使用 aria-label 指定一个标签。
  • 如果元素提供了单选按钮组或每个单选按钮的额外信息,这些元素被 radiogroup 元素或 radio 元素使用 aria-describedby 属性索引。

滑块

滑块是供用户从给定范围内选择值的输入控件。滑块通常有个拖动拇指,可以沿着条或轨道移动来改变滑块的值。

示例

键盘交互

  • Right Arrow: 按一定量增加滑块的值;
  • Up Arrow: 按一定量增加滑块的值;
  • Left Arrow: 按一定量减小滑块的值;
  • Down Arrow: 按一定量减小滑块的值;
  • Home: 将滑块设置为其范围内的最小值;
  • End: 将滑块设置为其范围内的最大值;
  • Page Up (可选地): 大幅度增加滑块的值(比 Up Arrow 增加的值大).
  • Page Down (可选地): 大幅度减小滑块的值(比 Down Arrow 减小的值大).
  1. 焦点放在滑块上(鼠标用户可以移动的视觉对象,也称为thumb组件)。
  2. 在某些场景下,反转上面指定值变化的方向(例如: Up Arrow 减小滑块的值),可以创建更直观的体验<译者注:可以理解为滑块为纵向方向排列>

WAI-WRIA 角色、状态和属性

  • 作为可聚焦滑块控件的元素具有 slider 角色。
  • 滑块元素将 aria-valuenow 属性设置为十进制值,呈现滑块的当前值。
  • 滑块元素将 aria-valuemin 属性设置为十进制值,呈现当前滑块允许的最小值。
  • 滑块元素将 aria-valuemax 属性设置为十进制值,呈现当前滑块允许的最大值。
  • 如果 aria-valuenow 的值用户不容易理解,例如周几一般使用数字呈现, aria-valuenow 属性被设置为字符串,让滑块的属性值更易理解,例如"Monday"。
  • 如果滑块具有一个可见标签,在slider元素上使用 aria-labelledby 索引。否则,使用 aria-label 为滑块元素提供一个标签。
  • 如果滑块是垂直方向的,则把 aria-orientation 设置为 vertical。滑块的 aria-orientation 的默认值是 horizontal

滑块(多滑块)

Multi-thumb滑块是一个具有两个或多个拇指(thumb)的 滑块,每个拇指都可以在一组相关值中设置一个值。很多双拇指滑块用来设置范围的最大值和最小值,而且拇指间不允许跨越。也就是说,设置范围的上限thumb的值不能低于设置范围的下限thumb的值。但是,在某些多拇指滑块中,每个拇指的设置值与其他拇指无关。

示例

多滑块示例: 演示了一个two-thumb 滑块来选择航班和酒店的价格范围。

键盘交互

  • 每个拇指都在页面Tab序列中,并且与 单拇指滑块 具有相同的键盘交互。
  • 无论滑块上的thumb值与视觉位置如何,标签顺序保持不变。例如,如果拇指的值改变,例如其越过了其他拇指,该拇指的焦点顺序不变。<译者注:如果thumb通过其他thumb,则焦点移至被通过的thumb值,并继续进行增加或减少>

WAI-WRIA 角色、状态和属性

  • 每个可聚焦滑块拇指元素具有 slider 角色。
  • 每个滑块元素的 aria-valuenow 属性设置为滑块当前的十进制值。
  • 每个滑块元素的 aria-valuemin 属性设置为滑块十进制的最小允许值。
  • 每个滑块元素的 aria-valuemax 属性设置为滑块十进制的最大允许值。
  • 当另一个滑块的范围(如最小值或者最大值)依赖另一个滑块的当前值,当前值改变的时候依赖滑块的 aria-valueminaria-valuemax 也要更新。
  • 如果 aria-valuenow 的值对用户不友好,例如周几一般使用数字呈现,将 aria-valuetext 属性设置为一个字符串,这样滑块值更易理解,例如 "Monday"。
  • 如果滑块具有可视的标签,那么滑块元素通过 aria-labelledby 引用,否则滑块元素上设置 aria-label 标签。
  • 如果滑块是垂直方向的,则把 aria-orientation 设置为 vertical。滑块的 aria-orientation 的默认值是 horizontal

数值调节按钮

数值调节按钮是个将值限定在离散数值集合或范围的输入组件。例如,在一个设置闹钟的部件中,一个数值调节按钮允许用户在0-59间选择分钟。

数值调节按钮通常有三个组件,包含一个显示当前值的文本框,一个增加按钮,一个减小按钮。一般来说,文本框是唯一可聚焦组件,因为增加和减小功能可使用光标键访问,一般来说,文本框还允许用户直接编辑其值。

如果数值范围很大,数值调节按钮支持以较小和较大的幅度调节其值。例如,在闹钟示例中,用户可以使用 Up ArrowDown Arrow 以1分钟的步幅改变值,并且可以使用 Page UpPage Down 以10分钟的步幅改变值。

示例

与数值调节按钮相关的动态都记录于 issue 125.

键盘交互

  • Up Arrow: 递增。
  • Down Arrow: 递减。
  • Home: 如果数值调节按钮具有最小值,则设置数值调节按钮的值为最小值。
  • End: 如果数值调节按钮具有最大值,则设置数值调节按钮的值为最大值。
  • Page Up (可选地): 以大于 Up Arrow 的调节幅度增加值。ncreases the value by a larger step than Up Arrow.
  • Page Down (可选地): 以大于 Down Arrow 的调节幅度减小值。
  • 如果数值编辑按钮的文本框允许直接编辑其值,支持以下键。
    • 适用于设备平台的标准单行文本编辑键(请参阅下面的注释)。
    • 可打印字符: 在文本框中输入字符。注意,许多实现仅允许某些字符作为值的一部分,并防止输入任何其他字符。 例如,小时和分钟的数值调节只允许从0到59的整数值,冒号':'以及字母'AM'和'PM'。 任何其他字符输入不会更改文本字段的内容和按钮的值。
  1. 操作过程中焦点仍在文本字段上。
  2. 适用于设备平台的标准单行文本编辑键:
    1. 包括输入键,光标移动,选择和文本操作。
    2. 用于编辑功能的标准键分配依赖于操作系统。
    3. 提供文本编辑功能的最强大的方法需要依靠浏览器,浏览器为HTML文本输入类型的组件和具有 contenteditable HTML属性的元素支持文本编辑功能。
    4. 重要: 确保JavaScript不会干扰浏览器提供的文本编辑功能,方法是捕获用于执行它们的事件。

WAI-WRIA 角色、状态和属性

  • 作为数值调节按钮的可聚焦元素具有 spinbutton 角色。一般来说,是支持文本输入的元素。
  • spinbutton元素的 aria-valuenow 属性用十进制值,表示当前值。
  • 如果它具有已知的最小值,spinbutton元素的 aria-valuemin 属性设置为十进制值,表示数值调节按钮的最小允许值。
  • 如果它具有确定的最大值,spinbutton元素的 aria-valuemax 属性设置为十进制值,表示数值调节按钮的最大允许值。
  • 如果 aria-valuenow 的值用户不好理解,例如周几一般使用数字呈现,可以将spinbutton元素的 aria-valuetext 属性设置为一个字符串,让数值选择按钮的值更好理解,例如 "Monday"。
  • 如果spinbutton具有一个可见标签,在spinbutton元素上使用 aria-labelledby 索引,否则,使用 aria-label 属性为spinbutton元素提供一个标签。

Table

Like an HTML table element, a WAI-ARIA table is a static tabular structure containing one or more rows that each contain one or more cells; it is not an interactive widget. Thus, its cells are not focusable or selectable. The grid pattern is used to make an interactive widget that has a tabular structure.

However, tables are often used to present a combination of information and interactive widgets. Since a table is not a widget, each widget contained in a table is a separate stop in the page tab sequence. If the number of widgets is large, replacing the table with a grid can dramatically reduce the length of the page tab sequence because a grid is a composite widget that can contain other widgets.

As with other WAI-ARIA roles that have a native host language equivalent, authors are strongly encouraged to use a native HTML table element whenever possible. This is especially important with role table because it is a new feature of WAI-ARIA 1.1. It is thus advisable to test implementations thoroughly with each browser and assistive technology combination that could be used by the target audience.

Examples

Table Example: ARIA table made using HTML div and span elements.

Keyboard Interaction

Not applicable.

WAI-ARIA Roles, States, and Properties

  • The table container has role table.
  • Each row container has role row and is either a DOM descendant of or owned by the table element or an element with role rowgroup.
  • Each cell is either a DOM descendant of or owned by a row element and has one of the following roles:
    • columnheader if the cell contains a title or header information for the column.
    • rowheader if the cell contains title or header information for the row.
    • cell if the cell does not contain column or row header information.
  • If there is an element in the user interface that serves as a label for the table, aria-labelledby is set on the table element with a value that refers to the labeling element. Otherwise, a label is specified for the table element using aria-label.
  • If the table has a caption or description, aria-describedby is set on the table element with a value referring to the element containing the description.
  • If the table contains sortable columns or rows, aria-sort is set to an appropriate value on the header cell element for the sorted column or row as described in the section on grid and table properties.
  • If there are conditions where some rows or columns are hidden or not present in the DOM, e.g., there are widgets on the page for hiding rows or columns, the following properties are applied as described in the section on grid and table properties.
  • If the table includes cells that span multiple rows or multiple columns, then aria-rowspan or aria-colspan is applied as described in grid and table properties.

If rows or cells are included in a table via aria-owns, they will be presented to assistive technologies after the DOM descendants of the table element unless the DOM descendants are also included in the aria-owns attribute.

选项卡

选项卡是一个内容分层模块的集合,被称为选项卡面板,一次只能显示内容的一个面板。每个选项卡面板都有相关联选项卡元素,当被激活,显示其相关联面板。选项卡元素列表被排列在当前显示面板的边缘,大多数情况在顶部边缘。

用于描述选项卡的术语包含:

选项卡或选项卡界面
选项卡元素组合和它们相关联的内容面板。
选项卡列表
被包含在 tablist 元素中的选项卡元素组合。
选项卡
选项卡列表中的一个元素,作为其中一个内容面板的标签,可以激活以显示对应的内容面板。
内容面板
包含与选项卡元素相关联内容的元素。

当初始化一个选项卡界面,一个选项卡面板默认显示,其相关联选项卡元素使用样式来标识其当前活跃。当用户激活一个别的选项卡元素,先前显示的内容面板被隐藏,与被激活选项卡元素相关联的内容面板变为可见,且选项卡元素被认为当前“活跃”。

示例

  • 自动激活的选项卡: 一个选项卡小组件,当接收到焦点时选项卡标签会自动激活并显示对应的面板。
  • 手动激活的选项卡: 一个选项卡小组件,用户通过点击 Space 或者 Enter来激活一个选项卡标签并显示它的面板。

键盘交互

对于选项卡列表:

  • Tab: 当焦点进入选项卡列表,将焦点放置在当前活跃 选项卡 元素上。当选项卡列表包含焦点,移动焦点到当前页面tab序列中的选项卡列表外的下一个元素,一般情况是内容面板的第一个可聚焦元素,或内容面板本身。
  • 当焦点在水平选项卡列表中的一个选项卡元素上时:
    • Left Arrow: 移动焦点到上一个选项卡元素;如果焦点在第一个选项卡元素上,移动焦点到最后一个选项卡元素。
    • Right Arrow: 移动焦点到下一个选项卡元素。如果焦点在最后一个选项卡元素上,移动焦点到第一个选项卡元素。
  • 当焦点在水平或垂直选项卡列表中的一个选项卡元素上时:
    • Space or Enter: 如果获取焦点的选项卡不会自动激活,则激活该选项卡元素。
    • Home (可选): 移动焦点到第一个选项卡元素上。
    • End (可选): 移动焦点到最后一个选项卡元素上。
    • Shift + F10: 如果选项卡有关联的弹出菜单,则打开菜单。
    • Delete (可选): 如果允许删除操作,删除(关闭)当前选项卡元素和其相关联选项卡面板。如果还有任何选项卡元素,将焦点设置在已关闭选项卡元素的下一个元素上,并且激活新聚焦的选项卡元素。
  1. 建议当选项卡元素接收到焦点时自动激活,只要它们相关的选项卡面板显示时没有明显的延迟。这种做法需要提前加载选项卡内容面板的内容。否则,自动激活标签会延缓焦点移动,这也会降低用户有效浏览选项卡列表的效率。更多相关指导,可以阅读
  2. 如果选项卡列表中的选项卡元素垂直排列:
    1. Down ArrowRight Arrow 执行一样的操作。
    2. Up ArrowLeft Arrow 执行一样的操作。
  3. 如果选项卡列表是水平的,它不会监听 Down ArrowUp Arrow 光标键,即使焦点在选项卡列表内,使用这些键仍会提供浏览器的常规滚动功能。

WAI-ARIA 角色,状态和属性

  • 选项卡组合的容器元素具有角色 tablist
  • 每个选项卡元素都有 tab 角色,并且被包含在具有 tablist 角色的元素里。
  • 每个 选项卡 拥有角色 tabpanel
  • 每个具有 tab 角色的元素,具有 aria-controls 属性来索引其相关联 tabpanel 元素。
  • 当前活跃 选项卡 元素具有 aria-selected 状态且设置为 true ,所有其他 选项卡 元素为 false
  • 每个具有角色 tabpanel 的元素有 aria-labelledby 属性,来索引其相关联 选项卡 元素。
  • 如果一个 tab 元素有弹出 菜单 ,则它的属性 aria-haspopup 设置为 true
  • 如果 tablist 元素是垂直排布,那么它应该设置 aria-orientation 属性值为 verticaltablist 元素的 aria-orientation 默认值为 horizontal

工具栏

工具栏 是一个对控件进行分组的容器,例如,按钮、菜单按钮、或复选框。

当一组控件在视觉上呈现为一个组合,可以使用 toolbar 角色来告知屏幕阅读器用户分组的呈现和目的。组合控件到工具栏,在键盘交互中是一个减少Tab停留数量的有效方式。

优化工具栏小部件的优点:

  1. 实现焦点管理,这样在Tab顺序中只包含一个toolbar站点,使用光标键可以在toolbar的控件间移动焦点。
  2. 避免在工具栏中包含需要光标键操作的控件,例如文本框或单选按钮。如果必须使用,只能包含一个这样的控件且让其作为最后一个元素。
  3. 当且仅当组合中包含三个或三个以上的控件时,才能使用工具栏作为分组元素。

Example

Toolbar Example: A toolbar that uses roving tabindex to manage focus and contains several buttons, including a menu button.

键盘交互

  • 当工具栏获取焦点时,焦点被设置在第一个可用控件上。或者,如果工具栏先前已获取过焦点,则焦点被设置在工具栏中最后一个被聚焦的元素上。(译者注:一般情况下,屏幕阅读器用户会使用Tab快速浏览页面上的内容,顺序为从上到下、从左到右,此时,若工具栏获取焦点,则将焦点设置在第一个可聚焦的元素上,若使用Shift+tab反向浏览,若工具栏获取焦点,则将焦点设置在最后一个可聚焦的元素上。)
  • 水平工具栏(默认):
    • Left Arrow: 将焦点移动到上一个控件。可选:焦点从第一个控件移动到最后一个控件上。
    • Right Arrow: 将焦点移动到下一个控件。可选:焦点从最后一个控件移动到第一个控件上。
  • Home (可选地): 将焦点移动到第一个元素。
  • End (可选地): 将焦点移动到最后一个元素。
  1. 如果工具栏中的项目垂直排列:
    1. Down ArrowRight Arrow 功能一样。
    2. Up ArrowLeft Arrow 功能一样。
  2. 般来说,使用键盘进行导航时,不可用元素不可聚焦。但是,在某些需要发现功能的场景中,如果不可用元素可聚焦,可以帮助屏幕阅读器用户发现这些功能的存在。相关指导信息,请参阅
  3. 在应用程序中,快速访问工具栏非常重要,例如,从编辑器的文本区域快速访问到编辑器的工具栏,建议使用文档快捷键,从相关上下文中移动焦点到对应工具栏。

WAI-WRIA 角色、状态和属性

  • 用于工具栏容器的元素设置role为 toolbar
  • 如果工具栏有可视的标签,它被工具栏元素上的 aria-labelledby 引用。否则,工具栏元素具有由 aria-label提供的标签。
  • 如果工具栏控件是垂直排列的,工具栏元素应该设置 aria-orientationvertical。其默认值为 horizontal。

工具提示

NOTE: 有关此设计模式的工作正在进行中,并记录于 issue 128.。 如有问题,请在该问题中提供反馈。

Tooltip是元素获得键盘焦点或鼠标悬停在其上时,显示的与元素相关的信息弹窗。它通常在一小段延迟后出现,并在 Escape 按下或鼠标移出时消失。

Tooltip组件不会获得焦点。包含可聚焦元素的悬停可以使用非模态对话框模式实现。

示例

issue 127. 记录着工具提示示例的进展。

键盘交互

Escape: 关闭工具提示框。

  1. 当工具提示组件显示时,焦点停留在触发元素上。
  2. 如果当触发元素获得焦点时唤起工具提示组件,当元素失去焦点时(onBlur),工具提示组件消失。如果鼠标移入唤起工具提示组件,则鼠标移出时消失。

WAI-ARIA 角色,状态和属性

  • 作为工具提示组件容器的元素具有角色 tooltip
  • 触发工具提示组件的元素使用 aria-describedby 索引工具提示组件元素。

树视图

一个树视图呈现为一个分层列表。层次结构中的任何项目都可能有子项,并且有子项的元素,可以展开或折叠来显示或隐藏子项。例如,在使用树视图显示文件夹和文件的文件系统导航器中,代表文件夹的项目能够被展开文件夹中的内容,这些内容可能是文件、文件夹,或两者都有。

理解的树视图的一些术语包括:

节点
在树结构中的项目。
根结点
在树结构根部的节点;它可以具有一个或多个子节点,但不具有父节点。
子节点
有一个父节点的节点;任意节点如果不是根节点,那它就是一个子节点。
终端节点
不具有任何子节点的节点;一个终端节点要么是根节点要么是子节点。
父节点
有一个或多个子节点的节点。它可以是打开的(扩展)或关闭的(折叠)。
开节点
被展开以使其子节点可见的父节点。
闭节点
被折叠以使其子节点不可见的父节点。

当使用键盘来导航一个树结构,一个可见的键盘指示器告诉用户哪个节点被聚焦。如果树结构允许用户一个动作只选择一个项目,那么它被称为单选择树(single-select tree),而且被聚焦的项目还有一个被选中的状态。但是,在多选择树(multi-select trees)中,允许用户一次性选择多个项目,其选择状态与焦点无关。例如,在一个典型文件系统导航器中,用户可以一次性地移动焦点来选择任意数量的文件,例如复制或移动。为已选定和具有焦点的项目提供视觉上的设计区分,这非常重要。有关详细信息,请参阅 this description of differences between focus and selection

示例

键盘交互

对于垂直方向的树结构:

  • 当单选树接收到焦点:
    • 如果树结构接收焦点之前没有任何节点被选择,则焦点设置在第一个节点上。
    • 如果树结构获得焦点之前有一个节点被选择,则焦点设置在被选择的节点上。
  • 当多选树接收到焦点:
    • 如果树结构接收焦点之前没有任何一个节点被选择,则焦点设置在第一个节点上。
    • 如果树结构接收焦点之前有一个或多个节点被选择,则焦点设置在第一个被选择的节点上。
  • Right arrow:
    • When focus is on a closed node, opens the node; focus does not move.
    • When focus is on a open node, moves focus to the first child node.
    • When focus is on an end node, does nothing.
  • Left arrow:
    • 当焦点是在一个闭节点上,打开这个节点; 焦点不会移动。
    • 当焦点在一个同时也是终端节点或闭节点的子节点上,将焦点移动到它的父节点。
    • 当焦点一个是同时也是终端节点或闭节点的根节点上,什么也不做。
  • Down Arrow: 不打开或关闭节点,将焦点移到下一个可聚焦的节点。
  • Up Arrow: 不打开或关闭节点,将焦点移到上一个可聚焦的节点。
  • Home: 不打开或关闭节点,将焦点移到树结构中的第一个可聚焦的节点。
  • End: 不打开或关闭节点,将焦点移到树结构的最后一个可聚焦的节点。
  • Enter: 激活一个节点,即执行其默认操作。对于父节点,一个可能的默认动作是打开或关闭节点。在一个选项不跟随焦点(见下面的注释)的单选树,默认的操作通常是选择焦点节点。
  • 建议所有的树结构支持提前键入,特别是对于包含超过7个根节点的树结构:
    • 键入一个字符:焦点移动到下一个名称以输入的字符开头的节点。
    • 快速连续键入多个字符:焦点移动到下一个名称以输入的字符串开头的节点。
  • * (可选地): 展开与当前节点在同一层级的所有兄弟节点。
  • 在多选树中选择:作者可使用以下两种交互模式以支持多选:推荐的模式,用户正在浏览列表时不要求用户按住辅助键,如 ShiftControl ,或另一种模式,当浏览时要求按住辅助键,以避免丢失选择状态。
    • 推荐选择模型 - 当移动焦点时按住辅助键是没有必要的:
      • Space: 切换聚焦节点的选择状态。
      • Shift + Down Arrow (可选地): 将焦点移到下一个节点,并且切换下一个节点的选择状态。
      • Shift + Up Arrow (可选地): 将焦点移到上一个节点,并且切换上一个节点的选择状态。
      • Shift + Space (可选地): 选择从最后选择的节点到当前节点的相邻节点。
      • Control + Shift + Home (可选地): 选择具有焦点的节点以及它到第一个节点的所有节点。
      • Control + Shift + End (可选地): 选择具有焦点的节点以及它到最后一个节点的所有节点。
      • Control + A (可选地): 选择在树结构中的所有节点。根据需要,如果选择了所有的节点,它也可以取消选择所有节点。
    • 备选选择模型 - 移动焦点时不按住 ShiftControl 辅助键,会取消选中节点,聚焦的节点除外:
      • Shift + Down Arrow: 将焦点移到下一个节点,并且切换下一个节点的选择状态。
      • Shift + Up Arrow: 将焦点移到上一个节点,并且切换上一个节点的选择状态。
      • Control + Down Arrow: 不改变选择状态,将焦点移动到下一个节点。
      • Control + Up Arrow: 不改变选择状态,将焦点移动到前一个节点。
      • Control + Space: 切换聚焦节点的选择状态。
      • Shift + Space (可选地): 选择从最近选择的节点到当前节点的相邻节点。
      • Control + Shift + Home (可选地): 选择从焦点节点到第一个节点的所有节点。
      • Control + Shift + End (可选地): 选择焦点节点到最后一个节点的所有节点。
      • Control + A (可选地): 选择在树结构中的所有节点。根据需要,如果所有的节点都被选择了,它也可以取消选择所有节点。
  1. DOM焦点(激活的元素)与选择的状态在功能上是有区别的。有关详细信息,请参阅 this description of differences between focus and selection.
  2. tree 角色支持 aria-activedescendant 属性,它提供了另一种使用键盘导航在treeitem元素间移动DOM焦点的方式。有关详细信息,请参阅 Managing Focus in Composites Using aria-activedescendant
  3. 在单选树中,移动焦点可以取消选择之前选择的节点,并选择新聚焦的节点。这种选择模式被称为 "选择跟随焦点(selection follows focus)"。选择跟随焦点在某些情况下非常有用,在其他情况下则会严重降低可访问性。有关更多的指南,请参阅 Deciding When to Make Selection Automatically Follow Focus
  4. 如果选择或取消选择所有节点是一个重要的功能,实现单独控制这些行为,如 "全选" 和 "取消全选" 按钮,可显著提高可用性。
  5. 如果在一个树结构中的节点被水平地布置:
    1. Down Arrow 的表现如上面描述的 Right Arrow 一样,反之亦然。
    2. Up Arrow 的表现如上面描述的 Left Arrow 一样,反之亦然。

WAI-ARIA 角色,状态和属性

  • 所有树节点都包含在或被角色为 tree 的元素所包含。
  • 作为树节点的每个元素都有 treeitem 角色。
  • 每一个根节点包含在角色为 tree 的元素或被设置了 aria-owns 的属性的 tree元素引用。
  • 每个父节点包含或拥有 group 角色的元素。
  • 每个子节点都包含在一个角色为 group 的元素中,或者被其拥有,该元素包含在节点中,或者由作为该子节点的父节点的节点拥有。
  • 每个作为父节点拥有 treeitem 的元素 aria-expanded 设置为 false,当节点处于关闭状态,并设置为 true 时,该节点是在打开状态。终端节点没有 aria-expanded 属性,因为,如果他们有,他们会被辅助技术错误地描述为父节点。
  • 如果树支持多个节点的选择,拥有角色 tree 的元素拥有设置为 true 值的 aria-multiselectable 属性。否则,aria-multiselectable 要么是设置为 false 或使用默认值 false
  • 如果树不支持多选, 选中节点的 aria-selected 被设置为 true 并且该属性不存在于树中的任何其它节点。
  • 如果树支持多种选择:
  • 拥有角色 tree 的元素拥有被 aria-labelledby 引用的可见标签或拥有指定值的 aria-label 属性 。
  • 如果由于用户移动焦点或滚动树结构引起的动态加载,DOM中不存在完整的可用节点集合,每个节点拥有指定值的 aria-levelaria-setsizearia-posinset
  • 如果 tree 元素是水平方向的,它的 aria-orientation 设置为 horizontal。一个树结构的 aria-orientation 默认值是 vertical

如果 aria-owns 设置在树容器上,以包含不是该容器DOM子元素的元素,这些元素会按它们被引用的顺序出现在读取序列中,并且在所有属于该容器的DOM子元素之后。用于管理焦点的脚本需要确保视觉焦点与这个辅助技术读取顺序相匹配。

Window Splitter

NOTE: ARIA 1.1 introduced changes to the separator role so it behaves as a widget when focusable. While this pattern has been revised to match the ARIA 1.1 specification, the task force will not complete its review until a functional example that matches the ARIA 1.1 specification is complete. Progress on this pattern is tracked by issue 129.

A window splitter is a moveable separator between two sections, or panes, of a window that enables users to change the relative size of the panes. A Window Splitter can be either variable or fixed. A fixed splitter toggles between two positions whereas a variable splitter can be adjusted to any position within an allowed range.

A window splitter has a value that represents the size of one of the panes, which, in this pattern, is called the primary pane. When the splitter has its minimum value, the primary pane has its smallest size and the secondary pane has its largest size. The splitter also has an accessible name that matches the name of the primary pane.

For example, consider a book reading application with a primary pane for the table of contents and a secondary pane that displays content from a section of the book. The two panes are divided by a vertical splitter labeled "Table of Contents". When the table of contents pane has its maximum size, the splitter has a value of 100, and when the table of contents is completely collapsed, the splitter has a value of 0.

Note that the term "primary pane" does not describe the importance or purpose of content inside the pane.

Example

Work to develop an example window splitter widget is tracked by issue 130.

Keyboard Interaction

  • Left Arrow: Moves a vertical splitter to the left.
  • Right Arrow: Moves a vertical splitter to the right.
  • Up Arrow: Moves a horizontal splitter up.
  • Down Arrow: Moves a horizontal splitter down.
  • Enter: If the primary pane is not collapsed, collapses the pane. If the pane is collapsed, restores the splitter to its previous position.
  • Home (Optional): Moves splitter to the position that gives the primary pane its smallest allowed size. This may completely collapse the primary pane.
  • End (Optional): Moves splitter to the position that gives the primary pane its largest allowed size. This may completely collapse the secondary pane.
  • F6 (Optional): Cycle through window panes.

A fixed size splitter omits implementation of the arrow keys.

WAI-ARIA Roles, States, and Properties

  • The element that serves as the focusable splitter has role separator.
  • The separator element has the aria-valuenow property set to a decimal value representing the current position of the separator.
  • The separator element has the aria-valuemin property set to a decimal value that represents the position where the primary pane has its minimum size. This is typically 0.
  • The separator element has the aria-valuemax property set to a decimal value that represents the position where the primary pane has its maximum size . This is typically 100.
  • If the primary pane has a visible label, it is referenced by aria-labelledby on the separator element. Otherwise, the separator element has a label provided by aria-label.
  • The separator element has aria-controls referring to the primary pane.

Landmark Regions

ARIA界标角色提供一个强大的方式来标识Web页面的组织和结构。通过对页面进行分类和标记,它们让视觉传递的结构布局信息可以被编程式呈现。屏幕阅读器利用界标角色,为页面中的重要部分提供键盘导航。界标区域还可用作 "跳过链接" 的目标,并且可被浏览器扩展用来增强键盘导航。

本节介绍了HTML5分区元素以及ARIA界标角色是如何让辅助技术用户更容易地理解页面布局的含义。

HTML5 分区元素

一些HTML5分区元素会自动创建ARIA界标区域。所以,为了提供给辅助技术用户页面的逻辑视图,理解使用HTML5分区元素的作用非常重要。关于HTML5元素角色映射的更多信息

HTML5分区元素默认界标角色
HTML5 Element Default Landmark Role
aside complementary
footer contentinfobody 元素中时
header bannerbody 元素中时
main main
nav navigation
section region 当使用 aria-labelledbyaria-label 提供可访问名称时

界标元素设计的基本原则

将页面中的 所有内容 都包含页面中任一界标区域中,并且给予每个界标区域一个有意义的语义角色,这是保证辅助技术用户不会忽略与其需要相关内容的最有效的方式之一。

步骤1:识别逻辑结构

步骤2:为每个区域分配界标角色

步骤3:标识区域

界标角色

Banner

banner 界标在网站每个页面的开头标识了站点推广的内容。 站点推广的内容一般包含LOGO或网站赞助商的标识,和网站特定的搜索工具。Banner一般出现在页面的顶端,并且横跨整个页面。

  • 每个页面可能都有一个 banner 界标。
  • banner 界标。
  • 当一个页面包含内嵌 document 和/或 application 角色时(例如,一般在使用 iframeframe 时),每个 documentapplication 角色可能都有一个 banner 界标。
  • 如果一个页面包含超过一个 banner 界标,每个banner都应该有一个唯一的标签。
HTML5 技术
  • 当其上下文是 body 元素时,HTML5 header 元素定义了 banner 界标。
  • 当HTML5 header 元素是以下任何元素的后代时,其不被视为 banner 界标(请参阅 HTML辅助功能映射):
    • article
    • aside
    • main
    • nav
    • section
ARIA 技术

如果未使用HTML5 header 元素技巧,应该使用 role="banner" 属性来定义 banner 界标。

示例

banner 界标示例

补充

complementary 界标是文档的支持部分,旨在补充DOM层次结构中类似级别的主要内容,但与主要内容分离时仍然有意义。

  • complementary 界标是文档的支持部分,被设计用来为DOM层级中类似层级的主要内容提供补充,而且与主内容分离仍然有意义。
  • 如果补充内容与主内容无关,应该分配一个更一般的角色(例如, region)。
  • 如果页面中 complementary 界标超过一个,每个都应该有一个唯一的标签(请查阅 步骤3:标识区域)。
HTML5 技术

使用HTML5 aside 元素定义 complementary 界标。

ARIA 技术

如果未使用HTML5 aside,请使用 role="complementary" 属性来定义 complementary 界标。

示例

补充界标示例

Contentinfo

contentinfo 界标位于网站每个页面的底部,是一种定义常用信息的方式,一般被称为 "footer" ,包含版权、隐私链接和无障碍状态等的信息。

  • 每个页面可能包含一个 contentinfo 界标。
  • contentinfo 界标。
  • 当一个页面包含内嵌 document 和/或 application 角色时(例如,一般在使用 iframeframe 时),每个 documentapplication 角色可能都有一个 contentinfo 界标。
  • 如果页面中的 contentinfo 界标超过一个,每个都应该有一个唯一的标签(请查阅 步骤3:标识区域)。
HTML5 技术
  • 当上下文是 body 元素时,HTML5 footer 元素定义了 contentinfo 界标。
  • 当它是以下任何元素的后代时,HTML5 footer 元素不被视为 contentinfo 界标。(请查阅 HTML 辅助功能映射):
    • article
    • aside
    • main
    • nav
    • section
ARIA 技术

如果未使用HTML5 footer 元素,则应使用 role="contentinfo" 来定义 contentinfo 界标。

示例

Contentinfo 界标示例

Form

form 界标(例如 main 或 search )都不合适时,这些项目和对象整合成一个表单。

  • 当表单用于搜索功能时,使用 search 界标代替 form 界标。
  • 一个 form 界标应该有一个标签,来帮助用户理解表单目的。
  • form 界标的标签应该所有用户可见(例如,h1-h6 元素)。
  • 如果一个页面包含的 form 界标超过一个,每个都应该有一个唯一的标签。(请查阅 步骤3:标识区域)
  • 只要有可能,HTML文档的 form 界标中包含的控件应该使用原生语义元素:
    • button
    • input
    • select
    • textarea
HTML5 技术

HTML5 form 元素 form 在具有可访问名称(例如 aria-labelledbyaria-labeltitle)时定义为界标。

ARIA 技术

使用 role="form" 来标识页面中的区域;不要使用form来标识每个表单字段。

示例

form 界标示例

Main

main 界标标识了页面的主要内容。

  • 每个页面都应该有一个 main 界标。
  • main 界标。
  • 当一个页面包含内嵌 document 和/或 application 角色时(例如,一般在使用 iframeframe 时),每个 documentapplication 角色可能都有一个 main 界标。
  • 如果页面包含的 main 界标超过一个,每个都应该有一个唯一的标签。(请查阅 步骤3:标识区域)
HTML5 技术

使用HTML5 main 元素定义 main 界标。

ARIA 技术

如果未使用HTML5 main 元素技术,使用 role="main" 属性来定义一个 main 界标。

示例

Main 界标示例

Navigation

Navigation 界标提供了一种标识链接组(例如 列表)方法,该链接组被用于网站或页面的导航。

  • 如果页面包含的 navigation 界标超过一个,每个都应该有一个唯一的标签。(请查阅 步骤3:标识区域)
  • 如果一个 navigation 界标与页面中另一个 navigation 界标的链接组相同,每个 navigation 界标使用相同的标签。
HTML5 技术

使用HTML5 nav 元素定义一个 navigation 界标。Use the HTML5 nav element to define a navigation landmark.

ARIA 技术

如果未使用HTML5 nav 元素,使用 role="navigation" 属性来定义 navigation 界标。

示例

Navigation 界标示例

Region

region 界标是页面中的可感知部分,其内容对用户来说足够重要,且用户能够导航到该部分。

  • region 界标必须有标签。
  • 如果页面中包含多个 region 界标,则每个都应该有一个唯一的标签。
  • region 界标适当描述的内容。
HTML5 技术

使用HTML5 section 元素定义 region 界标。

ARIA 技术

如果未使用HTML5 section 元素,请使用 role="region" 属性来定义 region 界标。

示例

Region 界标示例

Developing a Keyboard Interface

Unlike native HTML form elements, browsers do not provide keyboard support for graphical user interface (GUI) components that are made accessible with ARIA; authors have to provide the keyboard support in their code. This section describes the principles and methods for making the functionality of a web page that includes ARIA widgets, such as menus and grids, as well as interactive components, such as toolbars and dialogs, operable with a keyboard. Along with the basics of focus management, this section offers guidance toward the objective of providing experiences to people who rely on a keyboard that are as efficient and enjoyable as the experiences available to others.

This section covers:

  1. Understanding fundamental principles of focus movement conventions used in ARIA design patterns.
  2. Maintaining visible focus, predictable focus movement, and distinguishing between keyboard focus and the selected state.
  3. Managing movement of keyboard focus between components, e.g., how the focus moves when the Tab and Shift+Tab keys are pressed.
  4. Managing movement of keyboard focus inside components that contain multiple focusable elements, e.g., two different methods for programmatically exposing focus inside widgets like radio groups, menus, listboxes, trees, and grids.
  5. Determining when to make disabled interactive elements focusable.
  6. Assigning and revealing keyboard shortcuts, including guidance on how to avoid problematic conflicts with keyboard commands of assistive technologies, browsers, and operating systems.

Fundamental Keyboard Navigation Conventions

ARIA roles, states, and properties model accessibility behaviors and features shared among GUI components of popular desktop GUIs, including Microsoft Windows, macOS, and GNOME. Similarly, ARIA design patterns borrow user expectations and keyboard conventions from those platforms, consistently incorporating common conventions with the aim of facilitating easy learning and efficient operation of keyboard interfaces across the web.

For a web page to be accessible, all interactive elements must be operable via the keyboard. In addition, consistent application of the common GUI keyboard interface conventions described in the ARIA design patterns is important, especially for assistive technology users. Consider, for example, a screen reader user operating a tree. Just as familiar visual styling helps users discover how to expand a tree branch with a mouse, ARIA attributes give the tree the sound and feel of a tree in a desktop application. So, screen reader users will commonly expect that pressing the right arrow key will expand a collapsed node. Because the screen reader knows the element is a tree, it also has the ability to instruct a novice user how to operate it. Similarly, voice recognition software can implement commands for expanding and collapsing branches because it recognizes the element as a tree and can execute appropriate keyboard commands. All this is only possible if the tree implements the GUI keyboard conventions as described in the ARIA tree pattern.

A primary keyboard navigation convention common across all platforms is that the tab and shift+tab keys move focus from one UI component to another while other keys, primarily the arrow keys, move focus inside of components that include multiple focusable elements. The path that the focus follows when pressing the tab key is known as the tab sequence or tab ring.

Common examples of UI components that contain multiple focusable elements are radio groups, tablists, menus, and grids. A radio group, for example, contains multiple radio buttons, each of which is focusable. However, only one of the radio buttons is included in the tab sequence. After pressing the Tab key moves focus to a radio button in the group, pressing arrow keys moves focus among the radio buttons in the group, and pressing the Tab key moves focus out of the radio group to the next element in the tab sequence.

The ARIA specification refers to a discrete UI component that contains multiple focusable elements as a composite widget. The process of controlling focus movement inside a composite is called managing focus. Following are some ARIA design patterns with example implementations that demonstrate focus management:

Discernible and Predictable Keyboard Focus

Work to complete this section is tracked by issue 217.

When operating with a keyboard, two essentials of a good experience are the abilities to easily discern the location of the keyboard focus and to discover where focus landed after a navigation key has been pressed. The following factors affect to what extent a web page affords users these capabilities.

  1. Visibility of the focus indicator: Users need to be able to easily distinguish the keyboard focus indicator from other features of the visual design. Just as a mouse user may move the mouse to help find the mouse pointer, a keyboard user may press a navigation key to watch for movement. If visual changes in response to focus movement are subtle, many users will lose track of focus and be unable to operate. Authors are advised to rely on the default focus indicators provided by browsers. If overriding the default, consider:
    • something about ... Colors and gradients can disappear in high contrast modes.
    • Users need to be able to easily distinguish between focus and selection as described in , especially when a component that contains selected elements does not contain the focus.
    • ... other considerations to be added ...
  2. Persistence of focus: It is essential that there is always a component within the user interface that is active (document.activeElement is not null or is not the body element) and that the active element has a visual focus indicator. Authors need to manage events that effect the currently active element so focus remains visible and moves logically. For example, if the user closes a dialog or performs a destructive operation like deleting an item from a list, the active element may be hidden or removed from the DOM. If such events are not managed to set focus on the button that triggered the dialog or on the list item following the deleted item, browsers move focus to the body element, effectively causing a loss of focus within the user interface.
  3. Predictability of movement: Usability of a keyboard interface is heavily influenced by how readily users can guess where focus will land after a navigation key is pressed. Some possible approaches to optimizing predictability include:
    • Move focus in a pattern that matches the reading order of the page's language. In left to right languages, for example, create a tab sequence that moves focus left to right and then top to bottom.
    • Incorporate all elements of a section of the page in the tab sequence before moving focus to another section. For instance, in a page with multiple columns that has content in a left side bar, center region, and right side bar, build a tab sequence that covers all elements in the left sidebar before focus moves to the first focusable element in the center column.
    • When the distance between two consecutive elements in the tab sequence is significant, avoid movement that would be perceived as backward. For example, on a page with a left to right language, a jump from the last element in the bottom right of the main content to the top element in a left-hand sidebar is likely to be less predictable and more difficult to follow, especially for users with a narrow field of view.
    • Follow consistent patterns across a site. The keyboard experience is more predictable when similar pages have similar focus movement patterns.
    • Do not set initial focus when the page loads except in cases where:
      • The page offers a single, primary function that nearly all users employ immediately after page load.
      • Any given user is likely to use the page often.

Focus VS Selection and the Perception of Dual Focus

Occasionally, it may appear as if two elements on the page have focus at the same time. For example, in a multi-select list box, when an option is selected it may be greyed. Yet, the focus indicator can still be moved to other options, which may also be selected. Similarly, when a user activates a tab in a tablist, the selected state is set on the tab and its visual appearance changes. However, the user can still navigate, moving the focus indicator elsewhere on the page while the tab retains its selected appearance and state.

Focus and selection are quite different. From the keyboard user's perspective, focus is a pointer, like a mouse pointer; it tracks the path of navigation. There is only one point of focus at any time and all operations take place at the point of focus. On the other hand, selection is an operation that can be performed in some widgets, such as list boxes, trees, and tablists. If a widget supports only single selection, then only one item can be selected and very often the selected state will simply follow the focus when focus is moved inside of the widget. That is, in some widgets, moving focus may also perform the select operation. However, if the widget supports multiple selection, then more than one item can be in a selected state, and keys for moving focus do not perform selection. Some multi-select widgets do support key commands that both move focus and change selection, but those keys are different from the normal navigation keys. Finally, when focus leaves a widget that includes a selected element, the selected state persists.

From the developer's perspective, the difference is simple -- the focused element is the active element (document.activeElement). Selected elements are elements that have aria-selected="true".

With respect to focus and the selected state, the most important considerations for designers and developers are:

Deciding When to Make Selection Automatically Follow Focus

in composite widgets where only one element may be selected, such as a tablist or single-select listbox, moving the focus may also cause the focused element to become the selected element. This is called having selection follow focus. Having selection follow focus is often beneficial to users, but in some circumstances, it is extremely detrimental to accessibility.

For example, in a tablist, the selected state is used to indicate which panel is displayed. So, when selection follows focus in a tablist, moving focus from one tab to another automatically changes which panel is displayed. If the content of panels is present in the DOM, then displaying a new panel is nearly instantaneous. A keyboard user who wishes to display the fourth of six tabs can do so with 3 quick presses of the right arrow. And, a screen reader user who perceives the labels on tabs by navigating through them may efficiently read through the complete list without any latency.

However, if displaying a new panel causes a network request and possibly a page refresh, the effect of having selection automatically focus can be devastating to the experience for keyboard and screen reader users. In this case, displaying the fourth tab or reading through the list becomes a tedious and time-consuming task as the user experiences significant latency with each movement of focus. Further, if displaying a new tab refreshes the page, then the user not only has to wait for the new page to load but also return focus to the tab list.

When selection does not follow focus, the user changes which element is selected by pressing the Enter or Space key.

Keyboard Navigation Between Components (The Tab Sequence)

As explained in section , all interactive UI components need to be reachable via the keyboard. This is best achieved by either including them in the tab sequence or by making them accessible from a component that is in the tab sequence, e.g., as part of a composite component. This section addresses building and managing the tab sequence, and subsequent sections cover making focusable elements that are contained within components keyboard accessible.

The HTML tabindex and SVG tabindex attributes can be used to add and remove elements from the tab sequence. The value of tabindex can also influence the order of the tab sequence, although authors are strongly advised not to use tabindex for that purpose.

In HTML, the default tab sequence of a web page includes only links and HTML form elements, except In macOS, where it includes only form elements. macOS system preferences include a keyboard setting that enables the tab key to move focus to all focusable elements.

The default order of elements in the tab sequence is the order of elements in the DOM. The DOM order also determines screen reader reading order. It is important to keep the keyboard tab sequence and the screen reader reading order aligned, logical, and predictable as described in . The most robust method of manipulating the order of the tab sequence while also maintaining alignment with the reading order that is currently available in all browsers is rearranging elements in the DOM.

The values of the tabindex attribute have the following effects.

tabindex is not present or does not have a valid value
The element has its default focus behavior. In HTML, only form controls and anchors with an HREF attribute are included in the tab sequence.
tabindex="0"
The element is included in the tab sequence based on its position in the DOM.
tabindex="-1"
The element is not included in the tab sequence but is focusable with element.focus().
tabindex="X" where X is an integer in the range 1 <= X <= 32767
Authors are strongly advised NOT to use these values. The element is placed in the tab sequence based on the value of tabindex. Elements with a tabindex value of 0 and elements that are focusable by default will be in the sequence after elements with a tabindex value of 1 or greater.

Keyboard Navigation Inside Components

As described in section , the tab sequence should include only one focusable element of a composite UI component. Once a composite contains focus, keys other than Tab and Shift + Tab enable the user to move focus among its focusable elements. Authors are free to choose which keys move focus inside of a composite, but they are strongly advised to use the same key bindings as similar components in common GUI operating systems as demonstrated in .

The convention for where focus lands in a composite when it receives focus as a result of a Tab key event depends on the type of composite. It is typically one of the following.

The following sections explain two strategies for managing focus inside composite elements: creating a roving tabindex and using the aria-activedescendant property.

Managing Focus Within Components Using a Roving tabindex

When using roving tabindex to manage focus in a composite UI component, the element that is to be included in the tab sequence has tabindex of "0" and all other focusable elements contained in the composite have tabindex of "-1". The algorithm for the roving tabindex strategy is as follows.

  • When the component container is loaded or created, set tabindex="0" on the element that will initially be included in the tab sequence and set tabindex="-1" on all other focusable elements it contains.
  • When the component contains focus and the user presses a navigation key that moves focus within the component, such as an arrow key:
    • set tabindex="-1" on the element that has tabindex="0".
    • Set tabindex="0" on the element that will become focused as a result of the key event.
    • Set focus, element.focus(), on the element that has tabindex="0".
  • If the design calls for a specific element to be focused the next time the user moves focus into the composite with Tab or Shift+Tab, check if that target element has tabindex="0" when the composite loses focus. If it does not, set tabindex="0" on the target element and set tabindex="-1" on the element that previously had tabindex="0".

One benefit of using roving tabindex rather than aria-activedescendant to manage focus is that the user agent will scroll the newly focused element into view.

Managing Focus in Composites Using aria-activedescendant

If a component container has an ARIA role that supports the aria-activedescendant property, it is not necessary to manipulate the tabindex attribute and move DOM focus among focusable elements within the container. Instead, only the container element needs to be included in the tab sequence. When the container has DOM focus, the value of aria-activedescendant on the container tells assistive technologies which element is active within the widget. Assistive technologies will consider the element referred to as active to be the focused element even though DOM focus is on the element that has the aria-activedescendant property. And, when the value of aria-activedescendant is changed, assistive technologies will receive focus change events equivalent to those received when DOM focus actually moves.

The steps for using the aria-activedescendant method of managing focus are as follows.

  • When the container element that has a role that supports aria-activedescendant is loaded or created, ensure that:
    • The container element is included in the tab sequence as described in or is a focusable element of a composite that implements a roving tabindex.
    • It has aria-activedescendant="IDREF" where IDREF is the ID of the element within the container that should be identified as active when the widget receives focus. The referenced element needs to meet the DOM relationship requirements described below.
  • When the container element receives DOM focus, draw a visual focus indicator on the active element and ensure the active element is scrolled into view.
  • When the composite widget contains focus and the user presses a navigation key that moves focus within the widget, such as an arrow key:
    • Change the value of aria-activedescendant on the container to refer to the element that should be reported to assistive technologies as active.
    • Move the visual focus indicator and, if necessary, scrolled the active element into view.
  • If the design calls for a specific element to be focused the next time a user moves focus into the composite with Tab or Shift+Tab, check if aria-activedescendant is referring to that target element when the container loses focus. If it is not, set aria-activedescendant to refer to the target element.

The specification for aria-activedescendant places important restrictions on the DOM relationship between the focused element that has the aria-activedescendant attribute and the element referenced as active by the value of the attribute. One of the following three conditions must be met.

  1. The element referenced as active is a DOM descendant of the focused referencing element.
  2. The focused referencing element has a value specified for the aria-owns property that includes the ID of the element referenced as active.
  3. The focused referencing element has role of textbox and has aria-controls property referring to an element with a role that supports aria-activedescendant and either:
    1. The element referenced as active is a descendant of the controlled element.
    2. The controlled element has a value specified for the aria-owns property that includes the ID of the element referenced as active.

Focusability of disabled controls

By default, disabled HTML input elements are removed from the tab sequence. In most contexts, the normal expectation is that disabled interactive elements are not focusable. However, there are some contexts where it is common for disabled elements to be focusable, especially inside of composite widgets. For example, as demonstrated in the pattern, disabled items are focusable when navigating through a menu with the arrow keys.

Removing focusability from disabled elements can offer users both advantages and disadvantages. Allowing keyboard users to skip disabled elements usually reduces the number of key presses required to complete a task. However, preventing focus from moving to disabled elements can hide their presence from screen reader users who "see" by moving the focus.

Authors are encouraged to adopt a consistent set of conventions for the focusability of disabled elements. The examples in this guide adopt the following conventions, which both reflect common practice and attempt to balance competing concerns.

  1. For elements that are in the tab sequence when enabled, remove them from the tab sequence when disabled.
  2. For the following composite widget elements, keep them focusable when disabled:
  3. For elements contained in a toolbar, make them focusable if discoverability is a concern. Here are two examples to aid with this judgment.
    1. A toolbar with buttons for moving, removing, and adding items in a list includes buttons for "Up", "Down", "Add", and "Remove". The "Up" button is disabled and its focusability is removed when the first item in the list is selected. Given the presence of the "Down" button, discoverability of the "Up" button is not a concern.
    2. A toolbar in an editor contains a set of special smart paste functions that are disabled when the clipboard is empty or when the function is not applicable to the current content of the clipboard. It could be helpful to keep the disabled buttons focusable if the ability to discover their functionality is primarily via their presence on the toolbar.

One design technique for mitigating the impact of including disabled elements in the path of keyboard focus is employing appropriate keyboard shortcuts as described in .

Key Assignment Conventions for Common Functions

The following key assignments can be used in any context where their conventionally associated functions are appropriate. While the assignments associated with Windows and Linux platforms can be implemented and used in browsers running in macOS, replacing them with macOS assignments in browsers running on a macOS device can make the keyboard interface more discoverable and intuitive for those users. In some cases, it may also help avoid system or browser keyboard conflicts.

Function Windows/Linux Key macOS Key
open context menu Shift + F10
Copy to clipboard Control + C Command + C
Paste from clipboard Control + V Command + V
Cut to clipboard Control + X Command + X
undo last action Control + Z Command + Z
Redo action Control + Y Command + Shift + Z

Keyboard Shortcuts

When effectively designed, keyboard shortcuts that focus an element, activate a widget, or both can dramatically enhance usability of frequently used features of a page or site. This section addresses some of the keyboard shortcut design and implementation factors that most impact their effectiveness, including:

  1. Understanding how keyboard shortcuts augment a keyboard interface and whether to make a particular shortcut move focus, perform a function, or both.
  2. Making key assignments and avoiding assignment conflicts with assistive technologies, browsers, and operating systems.
  3. Exposing and documenting key assignments.

Designing the Scope and Behavior of Keyboard Shortcuts

This section explains the following factors when determining which elements and features to assign keyboard shortcuts and what behavior to give each shortcut:

  1. Ensuring discovery through navigation; keyboard shortcuts enhance, not replace, standard keyboard access.
  2. Effectively choosing from among the following behaviors:
    1. Navigation: Moving focus to an element.
    2. Activation: Performing an operation associated with an element that does not have focus and might not be visible.
    3. Navigation and activation: Both moving focus to an element and activating it.
  3. Balancing efficiency and cognitive load: lack of a shortcut can reduce efficiency while too many shortcuts can increase cognitive load and clutter the experience.
Ensure Basic Access Via Navigation

Before assigning keyboard shortcuts, it is essential to ensure the features and functions to which shortcuts may be assigned are keyboard accessible without a keyboard shortcut. In other words, all elements that could be targets for keyboard shortcuts need to be focusable via the keyboard using the methods described in:

Do not use keyboard shortcuts as a substitute for access via navigation. This is essential to full keyboard access because:

  1. The primary means of making functions and their shortcuts discoverable is by making the target elements focusable and revealing key assignments on the element itself.
  2. If people who rely on the keyboard have to read documentation to learn which keys are required to use an interface, the interface may technically meet some accessibility standards but in practice is only accessible to the small subset of them who have the knowledge that such documentation exists, have the extra time available, and the ability to retain the necessary information.
  3. Not all devices that depend on keyboard interfaces can support keyboard shortcuts.
Choose Appropriate Shortcut Behavior

The following conventions may help identify the most advantageous behavior for a keyboard shortcut.

  • Move focus when the primary objective is to make navigation more efficient, e.g., reduce the number of times the user must press Tab or the arrow keys. This behavior is commonly expected when assigning a shortcut to a text box, toolbar, or composite, such as a listbox, tree, grid, or menubar. This behavior is also useful for moving focus to a section of a page, such as the main content or a complementary landmark section.
  • Activate an element without moving focus when the target context of the function is the context that contains the focus. This behavior is most common for command buttons and for functions associated with elements that are not visible, such as a "Save" option that is accessible via a menu. For example, if the focus is on an option in a listbox and a toolbar contains buttons for moving and removing options, it is most beneficial to keep focus in the listbox when the user presses a key shortcut for one of the buttons in the toolbar. This behavior can be particularly important for screen reader users because it provides confirmation of the action performed and makes performing multiple commands more efficient. For instance, when a screen reader user presses the shortcut for the "Up" button, the user will be able to hear the new position of the option in the list since it still has the focus. Similarly, when the user presses the shortcut for deleting an option, the user can hear the next option in the list and immediately decide whether to press the delete shortcut again.
  • Move focus and activate when the target of the shortcut has a single function and the context of that function is the same as the target. This behavior is typical when a shortcut is assigned to a button that opens a menu or dialog, to a checkbox, or to a navigation link or button.
Choose Where to Add Shortcuts

Work to draft content for this section is tracked in issue 219.

The first goal when designing a keyboard interface is simple, efficient, and intuitive operation with only basic keyboard navigation support. If basic operation of a keyboard interface is inefficient , attempting to compensate for fundamental design issues, such as suboptimal layout or command structure, by implementing keyboard shortcuts will not likely reduce user frustration. The practical implication of this is that, in most well-designed user interfaces, the percentage of functionality that needs to be accessible via a keyboard shortcut in order to create optimal usability is not very high. In many simple user interfaces, keyboard shortcuts can be entirely superfluous. And, in user interfaces with too many keyboard shortcuts, the excess shortcuts create cognitive load that make the most useful ones more difficult to remember.

Consider the following when deciding where to assign keyboard shortcuts:

  1. To be written.

Assigning Keyboard Shortcuts

When choosing the keys to assign to a shortcut, there are many factors to consider.

  • Making the shortcut easy to learn and remember by using a mnemonic (e.g., Control + S for "Save") or following a logical or spacial pattern.
  • Localizing the interface, including for differences in which keys are available and how they behave and for language considerations that could impact mnemonics.
  • Avoiding and managing conflicts with key assignments used by an assistive technology, the browser, or the operating system.

Methods for designing a key shortcut scheme that supports learning and memory is beyond the scope of this guide. Unless the key shortcut scheme is extensive, it is likely sufficient to mimic concepts that are familiar from common desktop software, such as browsers. Similarly, while localization is important, describing how to address it is left to other resources that specialize in that topic.

The remainder of this section provides guidance balancing requirements and concerns related to key assignment conflicts. It is typically ideal if key assignments do not conflict with keys that are assigned to functions in the user's operating system, browser, or assistive technology. Conflicts can block efficient access to functions that are essential to the user, and a perfect storm of conflicts can trap a user. At the same time, there are some circumstances where intentional conflicts are useful. And, given the vast array of operating system, browser, and assistive technology keys, it is almost impossible to be certain conflicts do not exist. So it is also important to employ strategies that mitigate the impact of conflicts whether they are intentional or unknown.

In the following sections, meta key refers to the Windows key on Windows-compatible keyboards and the Command key on MacOS-compatible keyboards.

Operating System Key Conflicts

It is essential to avoid conflicts with keys that perform system level functions, such as application and window management and display and sound control. In general, this can be achieved by refraining from the following types of assignments.

  1. Any modifier keys + any of Tab, Enter, Space, or Escape.
  2. Meta key + any other single key (there are exceptions, but they can be risky as these keys can change across versions of operating systems).
  3. Alt + a function key.

In addition, there are some important application level features that most applications, including browsers, generally support. These include:

  1. Zoom
  2. Copy/Paste
  3. ... to be continued ...
Assistive Technology Key Conflicts

Even though assistive technologies have collectively taken thousands of key assignments, avoiding conflicts is relatively easy. This is because assistive technologies have had to develop key assignment schemes that avoid conflicts with both operating systems and applications. They do this by hijacking specific keys as modifiers that uniquely define their key commands. For example, many assistive technologies use the Caps Lock key as a modifier.

Deflect assistive technology key conflicts by steering clear of the following types of assignments.

  1. Caps Lock + any other combination of keys.
  2. Insert + any combination of other keys.
  3. Scroll Lock + any combination of other keys.
  4. macOS only: Control+Option + any combination of other keys.
Browser Key Conflicts

While there is considerable similarity among browser keyboard schemes, the patterns within the schemes are less homogenous. Consequently, it is more difficult to avoid conflicts with browser key assignments. While the impact of conflicts is sometimes mitigated by the availability of two paths to nearly every function -- keyboard accessible menus and keyboard shortcuts, avoiding conflicts with shortcuts to heavily used functions is nonetheless important. Pay special attention to avoiding conflicts with shortcuts to:

  1. Address or location bar
  2. Notification bar
  3. Page refresh
  4. Bookmark and history functions
  5. Find functions
Intentional Key Conflicts

While avoiding key conflicts is usually desirable, there are circumstances where intentionally conflicting with a browser function is acceptable or even desirable. This can occur when the following combination of conditions arises:

  • A web application has a frequently used function that is similar to a browser function.
  • Users will often want to execute the web application function.
  • Users will rarely execute the browser function.
  • There is an efficient, alternative path to the browser function.

For example, consider a save function that is available when the focus is in an editor. Most browsers use ... to be continued ...

Grid and Table Properties

To fully present and describe a grid or table, in addition to parsing the headers, rows, and cells using the roles described in the grid pattern or table pattern, assistive technologies need to be able to determine:

Browsers automatically populate their accessibility tree with the number of rows and columns in a grid or table based on the rendered DOM. However, there are many situations where the DOM does not contain the whole grid or table, such as when the data set is too large to fully render. Additionally, some of this information, like skipped columns or rows and how data is sorted, cannot be derived from the DOM structure.

The below sections explain how to use the following properties that ARIA provides for grid and table accessibility.

Grid and Table Property Definitions
Property Definition
aria-colcount Defines the total number of columns in a table, grid, or treegrid.
aria-rowcount Defines the total number of rows in a table, grid, or treegrid.
aria-colindex
  • Defines a cell's position with respect to the total number of columns within a table, grid, or treegrid.
  • Note: Numbering starts with 1, not 0.
aria-rowindex
  • Defines a cell's position with respect to the total number of rows within a table, grid, or treegrid.
  • Note: Numbering starts with 1, not 0.
aria-colspan Defines the number of columns spanned by a cell or gridcell within a table, grid, or treegrid.
aria-rowspan Defines the number of rows spanned by a cell or gridcell within a table, grid, or treegrid.
aria-sort Indicates if items in a row or column are sorted in ascending or descending order.

Using aria-rowcount and aria-rowindex

When the number of rows represented by the DOM structure is not the total number of rows available for a table, grid, or treegrid, the aria-rowcount property is used to communicate the total number of rows available, and it is accompanied by the aria-rowindex property to identify the row indices of the rows that are present in the DOM.

The aria-rowcount is specified on the element with the table, grid, or treegrid role. Its value is an integer equal to the total number of rows available, including header rows. If the total number of rows is unknown, a value of -1 may be specified. Using a value of -1 indicates that more rows are available to include in the DOM without specifying the size of the available supply.

When aria-rowcount is used on a table, grid, or treegrid, a value for aria-rowindex property is specified on each of its descendant rows, including any header rows. The value of aria-rowindex is an integer that is:

  1. Greater than or equal to 1.
  2. Greater than the value of aria-rowindex on any previous rows.
  3. Set to the index of the first row in the span if cells span multiple rows.
  4. Less than or equal to the total number of rows.

WARNING! Missing or inconsistent values of aria-rowindex could have devastating effects on assistive technology behavior. For example, specifying an invalid value for aria-rowindex or setting it on some but not all rows in a table, could cause screen reader table reading functions to skip rows or simply stop functioning.

The following code demonstrates the use of aria-rowcount and aria-rowindex properties on a table containing a a hypothetical class list.

        
          <!--
            aria-rowcount tells assistive technologies the actual size of the grid
            is 463 rows even though only 4 rows are present in the markup.
          -->
          <table role="grid" aria-rowcount="463">
            aria-label="Student roster for history 101"
            <thead>
              <tr aria-rowindex="1">
                <th>Last Name</th>
                <th>First Name</th>
                <th>E-mail</th>
                <th>Major</th>
                <th>Minor</th>
                <th>Standing</th>
              </tr>
            </thead>
            <tbody>
                <!--
                  aria-rowindex tells assistive technologies that this
                  row is row 51 in the grid of 463 rows.
                -->
              <tr aria-rowindex="51">
                <td>Henderson</td>
                <td>Alan</td>
                <td>ahederson56@myuniveristy.edu</td>
                <td>Business</td>
                <td>Spanish</td>
                <td>Junior</td>
              </tr>
                <!--
                  aria-rowindex tells assistive technologies that this
                  row is row 52 in the grid of 463 rows.
                -->
              <tr aria-rowindex="52">
                <td>Henderson</td>
                <td>Alice</td>
                <td>ahederson345@myuniveristy.edu</td>
                <td>Engineering</td>
                <td>none</td>
                <td>Sophomore</td>
              </tr>
                <!--
                  aria-rowindex tells assistive technologies that this
                  row is row 53 in the grid of 463 rows.
                -->
              <tr aria-rowindex="53">
                <td>Henderson</td>
                <td>Andrew</td>
                <td>ahederson75@myuniveristy.edu</td>
                <td>General Studies</td>
                <td>none</td>
                <td>Freshman</td>
              </tr>
            </tbody>
          </table>
        
      

Using aria-colcount and aria-colindex

When the number of columns represented by the DOM structure is not the total number of columns available for a table, grid, or treegrid, the aria-colcount property is used to communicate the total number of columns available, and it is accompanied by the aria-colindex property to identify the column indices of the columns that are present in the DOM.

The aria-colcount is specified on the element with the table, grid, or treegrid role. Its value is an integer equal to the total number of columns available. If the total number of columns is unknown, a value of -1 may be specified. Using a value of -1 indicates that more columns are available to include in the DOM without specifying the size of the available supply.

When aria-colcount is used on a table, grid, or treegrid, a value for aria-colindex property is either specified on each of its descendant rows or on every cell in each descendant row, depending on whether the columns are contiguous as described below. The value of aria-colindex is an integer that is:

  1. Greater than or equal to 1.
  2. When set on a cell, greater than the value set on any previous cell within the same row.
  3. Set to the index of the first column in the span if a cell spans multiple columns.
  4. Less than or equal to the total number of columns.

WARNING! Missing or inconsistent values of aria-colindex could have devastating effects on assistive technology behavior. For example, specifying an invalid value for aria-colindex or setting it on some but not all cells in a row, could cause screen reader table reading functions to skip cells or simply stop functioning.

Using aria-colindex When Column Indicies Are Contiguous

When all the cells in a row have column index numbers that are consecutive integers, aria-colindex can be set on the row element with a value equal to the the index number of the first column in the set. Browsers will then compute a column number for each cell in the row.

The following code shows a grid with 16 columns, of which columns 2 through 5 are displayed to the user. Because the set of columns is contiguous, aria-colindex can be placed on each row.

        
<div role="grid" aria-colcount="16">
  <div role="rowgroup">
    <div role="row" aria-colindex="2">
      <span role="columnheader">First Name</span>
      <span role="columnheader">Last Name</span>
      <span role="columnheader">Company</span>
      <span role="columnheader">Address</span>
    </div>
  </div>
  <div role="rowgroup">
    <div role="row" aria-colindex="2">
      <span role="gridcell">Fred</span>
      <span role="gridcell">Jackson</span>
      <span role="gridcell">Acme, Inc.</span>
      <span role="gridcell">123 Broad St.</span>
    </div>
    <div role="row" aria-colindex="2">
      <span role="gridcell">Sara</span>
      <span role="gridcell">James</span>
      <span role="gridcell">Acme, Inc.</span>
      <span role="gridcell">123 Broad St.</span>
    </div>
   …
  </div>
</div>

Using aria-colindex When Column Indicies Are Not Contiguous

When the cells in a row have column index numbers that are not consecutive integers, aria-colindex needs to be set on each cell in the row. The following example shows a grid for an online grade book where the first two columns contain a student name and subsequent columns contain scores. In this example, the first two columns with the student name are shown, but the score columns have been scrolled to show columns 10 through 13. Columns 3 through 9 are not visible so are not in the DOM.

          
            <table role="grid" aria-rowcount="463" aria-colcount="13">
              aria-label="Student grades for history 101"
              <!--
                aria-rowcount and aria-colcount tell assistive technologies
                the actual size of the grid is 463 rows by 13 columns,
                which is not the number rows and columns found in the markup.
              -->
              <thead>
                <tr aria-rowindex="1">
                  <!--
                    aria-colindex tells assistive technologies that the
                    following columns represent columns 1 and 2 of the total data set.
                  -->
                  <th aria-colindex="1">Last Name</th>
                  <th aria-colindex="2">First Name</th>
                  <!--
                    aria-colindex tells users of assistive technologies that the
                    following columns represent columns 10, 11, 12, and 13 of
                    the overall data set of grades.
                  -->
                  <th aria-colindex="10">Homework 4</th>
                  <th aria-colindex="11">Quiz 2</th>
                  <th aria-colindex="12">Homework 5</th>
                  <th aria-colindex="13">Homework 6</th>
                </tr>
              </thead>
              <tbody>
                <tr aria-rowindex="50">
                  <!--
                    every cell needs to define the aria-colindex attribute
                  -->
                  <td aria-colindex="1">Henderson</td>
                  <td aria-colindex="2">Alan</td>
                  <td aria-colindex="10">8</td>
                  <td aria-colindex="11">25</td>
                  <td aria-colindex="12">9</td>
                  <td aria-colindex="13">9</td>
                </tr>
                <tr aria-rowindex="51">
                  <td aria-colindex="1">Henderson</td>
                  <td aria-colindex="2">Alice</td>
                  <td aria-colindex="10">10</td>
                  <td aria-colindex="11">27</td>
                  <td aria-colindex="12">10</td>
                  <td aria-colindex="13">8</td>
                </tr>
                <tr aria-rowindex="52">
                  <td aria-colindex="1">Henderson</td>
                  <td aria-colindex="2">Andrew</td>
                  <td aria-colindex="10">9</td>
                  <td aria-colindex="11">0</td>
                  <td aria-colindex="12">29</td>
                  <td aria-colindex="13">8</td>
                </tr>
              </tbody>
            </table>
          
        

Defining cell spans using aria-colspan and aria-rowspan

For tables, grids, and treegrids created using elements other than HTML table elements, row and column spans are defined with the aria-rowspan and aria-colspan properties.

The value of aria-colspan is an integer that is:

  1. Greater than or equal to 1.
  2. less than the value that would cause the cell to overlap the next cell in the same row.

The value of aria-rowspan is an integer that is:

  1. Greater than or equal to 0.
  2. 0 means the cell spans all the remaining rows in its row group.
  3. less than the value that would cause the cell to overlap the next cell in the same column.

The following example grid has a two row header. The first two columns have headers that span both rows of the header. The subsequent 6 columns are grouped into 3 pairs with headers in the first row that each span two columns.

        
          <div role="grid" aria-rowcount="463">
            aria-label="Student grades for history 101"
            <div role="rowgroup">
              <div role="row" aria-rowindex="1">
                  <!--
                    aria-rowspan and aria-colspan provide
                    assistive technologies with the correct data cell header information
                    when header cells span more than one row or column.
                  -->
                  <span role="columnheader" aria-rowspan="2">Last Name</span>
                  <span role="columnheader" aria-rowspan="2">First Name</span>
                  <span role="columnheader" aria-colspan="2">Test 1</span>
                  <span role="columnheader" aria-colspan="2">Test 2</span>
                  <span role="columnheader" aria-colspan="2">Final</span>
              </div>
              <div role="row" aria-rowindex="2">
                  <span role="columnheader">Score</span>
                  <span role="columnheader">Grade</span>
                  <span role="columnheader">Score</span>
                  <span role="columnheader">Grade</span>
                  <span role="columnheader">Total</span>
                  <span role="columnheader">Grade</span>
              </div>
            </div>
            <div role="rowgroup">
              <div role="row" aria-rowindex="50">
                <span role="cell">Henderson</span>
                <span role="cell">Alan</span>
                <span role="cell">89</span>
                <span role="cell">B+</span>
                <span role="cell">72</span>
                <span role="cell">C</span>
                <span role="cell">161</span>
                <span role="cell">B-</span>
              </div>
              <div role="row"  aria-rowindex="51">
                <span role="cell">Henderson</span>
                <span role="cell">Alice</span>
                <span role="cell">94</span>
                <span role="cell">A</span>
                <span role="cell">86</span>
                <span role="cell">B</span>
                <span role="cell">180</span>
                <span role="cell">A-</span>
              </div>
              <div role="row"  aria-rowindex="52">
                <span role="cell">Henderson</span>
                <span role="cell">Andrew</span>
                <span role="cell">82</span>
                <span role="cell">B-</span>
                <span role="cell">95</span>
                <span role="cell">A</span>
                <span role="cell">177</span>
                <span role="cell">B+</span>
              </div>
            </div>
          </div>
        
      

Note: When using HTML table elements, use the native semantics of the th and td elements to define row and column spans by using the rowspan and colspan attributes.

Indicating sort order with aria-sort

When rows or columns are sorted, the aria-sort property can be applied to a column or row header to indicate the sorting method. The following table describes allowed values for aria-sort.

Description of values for aria-sort
Value Description
ascending Data are sorted in ascending order.
descending Data are sorted in descending order.
other Data are sorted by an algorithm other than ascending or descending.
none Default (no sort applied).

It is important to note that ARIA does not provide a way to indicate levels of sort for data sets that have multiple sort keys. Thus, there is limited value to applying aria-sort with a value other than none to more than one column or row.

The following example grid uses aria-sort to indicate the rows are sorted from the highest "Quiz 2" score to the lowest "Quiz 2" score.

        
          <table role="grid" aria-rowcount="463" aria-colcount="13">
            aria-label="Student grades for history 101"
            <thead>
              <tr aria-colindex="10" aria-rowindex="1">
                <th>Homework 4</th>
                <!--
                  aria-sort indicates the column with the heading
                  "Quiz 2" has been used to sort the rows of the grid.
                -->
                <th aria-sort="descending">Quiz 2</th>
                <th>Homework 5</th>
                <th>Homework 6</th>
              </tr>
            </thead>
            <tbody>
              <tr aria-colindex="10" aria-rowindex="50">
                <td>8</td>
                <td>30</td>
                <td>9</td>
                <td>9</td>
              </tr>
              <tr aria-colindex="10"  aria-rowindex="51">
                <td>10</td>
                <td>29</td>
                <td>10</td>
                <td>8</td>
              </tr>
              <tr aria-colindex="10"  aria-rowindex="52">
                <td>9</td>
                <td>9</td>
                <td>27</td>
                <td>6</td>
              </tr>
              <tr aria-colindex="10"  aria-rowindex="53">
                <td>9</td>
                <td>10</td>
                <td>26</td>
                <td>8</td>
              </tr>
              <tr aria-colindex="10"  aria-rowindex="54">
                <td>9</td>
                <td>7</td>
                <td>24</td>
                <td>6</td>
              </tr>
            </tbody>
          </table>
        
      

利用 Role 属性的 presentation 主动隐藏语义

虽然ARIA主要用于表达语义,但是在某些情况下,对辅助技术而言隐藏元素的语义是有意义的,presentation 角色的作用是,声明一个元素仅用于呈现,不具有可访问语义。ARIA1.1规范还提供了 none 角色,与 presentation 角色作用相同。

例如:假设使用 ul 元素创建一个tab组件

    <ul role="tablist">
      <li role="presentation">
        <a role="tab" href="#">Tab 1</a>
      </li>
      <li role="presentation">
        <a role="tab" href="#">Tab 2</a>
      </li>
      <li role="presentation">
        <a role="tab" href="#">Tab 3</a>
      </li>
    </ul>
    

因为列表被声明为一个tablist,列表项的列表环境也就不存在了。如果辅助技术仍把li解析为列表项可能会令用户感到困惑。通过给 li 元素添加 presentation 角色告诉浏览器这些元素从可访问树中移除。因此辅助技术将不知道这些列表项元素,并将tab元素(译者注:a元素)视为tablist的直接后代。

presentation 角色的三种常见用法:

  1. 隐藏装饰性图像,相当于给图像的alt值置空;
  2. 当表格语义不能传达有意义的关系时,去除布局表格的表格语义;
  3. 去除符合组件结构中孤儿元素(译注:通常因为腹肌元素的原有语义更改)的语义,如上述的选项卡列表,菜单或树组件。

presentation 角色的作用

当元素设置了 role="presentation" 时,如果不存在 需要浏览器忽略 presentation 的情况 ,则具有以下三种作用:

  1. 元素的隐含ARIA角色,以及该角色相关联的ARIA状态和属性均对辅助技术不可见;
  2. 元素包含文本(内部文本)以及其所有后代元素的内部文本,仍对辅助技术可见,当文本进行显式隐藏时除外,如设置了样式 display: none 或属性 aria-hidden="true"
  3. 所有后代元素的角色、状态和属性仍对辅助技术可见,除非后代元素要求表象元素的环境。例如:
    • 如果 presentation 设置于 ulol 元素上,每个 li 子元素都会继承 presentation 角色,因为ARIA要求 listitem 元素具有父list元素,所以,li 元素并不会暴露给辅助技术,但这些 li 元素内部的元素,包括嵌套的列表,对辅助技术是可见的;
    • 同样的,如果 presentation 设置于 table 元素上,则后代元素 captiontheadtbodytfootertrthtd 元素将继承 presentation,因此不会暴露于辅助技术。但是,在 thtd 元素内的元素,包含嵌套表都暴露于辅助技术中。

导致 presentation 角色被忽略的情况

如果被作用的元素满足下面任一个条件,浏览器将会忽略 role="presentation",因此也就不会产生任何作用:

presentation 角色作用示例

代码如下:

        <ul role="presentation">
          <li>Date of birth:</li>
          <li>January 1, 3456</li>
        </ul>
      

当浏览器解析时,从屏幕阅读器或其他依赖于浏览器可访问树的辅助技术的角度来看,是与下面代码等效的:

        <div>Date of birth:</div>
          <div>January 1, 3456</div>
      

使后代元素presentational隐藏的角色

有一些类型的用户界面组件,当在平台可访问性API中表示时,它们只能包含文本。例如,可访问性API没有提供在按钮内包含语义元素的方法。为了解决这个限制,WAI-ARIA要求浏览器对于那些不支持语义后代的元素,自动为其所有后代元素自动添加 presentation 角色。

要求所有后代元素需要设置presentation的角色有:

例如,下面这个tab元素包含了一个标题元素

      <li role="tab"><h3>Title of My Tab</h3></li>
    

由于WAI-ARIA要求tab的后代需为表象元素,所以与下面的代码是等效的。

      <li role="tab"><h3 role="presentation">Title of My Tab</h3></li>
    

此外,对于那些使用依赖可访问性API的辅助工具(如屏幕阅读器)的人来说,这个标题是不存在的,因为上面的的代码与下面的代码是等效的。

      <li role="tab">Title of My Tab</li>
    

更多详细解释,请参阅presentation 角色章节

Appendices

Change History

Changes in December 2017 Publication as Note

  • Added the following:
    • Read Me First section
    • Combobox pattern
    • Combobox examples: 3 ARIA 1.0 style and 4 ARIA 1.1 style
    • Disclosure pattern
    • Feed example display page
    • Grid and table properties guidance section
    • Collapsible dropdown listbox example
    • Multi-thumb slider examples
    • Table pattern and example
  • The top of each example page now includes a set of four related links to:
    • Browser and Assistive Technology Support section of Read Me First
    • Report Issue page in the Github repository
    • Related Issues listed in the Github project for the example
    • Design Pattern section that applies to the example
  • All Javascript and CSS files used by the examples include the correct license and copyright statements.
  • Significant revisions of guidance and implementation were made to the following sections, design patterns, and examples:
    • Introduction
    • Keyboard guidance for Mac OS
    • Accordion example
    • Mixed checkbox examples
    • Scrollable layout grid example
    • Listbox examples
    • Modal dialog example
    • editor menubar example
    • Navigation menubar example
    • Menu button examples
    • Spinbutton pattern
    • Toolbar example
    • Tree view examples

Also see:

Changes in June 2017 Working Draft

  • Added the following:
    • Modal dialog example
    • Disclosure design pattern
    • Example disclosure for FAQ
    • Example disclosure for image description
    • Draft of feed pattern
    • Example feed implementation
    • Example of menu button using aria-activedescendant
    • Example of tabs with manual activation
  • Design pattern section: moved examples subsection of each design pattern to be the first subsection.
  • Across all example pages:
    • Improved visual design of tables that document keyboard implementation, roles, states, and properties.
    • Improved consistency of editorial style.
  • Significant revisions of guidance and implementation were made to the following design patterns and example pages:
    • Accordion example
    • Alert example
    • Breadcrumb example
    • Button example
    • Checkbox examples
    • Dialog (modal) design pattern
    • Grid examples
    • Landmark examples
    • Link example
    • Listbox example
    • Menubar examples
    • Menu button examples
    • Radio group example
    • Slider design pattern
    • Slider example
    • Example of tabs with automatic activation
    • Tree view examples

Also see: