3. Basic WAI-ARIA
Keyboard Interaction
Keyboard access is perhaps the most important accessibility feature that can go into a website, widget, or web application. However, it is often overlooked by developers, who are typically mouse users and may not have keyboard usability as a part of their testing regimen. People who are blind are typically unable to use a mouse, so any feature that relies on a mouse alone to function will likely be inaccessible to them. Fortunately, it is relatively easy to include keyboard access. It’s more a matter of remembering to add it when mouse access is added.
The following is a simple example of including both mouse and keyboard events when defining interaction for a widget or web application. Examine the JavaScript to see how mouse and keyboard events are handled, then under the Result tab, try operating the button with a keyboard and mouse while using ChromeVox. How you go about implementing both mouse and keyboard doesn’t really matter, as long as it is possible to interact with both.
You may notice some inconsistencies in ChromeVox support for the live region used to present the messages in the example, more specifically the aria-atomic attribute. Live regions will be covered more thoroughly later in this unit.
Predictability, Consistency, and Convention
Here we will introduce the basics of keyboard interaction, and we’ll go into greater detail when we start looking more closely at particular widgets and design patterns as they are introduced in the units that follow.
As the heading for this section suggests, keyboard interaction needs to be predictable, consistent, and should follow convention. That is, users should have a good idea of the path that the focus will follow (predictable). When navigating with the Tab key, that path should be the same throughout an application or website (consistent). Finally, it should be like it is in other applications, websites, or operating systems (convention).
Take for example a combo box (aka, a select menu). Regardless of the operating system being used, combo boxes work the same way. If you are developing a widget out of divs that function like a combo box, it should operate like a standard HTML combo box.
Conventional keyboard interaction for a combo box:
- Tab to navigate into the combo box
- While in focus, tab to navigate beyond the combo box
- While in focus, Shift + Tab to navigate before the combo box
- While in focus, Down Arrow to show next option
- While in focus, Up Arrow to show previous option
- While in focus, Alt + Down Arrow to display options list
- While options list is open, Alt + Up Arrow to close the options list
- While options list is open, Esc to close the options list and return to default state
- While an option is in focus, Enter to select that option
When developing a custom combobox — typically, a text box and list of options — a grid, a tree, or a dialog are combined into a functional unit that should operate like a standard HTML select menu. Functionality in addition to that described above may be added to the custom combobox, e.g., to add autocompletion. As the user types letters into the text box, options beginning with the string type are displayed below as a list or the first option with those letters is displayed inline in the text box.
Try This: Using your keyboard, try the keyboard interactions described above to confirm whether or not the combobox functions in a conventional way. Try it with a few different browsers and notice any variations in how different browsers handle combobox interaction.
Toolkit: For a list of design patterns, and keyboard interaction conventions, review the following widget development best practices. Scan for now. They will be covered more thoroughly in later units.
