An accessibility case study - Reading List. Part 3: Keyboard accessibility
This post discusses accessibility considerations around keyboard accessibility of the Reading List app available in the Windows 8.1 Preview.
The series of posts, “An accessibility case study - Reading List”, highlights work the Reading List team did to enhance the accessibility of the Reading List app beyond the level provided by default by the WinJS framework. In the case of keyboard accessibility, the team didn’t really have to do anything at all. The WinJS framework did such a great job at making the app keyboard accessible, I could have left this post out.
But keyboard accessibility is of such fundamental importance to accessibility as a whole, whether the customer is using a switch device which simulates keyboard, controlling a screen reader with a keyboard, or simply finds it more efficient to interact with the app via a keyboard rather than a mouse. So I want to take this opportunity to describe what the team considered around keyboard accessibility during development of the Reading List app.
Keyboard focus
All elements that the customer can interact with must be able to get keyboard focus. In the case of the Reading List app, there are three areas of interest; the list items, the list group headers and the SearchBox control. By default, as the customer tabs through the UI, keyboard focus cycles through these areas. Also by default, when focus is on a list item or on a group header, the arrow keys will move focus between elements of the same type, (that is, other items or group headers).
So the customer can tab to the group headers, then arrow through the headers to get to a group of interest, and then Shift+Tab into the items in that group. They can then arrow around or page through the items however they’d like. (As you’d expect, Home and End moves keyboard focus to the start or end of the list.)
And the Reading List team didn’t have to do anything to enable all this efficient navigation.
On a side note, if we’d found it necessary we could have used the “tabindex” property supported by the WinJS framework, to add keyboard focus support to elements or to control where they’re located in the tab order. As it happened, we didn’t have to do that.
One important reminder on keyboard focus; don’t forget to consider which element should get focus by default when different UI is presented to the customer. For the Reading List app, we put focus on the first item in the list, in order for the customer to move through the list immediately. It would be tiresome for the customer to always have to press the tab key to move focus into the list when the app starts.
And by the way, we shipped the app with the default tab order provided for buttons that appear on appbar along the bottom of the screen and on the navbar along the top. The default tab order for those features worked just fine.
Interacting with the element with focus
Once focus has reached an element, the customer must be able to interact with it through the keyboard. For the list items, again this functionality was provided automatically. A press of the Enter key would fire an itemInvoked event for the item, and a press of the Spacebar would fire the selectionchanging/selectionchanged events. All the Reading List team had to do was register event handlers for these events from the ListView.
We did explicitly add a keydown event handler for the list in order to react to a press of the Delete key. (The ListView automatically reacts to Ctrl+A to select all the items, which was handy.) The customer could already delete selected items by invoking the Delete button on the appbar after selecting items, but adding a Delete key handler made for a more efficient way of doing deleting items. We registered the event handle with the following code:
listView.addEventListener("keydown", onKeyDown);
The function below then reacted as required:
function onKeyDown(eventInfo) {
if (eventInfo.keyCode === WinJS.Utilities.Key.deleteKey) {
…
}
}
The Reading List app doesn’t react to the customer interacting with the group header with focus, (for example, when they press the Enter key or Spacebar), so no events handlers needed to be set up for that.
The app does also have some additional keydown event handlers for app-specific functionality. For example, reacting to Backspace to make it quick to return to the main app flyout from the About or Options UI. We also added an event handler to react to certain key presses when focus is on the main list of items. This means the customer can be happily arrowing around the list, then press “h” to start a search for all items with text beginning with “h”. As a result, they don’t have to explicitly move focus up to the SearchBox control whenever they want to start a search.
This illustrates how we wanted Reading List to not only be technically accessible, but to be efficient to use.
Transient keyboard accessible UI
I thought it worth calling out a potential problem with transient UI. Your customer may take action which results in you revealing some UI that they can interact with. That UI needs to be keyboard accessible, and that means it should get inserted in the appropriate place in the tab order. It’s going to be pretty irritating for the customer if some UI appears visually next to where keyboard currently focus is, and then they have to press tab a load more times before focus moves into the UI that just appeared. (This might happen if the UI that appeared got inserted in the tab order at the end of the tab sequence for all the UI that was already on the screen.) Instead the customer wants to press tab once to be taken into the revealed UI. Similarly when the transient UI vanishes, the keyboard focus wouldn’t want to unexpectedly jump to some distant control.
An example of this is the transient Delete or Add Back buttons that can appear on list items when vertically laid out in the Reading List app when the app’s narrow. Say the customer is viewing the Recently Deleted items, and they want to add one back to the Home view. They arrow to the item of interest and then press the Spacebar to select it. The Add Back button appears on the item. The customer then presses the tab key once to move focus onto the newly revealed button and then the Spacebar to invoke it. The item is removed from the list, and focus moves to the next item in the list.
In the case of the transient Delete and Add Back buttons that can appear on the list items when vertically laid out, the buttons were automatically inserted in the required tab order.
Again the Reading List team didn’t have to do any specific work to enable this efficient keyboard interaction.
Figure 1: Keyboard focus on the transient Add Back button.
On-screen keyboards
A very important aspect of keyboard accessibility, is that an app is not only accessible to customers who uses physical keyboards, but also to customers who use on-screen keyboards. And so by making the Reading List app fully keyboard accessible, we knew that switch device customers can also leverage the app’s features, as shown below.
Figure 2: The Reading List app being controlled with the On-Screen Keyboard in Scan mode.
Figure 3: The Reading List app being controlled by a switch device.
Summary
Keyboard navigation and control is an essential part of an app’s accessibility, and the WinJS framework automatically provided support for much of this by default to the Reading List app. With little effort, the Reading List team implemented some specific key event handlers in order to make keyboard accessibility more efficient.
An accessibility case study - Reading List. Part 1: Introduction
An accessibility case study - Reading List. Part 2: Colours and Contrast
An accessibility case study - Reading List. Part 3: Keyboard accessibility
An accessibility case study - Reading List. Part 4: Programmatic accessibility
An accessibility case study - Reading List. Part 5: Live Regions
An accessibility case study - Reading List. Part 6: Using Narrator with touch input only