Accessibility: Keyboard Navigation

Last week, in the first of my follow ups to my Accessibility Primer, we looked at setting up a good foundation by using HTML and ARIA roles properly. Today we’re going to dive into the world of making sure that people can navigate your site using their keyboard.

Many, many people use just their keyboards for navigation because it’s easier on their wrists or hands, or they prefer it, or they don’t have the fine motor control to work a mouse or touchpad effectively. Making sure they can get around your site is pretty important. This is another population that wants to get at your content—if you make it possible for them to do it—and the reality is that it doesn’t take too much to make it possible.

First up is that keyboard navigators rely on link focus styling it’s how they know where they are. If you eliminate a link’s outline styling, they’ve lost their indicator. If you want a different focus state for your links, that’s fine. Just make sure you include that in your CSS. Perhaps you change the outline styling or you give it a border or an underline—I’m not telling you what to do for the focus state, I’m just reminding you to make sure you do something for it.

Another important factor to consider when testing to make sure users can navigate is the navigation order. Thankfully, links and buttons are already easy to tab to with the keyboard, so just by using proper HTML elements, you are well on your way. Links with empty href values won’t be accessible by tabbing, so make sure all your links have valid destinations. But that’s part of our good foundation: using links as links and buttons as buttons.

There may also be scenarios in which changing the tab order makes sense, such as when an error message pops up that contains a link to more information. Testing and navigating the site with your keyboard only will help you see the way it flows. Then you can figure out when it may be appropriate to adjust tabindex values to ensure a usable flow in the link order. It’s fairly rare to need to adjust tabindex above 0, but test to make sure the flow works for you.

The final bit that needs to be factored into keyboard navigation is any custom widgets you may have happening on your page. I like JavaScript interactivity just as much as the next person, but sometimes adding things via JavaScript means things don’t get put into the tab order.

You’ll want to test any interactive widgets heavily to make sure that you send focus to the right place at the right time—this assures that they’ll work well for the keyboard-only navigator. This doesn’t have to be terribly difficult, if the user opens a dialog box, send them back to where they were when it closes. But the coding and thinking through of this is important and I recommend reading more about it so you make sure you don’t miss anything. The A11Y Project is a fantastic resource with examples of accessible things like modals and tooltips.

Testing is a lot easier than you think. Just set aside your mouse or trackpad and navigate your site. How does it feel? Do you have friends or colleagues that prefer to keyboard only navigate? Ask them to test your site and give you feedback.

If you make sure your users can navigate via keyboard, on top of using good HTML and ARIA roles, you’re giving that many more people access to your content. That’s a goal worth striving for: making sure everyone has access.

This article originally appeared on the Bocoup blog and was edited by Brian Brennan.