How Should Keyboard Navigation Work in Web Applications?

To make your web content accessible for users, it should be navigable by keyboard alone. This benefits all users, including but not limited to those with motor and visual impairments.

How should my web content behave when navigated by keyboard?

• You should be able to move through all the interactive items (e.g. buttons, links, form inputs) with the tab key
• Non-Interactive items (e.g. paragraphs, images) should not receive focus when tabbing through the page
• The focused element should be clearly highlighted as you tab through items
• The order in which you tab through the items should make sense. Usually, this means it simply follows the same order that you would conventionally read the screen, e.g. top to bottom, and in most cases, left to right

Depending on your content, good keyboard navigation can be achieved in your app without much additional effort, but some areas might need some particular attention.

The order in which you declare your HTML matters

It's vital to remember that in terms of tabbing with the keyboard, the order you declare your HTML in matters and not how it visually looks on the page once your CSS has aligned items.

Pay particular attention to elements that appear horizontally next to each other on your page - for example, if you have a side panel with ancillary links, declare it last, so it doesn’t interrupt the tabbing order of your more important elements.

One simple way to check your tabbing order is to literally tab through all the interactive items yourself in the browser. However, if you have a lot of items on your page, or want to be able to log a nice clear bug-ticket, I would totally recommend Accessibility Insights "show tab stops" feature, which generates a visual report of your tabbing order, for example:

Use tabIndex wisely

If you have created a custom-component that is interactive, you will need to employ the tabIndex attribute. A good example of this would be a clickable Card component.

Before using tabIndex be sure to consider if a standard interactive HTML element (e.g. button, link) would fit the purpose

To insert your custom component into the tabbing order, you may add the attribute tabIndex="0". This inserts the element into the tabbing order at its natural position. For example, a clickable card component might look like:

<div class="card-component" tabIndex="0">
  ... 
</div>

Be mindful of your focus styles

Every browser ships with default styling of focused elements (most commonly a plain blue outline around the element). Many designs or branding guidelines might conflict with this focus styling but it's important to remember that if the default styling is removed, it must be replaced with some other indicator of focus. Otherwise, keyboard users will have no visual clue what element they can currently interact with.

Focus can be styled with the :focus CSS pseudo selector, for example:

.my-button:focus {
  background-color: yellow;
}

Give it a whirl!

I think all developers rely on keyboard shortcuts for efficiency, so why not try going all-out for an afternoon? Take a mouse/trackpad vacation, and try using only your keyboard - do sites and applications work as you expected? Let me know how you get on in the comments 😄

---

Did you find this post useful? Please consider buying me a coffee so I can keep making content 🙂

Comments

[Jen]

Thanks for your article(s) on accessibility! It's easy to look over these things especially when you or your team don't have disabilities. I do consultancy work in UK Government where public sector services need to be accessible, so projects often have a budget for accessibility testing which isn't a luxury for some.

Government Digital Service ran an audit on automated checkers and it turns out they're pretty bad at catching accessibility barriers 😅 but I think they're a good first step if WCAG 2.1 compliance hasn't been thought about at all. (GDS's results are here ➡️ alphagov.github.io/accessibility-t...)

[Suzanne Aitchison]

Amazing - thank you for sharing that, it's very interesting to see the data collected together like that. I'm definitely going to take a bit more time to read through the detail - some things you can expect an automated tool not to pick up due to the nuance, but very interesting to see even things like contrast ratio being missed in such a large proportion of audit tools!

I totally agree, an automated checker should be used only as a kind of "initial check" to filter out any obvious issues before the code gets as far as code review or test. These tools can easily miss things, especially when the real test is the overall experience, not a box checking exercise. And there are some things I don't think an automated tool could ever assess in place of a human, e.g. whether or not alternative text is actually conveying what it should in the given situation.