Creating websites and online content that are easily accessible by disabled and able-bodied users alike is of ever-growing importance in most commercial and educational circles. In some peoples' minds, however, this roughly equates to making sure a site works with screen readers for blind people. In fact, "web accessibility" is intended to cater for all types of disability. Unfortunately, keyboard users are a sizable group of people often forgotten by web designers and developers.
Keyboard users are people who cannot use a mouse, due to injury or impairment of hands, arms or muscles, or such ailments as arthritis and hand tremors. Most of these users navigate using the keyboard instead, but they are completely prevented from doing so if the website is not marked up correctly.
Blind people use the same keyboard functionality - their screen and Braille readers add to rather than replace the standard keyboard mechanisms. So these users also cannot use a wrongly marked up page.
How keyboard Users Work
Keyboard users use the page-up and page-down keys to scroll a web page as they read it. But to use the interactive components - links, buttons, form fields and so on - they use the Tab key to jump from one interactive component to the next, and Shift+Tab to go back.
They then press Enter to follow links, and the spacebar or Enter to operate buttons. Some components, such as option select elements, tabs and menus, and radio buttons, require the use of the four arrow keys. Other keys may also be used as appropriate.
Providing this interactivity requires three things:
- Use standard HTML elements wherever possible, as they are inherently keyboard usable.
- Ensure any custom-built interactive components react to the relevant keys, not just to mouse clicks.
- The user must also be able to see where they are on the page.
If your web page contains standard interactive components - links, buttons, form fields and other HTML elements - with correct syntax and usage according to the HTML specification, all should be well. But if you have non-standard components custom built by developers, that is time for the alarm bells to start ringing. Custom components are usually built using non-interactive elements such as divs or spans. The developer will give them mouse-handling events and may not realize that this leaves keyboard users high and dry.
If you have such content or are using a framework or library that does not create standard HTML:
- Add keyboard event handlers to ensure it reacts to the expected keys for that component.
For the keys to use for different components, take a look at W3C's ARIA Authoring Practices 1.1, the industry standard for creating complex components. Another useful guide exists on WebAIM.
Since keyboard users tab from one interactive control to the next, an indicator is needed to show them where the focus is currently. This will usually be either an outline
This indicator must be clearly visible; the faint grey, dotted focus indicator provided as default by most browsers is hard to follow, especially when it jumps long distances around the page. People are not limited to just one disability. The same proportion of keyboard users have poor eyesight as do the rest of the population, and they need a highly visible indicator. So add your own, high contrast indicator. Some websites these days use a thick orange outline of 3 or even 4px thickness.
Once you have completed your web page, put aside your mouse and test it as a keyboard user:
- Check everything can be reached using the Tab and also the Shift+Tab keys.
- Check the focus indicator shows clearly in each interactive component. It must contrast clearly with both page and component.
- Check everything tabbed to can be operated by the expected keys for the type of component concerned (see above).
Following these simple procedures will ensure all keyboard users can use your website.
Leave a comment