If content can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. (Level A)

Rationale

The intent of this checkpoint is to ensure that when users navigate sequentially through content, they encounter information in an order that is consistent with the meaning of the content and can be operated from the keyboard.

When content relies on sequential navigation for the user to understand it, it is essential for the focus order to match the visual flow of the content, whether that is from left to right, top to bottom or some other visual stylization. If there is more than one order that preserves meaning and operability, only one of them needs to be matched by focus order.

Note: lf content does not need to be navigated sequentially or the navigation sequence does not affect the meaning of the content, the focus order should still be logical and predictable.

Refer to Understanding SC 2.4.3  for more information (external link to WCAG).

Development Techniques

Review the General techniques as well as other tabs applicable to your technology.  Prioritize the use of technology-specific techniques, and implement the General techniques as needed. You are always required to find, understand and implement accessible code techniques to meet the checkpoint. The documented techniques and supplements are not exhaustive; they illustrate acceptable ways to achieve the spirit of the checkpoint. If numbered, techniques are in order of preference, with recommended techniques listed first. Where used, IBM information that complements the WCAG techniques is indicated as supplemental.

General techniques

Any item in this section represents a technique deemed sufficient. Ensure you review WCAG Common Failures to avoid development mistakes.

General supplements

The following examples and comments provide additional information beyond that available in the WCAG techniques.

Maintaining user’s point of regard

WCAG discusses the concept that after a button triggers the opening of a dialog, when the dialog is dismissed, focus returns to the button. This concept is often termed “maintaining the user’s point of regard”. The point of regard is a position in rendered content that has focus and context for the user. Dynamically refreshing content using scripting is another example where the user's point of regard has to be maintained by handling focus, either to return to a prior context or to be placed in a location that can be anticipated by the user (such as placing the focus on the search results after activating the Search button).

Web (HTML, ARIA, CSS) techniques

Instructions: In addition to the General techniques, any item in this section represents a technique deemed sufficient.

Web supplements

The following examples and comments provide additional information beyond that available in the WCAG techniques.

Creating a logical arrow key order through complex widgets

Rich Internet application keyboard navigation should behave like desktop application keyboard navigation. For example, keyboard users tab to Windows® Explorer and then use the arrow keys to navigate to elements in the tree. WAI-ARIA provides support for arrow key navigation of complex widgets, such as menus, trees and grids, via the tabindex attribute or activedescendant property. For more information on how to implement arrow key navigation, see WAI-ARIA Best Practices.

Using WAI-ARIA to create messages and dialogs in the DOM

Screen readers do not always announce content when the application renders messages and dialog boxes created in the DOM. To overcome this problem, assign a WAI-ARIA alert or alertdialog role to a container element via JavaScript®. The following JavaScript function assigns an alertdialog role to the div with id "myAlert".

function showAlertDialog(){
var alertDialog = document.getElementById('myAlert');
alertDialog.setAttribute('role', 'alertdialog');
alertDialog.setAttribute('tabindex', '0');
alertDialog.focus();
var txt = document.createTextNode('This message appears in an alert dialog.');
alertDialog.appendChild(txt);
alertDialog.style.display = 'block';
alertDialog.style.border = '1px solid black';
}

<div id="myAlert"> </div>

When the dialog box is rendered, a screen reader announces "alert" and then reads the content in the dialog box.

Note that if an explicit action or acknowledgement is required, use alertdialog and maintain the point of regard by returning focus to the element that previously had focus when the dialog is dismissed. If a simple message is rendered that does not require interaction, use alert and leave the focus unchanged.

Mobile Native (iOS) techniques

Instructions: In addition to the General techniques, the iOS techniques in this section are deemed sufficient for meeting this checkpoint where appropriate.

Meet G59: Placing the interactive elements in an order using the following:

Moving the VoiceOver Cursor to a Specific Element

iOS determines focus order from the physical layout of controls and views top-left to bottom-right. In rare cases where you need to override the focus, you can do so. See Moving the VoiceOver Cursor to a Specific Element  in the View Controller Programming Guide for iOS, as well as the UIAccessibilityProtocol Reference.  Children that need to be grouped for navigation can use the shouldGroupAccessibilityChildren method of UIAccessibilityProtocol.

For custom controls, you can order focus using the accessibleElements array. If necessary, the default focus order may be changed by reordering items within the accessibleElements array. Refer to the code snippet under the Make the Contents of Custom Container Views Accessible heading for an example of how to add custom view items to the accessibleElements array.

The Accessibility on iOS session from WWDC 2014 gave a good overview of overriding the defaul focus order.  Skip to the 41:20 mark of the video for the demo.

Eclipse techniques

Instructions: In addition to the General techniques, the Eclipse techniques in this section represent a technique or combination of techniques deemed sufficient for meeting this checkpoint.

Provide logical navigation order

Provide a logical navigation order among items in application windows and dialogs. The navigation order is the order in which the Tab key gesture moves the keyboard focus from one control or item to the next within a dialog box.

For Western languages, the navigation order is normally from left to right and top to bottom. If the order does not follow this convention, it can be very confusing to users, especially blind users, who navigate using the keyboard. Users who are blind explore forms and dialog boxes sequentially, using the Tab key, instead of scanning the entire box as sighted users would.

Use standard programming practices for specifying the tab order for each control in a dialog. In Eclipse, the default tab order is the order in which the controls are added to the GUI component hierarchy. You can override this by using the org.eclipse.swt.widgets. Composite getTabList() and setTabList() methods for Composite type objects. For Control type objects use the Control.moveAbove() and Control.moveBelow() methods to manipulate the tab order.

WAI-ARIA Authoring Practices provides further discussion on how to provide logical keyboard and navigation support where the user can Tab to controls and once a widget has keyboard focus, arrow keys can be used to navigate the options of the widget.

Provide support for Shift+Tab

In dialogs, allow the user to press the Shift+Tab key combination to move backwards through the elements in dialogs. Without this feature, the user will have to cycle all the way through the end of a dialog and back to the beginning in order to back up to a previous control.

Windows-based (MSAA+IA2) techniques

Instructions: In addition to the General techniques, the Windows-based (MSAA+IA2) techniques in this section represent a technique or combination of techniques deemed sufficient for meeting this checkpoint.

Provide logical navigation order

Provide a logical navigation order among items in application windows and dialogs. The navigation order is the order in which the Tab key moves the keyboard focus from one control or item to the next within a dialog box. For Western languages, the navigation order is normally from left to right and top to bottom.

If the order does not follow this convention, it can be confusing to users, especially blind users, who navigate using the keyboard. Users who are blind explore forms and dialog boxes sequentially, using the Tab key, instead of scanning the entire box as sighted users would.

Use standard programming practices for specifying the tab order for each control in a dialog. For example, in Microsoft Visual C++ use Layout/Tab Order to view and change tab orders for your dialogs. WAI-ARIA Authoring Practices provides further discussion on how to provide logical keyboard and navigation support where the user can Tab to controls and once a widget has keyboard focus, arrow keys can be used to navigate the options of the widget.

Provide support for Shift+Tab

In dialogs, allow the user to press the Shift+Tab key combination to move backwards through the elements in dialogs. Without this feature, the user will have to cycle all the way through the end of a dialog and back to the beginning in order to back up to a previous control.


Most links in this checklist reside outside ibm.com at the Web Content Accessibility Guidelines (WCAG) 2.0. W3C Recommendation 11 December 2008: http://www.w3.org/TR/WCAG20/

Copyright © 1994-2017 World Wide Web Consortium, (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University, Beihang University). All Rights Reserved.

Copyright © 2001, 2017 IBM Corporation