Posted on Friday, 9 May 2025 by Demelza Feltham in Design and development

Tags: Assistive Technology, Code, Foundations, WCAG

By prioritising semantic HTML and offering keyboard-friendly alternatives for complex interactions, you help create a more inclusive experience for people who use a keyboard.

Keyboard accessibility ensures that people who navigate websites or apps using a keyboard, whether due to disability, injury, or personal preference, have an experience that is just as functional and efficient as those using a mouse, touch, or other input methods. While the interactions may differ, the goal is to provide equal usability and access to content. Prioritising semantic HTML and offering keyboard-friendly alternatives for complex interactions enhances the experience for all users.

Who benefits from keyboard accessibility?

Keyboard accessibility is essential for many people with different types of disability that may be permanent, temporary, or situational, or for people who prefer keyboard navigation:

• People browsing with a screen reader who cannot see or have low vision rely on keyboard navigation to move through content efficiently
• People with moving disabilities and limited dexterity may be unable to use a mouse and instead browse with a keyboard
• People with temporary injuries, like a broken wrist, repetitive strain injury, or a minor finger injury can find it difficult to use a mouse, highlighting the importance of keyboard support

By ensuring robust keyboard support, you create a more inclusive and user-friendly experience for everyone.

Where possible, use HTML

There may be situations where delivering an identical experience isn’t possible, so an equivalent experience must always be provided. For example, when exploring an interactive map, people with a mouse might click, drag, or scroll to move around. While these exact interactions may not translate directly to a keyboard, alternative navigation options, such as arrow-key navigation or keyboard-accessible buttons, can provide an equivalent experience.

When building accessible interfaces, start with semantic HTML. In line with the first rule of ARIA, HTML has already done most of the heavy lifting. While ARIA is a powerful tool for remediation, it should be a last resort. Many accessibility issues can be avoided simply by using the correct native elements.

One of the biggest advantages of semantic HTML is that it requires no extra effort for keyboard support. Native interactive elements, such as buttons (<button>) and links with a valid href (<a href="#">), come with built-in keyboard functionality, ensuring a more accessible experience without additional coding.

For example, compare these two buttons:

A native HTML button:

<button>I am a button</button>

• Uses the <button> element, which is inherently interactive with a keyboard
• Automatically supports keyboard interactions, for example pressing Enter or Space to activate
• Is focusable by default (no need for tabindex)
• Works with screen readers and assistive technology

A custom button:

<div role="button" tabindex="0">I am also a button</div>

• Requires role="button" so assistive tech recognises it as a button
• Needs tabindex="0" to be focusable
• JavaScript must be added to handle keyboard activation (Enter or Space), as <div> does not natively support it

If you can use native HTML, do it. It saves you and your team time, reduces the risk of accessibility failures, and ensures built-in support for keyboard navigation. However, there are instances where native HTML alone may not be enough.

When HTML alone isn't enough

Sometimes, native elements don’t fit the design or functional requirements, and a custom solution is needed. Examples include:

• Custom dropdowns, when <select> is too limited
• Modals or dialogs, beyond what <dialog> provides
• Complex interactive widgets, for example sortable lists, carousels, rich text editors

When creating custom components, you must follow the third rule of ARIA to ensure they remain accessible to keyboard users. This means handling focus properly, supporting keyboard interactions, and maintaining expected behaviours.

Common keyboard accessibility failures

Most common issues associated with the keyboard accessibility of custom controls can be avoided. Two instances that are seen regularly within accessibility assessments result in a failures against:

• 2.1.1 Keyboard (Level A)
• 2.4.3 Focus order (Level A).

Clickable controls without tabindex

A common issue is interactive elements that work with a mouse but aren’t accessible by keyboard. This often happens when <div> or <span> elements are used instead of native HTML interactive elements.

This is problematic because by default <div> and <span> elements are not focusable. Similarly, people cannot tab to them, making them completely inaccessible via keyboard. However, these issues can be avoided by following a few steps.

If you must use a <div> or <span> for styling reasons, make it keyboard accessible by:

• Adding a tabindex="0" to bring it into the focus order, for example <div role="button" tabindex="0">Click me</div>
• Using JavaScript to add keyboard support and event handlers, for example <div role="button" tabindex="0" onclick="doSomething()" onkeypress="handleKeyPress(event)">Click me</div>

However, using a real <button> is always the better solution.

Non-interactive elements receiving focus

Some developers try to improve accessibility by adding tabindex to non-interactive elements, thinking it will help screen reader users. However, this actually causes more issues than it solves. The motivation behind doing this is often an attempt to create a richer experience for screen reader users, coupled with a misunderstanding of the difference between keyboard and screen reader navigation. Interactive controls receive focus, not static text. So, when static text receives focus by virtue of tabindex values, it creates confusion for people who may believe they can interact with an element that is actually static. It disrupts expected navigation as keyboard users don’t expect to focus on static text.

A common issue arises when tabindex is applied to headings, causing focus order problems. Since non-interactive elements receive focus, they create unnecessary tab stops, disrupting the keyboard navigation experience.

For screen reader users, headings can already be navigated efficiently using built-in shortcuts. For example, when the screen reader NVDA is in browse mode, pressing H moves to the next heading (with its level announced), while Shift + H moves to the previous one. Because these elements are inherently accessible, forcing focus on them with tabindex is redundant.

Avoid using tabindex on non-interactive elements. Instead, structure content with proper headings, landmarks, and semantic elements to enhance navigation. Reserve tabindex only for custom interactive controls when necessary.

Summary

• Use native HTML whenever possible
• Ensure custom controls are keyboard focusable by adding tabindex="0"
• Ensure custom controls are interactive by adding JavaScript
• Avoid adding tabindex to non-interactive controls

Further reading

• 2.1.1 Keyboard (Level A)
• 2.4.3 Focus order (Level A)
• When to use tabindex=0, Graeme Coleman
• Keyboard accessibility myths and WCAG, Graeme Coleman
• Foundations: native versus custom components, Ela Gorla
• Understanding screen reader interaction modes, Léonie Watson
• The difference between keyboard and screen reader navigation, Léonie Watson

Next steps

Read more accessibility foundations posts or sign up for Accessibility Unlocked, our free six-day newsletter series designed to help you kick-start accessibility.