This is part 4 of a series that begins here: Designing for Accessibility.
In the previous article in this series I talked about what keyboard users need to get around your site, and how you can design your pages to meet their needs by calling out landmark roles, semantic headings and logical content order. This article explains how to ensure that keyboard users can access interactive content on your pages.
Even the simplest web sites these days often require users to interact with the page in some way, such as entering information in a form, or hovering over or clicking an element to see more information. More complex web applications include drag and drop, scrolling using the mouse wheel, double-clicking or right-clicking — almost anything you can do with a desktop application. These are the kinds of sites that interaction designers love to work on. But they often present challenges to users with disabilities.
There is one simple goal for designing interactions: every interaction on the page — navigating, editing, posting, filtering, arranging, sorting, creating, deleting, etc. — must be available from the keyboard.
Visually indicate which components are interactive — and how
It’s a lot easier for any sighted user to target an interactive element if the element provides some visual indication that you can do something with it. For sighted keyboard users it’s invariably more work to get keyboard focus to the element, even if you’ve designed your content for efficient navigation, so knowing ahead of time where you’re trying to go is crucial.
Additionally, it helps if an element gives some indication, either visually or by its content, of what it does. For example, in this navigation menu from Netflix, it’s pretty clear that “Genres” has some kind of dropdown or submenu associated with it, while the other menu items do not.
Provide keyboard access to all focusable/clickable elements
The Netflix menu above is a typical example of a web navigation menu where hovering over an option displays a submenu of options. Unfortunately, it’s also a typical example of one of the most common keyboard accessibility fails.
Here’s the Genres menu item on hover:
And here’s the Genres menu item on keyboard focus:
Contrast the Netflix experience with that on the Knowbility site:
Hovering or tabbing to the “Learn” section displays a submenu with related links. Arrow keys are used to navigate through the links in the submenu, while the tab key takes you to the next navigation menu item at the same level as “Learn,” which is “Participate.” This is consistent with how we expect drop-down menus to behave, and also an efficiency for keyboard users, as users don’t need to tab through all the child links to get to the next top level link.
The hover pattern is also commonly used to reduce visual clutter on a page by hiding related links until the user hovers over content, such as on Twitter:
Although there is content in the tweet that can receive keyboard focus, the additional links in the second image are shown only when a user mouses over the tweet, making those actions unavailable to keyboard users.
There is one exception to the rule of providing keyboard access to every element that is clickable, and that’s when you are providing multiple clickable targets that link to the same destination. In the publishing box for Facebook, for example, you can click on either the icon or name of each action:
If you provided keyboard access to both the icons and the action names, it would require twice as many clicks for a keyboard user to get through the list. In cases like this it makes sense to only provide keyboard access to the action names, and skip over the icons.
Use the right tools for the job
Form elements are great for entering data into a form. But some elements, particularly drop-downs (the HTML select element) and radio buttons, have gotchas for keyboard users that make using those elements for other things — like navigation — problematic. Take, for example, this list of loans from Kiva:
The list of radio buttons acros the top are filters for the table below. They behave much like tabs: clicking on one refreshes the table to show only the loans that meet a specific criteria. The problem for keyboard users is that you can’t actually navigate through a list of radio buttons by keyboard without activating the onclick event for each one. In this page, this event submits a form, which causes the page to refresh, which causes keyboard focus to return to the top of the page. While it’s not impossible for a keyboard user to filter to see only “Paid Back” loans, they’d have to want it awfully badly.
Another common use of form elements for navigation is using a drop-down to choose a destination page, such as on Google Analytics:
While the HTML select element does allow users to navigate through them using the keyboard, the behavior is different for each browser. Firefox and Chrome allow you to use the up and down arrow keys to move through the items, then press the enter key to trigger the onchange event. Internet Explorer triggers the onchange event if you use the arrow keys — you must first use Alt+down to open the drop-down, and a lot of users don’t know this.
The answer in both cases is either to use a button to submit the form instead of using the onclick/onchange events, or to use a custom control.
Functionality, not method for achieving functionality
Keyboard accessibility doesn’t mean that you need to figure out a way to drag and drop elements using a keyboard. It means that equivalent functionality must be available using a keyboard. Consider the functionality, not the method for achieving that functionality.
Wufoo’s form building tool allows users to drag fields from a palette to a canvas to create web forms:
However, you don’t actually have to drag fields to add them to your form. Just clicking on a field type adds it below the last element on the canvas. A keyboard user can tab between field types in the palette, and press the Enter key to add them to the canvas.
Unfortunately Wufoo doesn’t have equivalent functionality for configuring the field properties, as there’s no apparent way to set keyboard focus on the canvas elements.
Follow standard interaction patterns when creating custom controls
If you require more complex functionality, such as in a web application, you should design a mouse interaction and a keyboard interaction. In some cases, they may be the same. (If they’re very different, you may want to consider whether the interaction is needlessly complicated.)
When creating custom controls, as in the Netflix “Genres” menu example, help mouse and keyboard users understand how the control will behave by following standard patterns. The WAI-ARIA 1.0 Authoring Practices outline standard widget design patterns, as does the AOL Developer Network’s DHTML Style Guide.
Offer keyboard shortcuts to accelerate work
Expert users usually benefit from keyboard shortcuts as much as users with disabilities. Unfortunately, keyboard shortcuts are difficult to discover and to remember, making them useful only for sites that receive frequent use. The TinyMCE editor I’m using right now to create this post is a good example.
If you blog more frequently than I apparently do, it’s worth knowing the keyboard shortcuts for common options on the TinyMCE menu bar. If you don’t remember a particular shortcut, or if an option doesn’t have a shortcut, a mouse user can click on the related control in the menu bar. The menu controls are keyboard-accessible, but not via the tab key — you need to use accesskey+Q to get to the menu. This is announced to screen reader users, but isn’t easy to discover if you’re a sighted, keyboard-only user.
Another issue with keyboard shortcuts is that they mustn’t conflict with existing operating system, browser or assistive technology keyboard shortcuts, which limits the pool considerably. And sometimes there are internationalization issues: alt-S, for example, is a common accented letter in Polish, so a page that includes that keyboard shortcut prevents Polish users from typing that character.
Note in your design deliverables:
- elements that can receive focus using a mouse must also be able to receive focus using the keyboard
- which elements, if any, should not receive focus
- any behavior that occurs on hover must also occur on keyboard focus
- any interactions that are specific to keyboard users, in addition to the mouse interactions
This is the end of the section on keyboard accessibility. Up next in this series: how does someone with a visual impairment interact with your page?