Some portion of your audience may experience motor disabilities that make using a mouse or keyboard difficult. This could include tremors or pain in the hands, whether it be a long-term disability or something short-term for example if someone had surgery on a hand.
To keep your site fully accessible to individuals with motor disabilities, ensure that all functionality on a site is keyboard-accessible. You should be able to [ tab ] through all focused elements on a page. If you are creating your page with Snippets in the CMS Editor you do not need to worry about this, as it will be handled in the background HTML.
Advanced keyboard accessibility
People who use screen readers rely on keyboard navigation, but so do people with mobility impairments.
- Users must be able to access and operate all information and function using only the keyboard.
- As focus advances to the next interactive component, ensure focus is always visible.
- Require user action such as a keypress, rather than an
onfocusevent, to initiate a change in context. - Provide visible mechanisms to allow keyboard users to skip past repetitive blocks of content, such as navigation elements.
- Design drop-down navigation to allow users to tab left and right across main categories and use arrow keys to move up and down through the sub navigation.
- Provide consistent, logical tab order—left to right, top to bottom.
- As content is dynamically introduced, move focus into the new content and inform users of its function and purpose.
Programmatic Focus
Keyboard users — such as blind screen reader users or people who cannot use a mouse due to tremors in their hands — can activate only the links and form elements that can receive programmatic focus.
Bad Example:
This "link" is not a link after all, and that is why it cannot receive keyboard or programmatic focus when tabbing through the web page.
<p onclick="JavaScript:location.href='http://www.deque.com';">Learn more...</p>
Changes in Programmatic Focus
|
Events that Usually Trigger Changes in Programmatic Focus |
Events that Usually do NOT Trigger Changes in Programmatic Focus |
|
|
Event Handlers
|
Recommended |
Not Recommended |
|
onfocus OR focus() |
onmouseover OR mouseover() OR hover() |
|
onblur OR blur() |
onmouseout OR mouseout() |
Ensure All Actionable Elements Can Receive Focus
This code example provides the method for ensuring focus on an element through the use of the tabindex attribute. Although tabindex is not "valid" for the <td> element (it is only valid for A, AREA, BUTTON, INPUT, OBJECT, SELECT, and TEXTAREA elements) the attribute works nonetheless on all major browsers. Adding tabindex has the effect of placing otherwise non-actionable items in the tab order. This is very important for interfaces with a lot of client-side interaction. For example, a lot of "accordion" widgets created through JavaScript and so on, use <div> elements that, by default, are not actionable.
Using the tabindex attribute and setting its value to zero places the item in the tab order, while not "messing" with the actual order of tabbing through other items on the page. It takes its place in the tab order logically where it would otherwise exist if it were an actionable item.
- All
tabindexitems are tabbed to before any non-tabindexitems.
Example:
<td class="sort" tabindex="0">Name</td>
Methods for allowing items to receive tab focus
|
Method |
Effect |
|
tabindex="0" |
Puts the item in the normal tab flow. |
|
tabindex="-1"+ JavaScript |
Keeps the item out of the normal tab flow until a JavaScript method allows tab focus and changes the value (i.e. by changing the tabindex value to 0 or a positive number) |
Visual Focus
- Don't hide this in the styles.
- Feel free to augment default in the styles for folks with low vision. E.g. a giant thick outline versus the thin standard one provided by default.
Keyboard Traps
- Flash objects are major offenders. Here is a W3C document "Providing Keyboard Access to a Flash Object and Avoiding a Keyboard Trap.".
- Check UIs and JavaScript to avoid this in your code.