PF/ARIA/BestPractices/NavigationGeneral
ARIA Keyboard Bindings and Behaviors
Essential to accessible Web 2.0 widgets is keyboard support to provide full operation and functionality of a widget through keyboard-only events. Unlike traditional HTML form controls, Web 2.0 widgets have no inherit keyboard support. The developer must enable keyboard support for the widgets they create or use widget libraries with keyboard support. The best practices model for keyboard support for Web 2.0 widgets are graphical user interface (GUI) operating systems like Microsoft Windows®, Apple OSX® and UNIX Desktops like GNOME and GTK. Two basic accessibility requirements for keyboard focus include:
- Support users who cannot use pointing devices due to physical or visual impairment to access the full functionality of the Web application. All major software and web accessibility guidelines for people with disabilities require keyboard-only operation of the interface for accessibility.
- Communicate accessibility information to assistive technologies on the type of widget and its associated state and properties.
The TABINDEX attribute enables focus to be moved via keyboard to HTML elements used to create Web 2.0 widgets.
- Tab and Shift+Tab key move focus among widgets and standard HTML controls.
- Widgets with TABINDEX=0 will be added to the tab sequence based on document order
- Widgets with TABINDEX>0 will be added to the tab sequence based on the TABINDEX value
- Widgets with TABINDEX<0 will not be added to the tab sequence but are enabled to receive keyboard focus.
Once a widget has keyboard focus, arrow keys, Spacebar, Enter key, or other keyboard commands can be used to navigate the options of the widget, change its state, or trigger an application function associated with the widget.
Each element that receives keyboard focus needs to have a TABINDEX attribute set. The element with keyboard focus is essential because it communicates information about the widget to assistive technologies like screen readers and magnifiers through operating specific accessibility APIs like Microsoft Active Accessibility (MSAA), Apple Accessibility Programming Guidelines and ATK Accessibility Toolkit. The TAB key moves keyboard focus to the widget, and other keys operate the features of the widget, typically cursor keys, Enter key and Spacebar. The actual keys are up to the developer, but best practices recommend using the same key bindings that are used to control similar widgets in common GUI operating systems like Microsoft Windows®, Apple OSX® and UNIX Desktops like GNOME and GTK. JavaScript can use either the focus() method to move focus to the appropriate element in the widget, or it can use an ARIA property called "activedescendent" to indicate which element in the widget should have focus. The author must indicate through styling and/or markup which element in the widget has focus.
Example Keyboard Operation: Radio Group/Radio
See working | Radio button examples from the University of Illinois.
| Key |
| Tab Key |
| Space Bar |
| Down Arrow |
| Up Arrow |
In this Radio Group example, the TABINDEX of the radiogroup element initially has tabindex=0 (assuming none of the radio buttons is checked), the radio elements have TABINDEX=-1. As soon as one of the radio buttons is checked, the radio group element changes its value of TABINDEX=-1, the radio element that is checked changes its value to TABINDEX=0, and all other radio buttons have a TABINDEX=-1.
Other Widget Best Practices
For specific keyboard navigation, see the individual Widgets and structures.
Validation Issues
TABINDEX, ROLE, and ARIA states and properties attributes need to be added to elements used to create widgets within HTML 4.01 documents through scripting, if the resource is to validate, because the HTML 4.01 DTD only allows TABINDEX on anchors and form controls. See the | Embedding Accessibility Role and State Metadata in HTML Documents for more information.