Keyboard control is the most common alternate interaction mode for sites, one vital for users with coordination and control challenges and those who desire optimized use of web apps. It’s also probably the most overlooked aspect of modern UI design. This is ironic, given that creating keyboard accessibility is straightforward if you pay attention to just a few rules:

Plan For Accessibility

Basic keyboard navigation on the web uses the tab and enter keys. Repeatedly pressing tab will select elements in the browser window: first the URL bar, then browser controls, then sequentially through appropriate elements on the page, including , buttons, and form elements. Most browsers will outline a selected item in blue. Tapping the enter key is the equivalent to “clicking” on a selected element.

Selection follows the flow of the document, in source order*. Your first task when planning for keyboard accessibility is not only to determine if your site UI can be used via the keyboard, but also how quickly UI elements can be reached.

By considering these factors early in the design and development process, integrating accessibility helps everyone: a page that takes a lot of keyboard input to navigate will likely also be difficult for users without accessibility needs, and should be reconsidered.

Keep It Simple

Trying to code keyboard accessibility for hyperstylized <span> and <div> elements with tacked-on JavaScript interactivity can be a real challenge. Developers can avoid this problem altogether by choosing to use appropriate elements for site UI:  for links, <button> elements for buttons. Of course, both elements can still have JavaScript added, and be styled just as extensively as other tags.

Make Focus & Hover Equal

Keyboard users still need to know when something is selected. The easiest way to achieve this is to make :hover and :focus states equal in your CSS, via group selectors: 

a:hover, a:focus { background: #000; color: #fff; }

Naturally, you should keep color contrast and color blindness in mind when designing these states.

Test For Accessibility

Testing keyboard accessibility is surprisingly simple: without touching your mouse or trackpad, try to navigate your site.

If a UI element can’t be used or reached via the keyboard, craft a solution. The answers may include JavaScript mapping of keyboard controls, a specialized accesskey combination, or a remapped tabindex.

Use Negative TabIndex To Skip

You may find visual focus “slipping away” during keyboard accessibility testing: you’re pressing the tab key, but nothing appears in a hover state or surrounded with an outline. In such cases it’s likely that you’re selecting an element that is hidden, but can still be reached via the keyboard.

There are a few ways to deal with this: you can either set the element(s) or their parent to display: none in the site’s CSS, or set a negative tabindex value on the element: 

<div id="hidden-nav" tabindex="-1">

Both techniques remove the element from the keyboard selection order: there’s now no way to reach it with a keyboard. Obviously, this has to be used carefully.

Conclusion

I think part of the reason many websites lack good is that many developers fear doing it “wrong”, while others become overwhelmed trying to shoehorn accessibility into completed work and give up. But there’s really nothing to fear: most websites benefit from simply following the basics. By integrating accessibility considerations into your workflow, rather than thinking about them at the end of the development process, you can make sites that are accessible and work better for everybody.

* Interestingly, Firefox will progressively select through items in the order they appear on the page, whereas Chrome will continue to select in source order. I’ve filed a bug report with the Blink team to this effect.

Enjoy this piece? I invite you to follow me at twitter.com/dudleystorey to learn more.