WCAG Master Guide: Keyboard Accessibility

Most people use both a mouse and keyboard to complete tasks on their computers and browse the web. However, some users are unable to use a mouse and rely solely on keyboard controls. 

Keyboard accessibility forms part of the Operable requirements of the Website Content Accessibility Guidelines (WCAG) and is another aspect to consider when taking steps to remediate your website. 

What Is Keyboard Accessibility?

Keyboard accessibility forms part of WCAG because it helps ensure that all users can access content and information without the need for a mouse.

WCAG requires all websites to be fully functional and operational using only a keyboard. This requirement caters to users with low vision and blindness as well as those with motor and cognitive impairments. 

Along with being keyboard operable, a site should have a visible keyboard focus, the necessary tab order, and limit any keyboard traps that could hinder the user experience.

WCAG Keyboard Accessibility Success Criteria

Here are the success criteria you would need to meet for keyboard accessibility in order to achieve Level A or higher.

Keyboard Interface

All content on your site should be operable via a keyboard interface without the need for specific keystroke timing. 

The only time this wouldn’t apply is if an underlying function requires input that depends on a user’s specific journey. Someone handwriting text or engaging in free-hand drawings would be an example of this. 

Even with a keyboard interface, mouse and other input methods should not be discouraged.

A keyboard interface caters to users who cannot rely on hand-eye coordination to navigate a website. It also aids people who use alternate keyboards or input devices that act as keyboard emulators. Speech input software, on-screen keyboards, and sip-and-puff devices are some examples of this. 

This success criterion will help you meet the minimum requirements of WCAG Level A and higher.

No Keyboard Trap

This is another non-negotiable WCAG keyboard accessibility requirement.

Users should be able to interact with all components on your website using only a keyboard interface. 

If a keyboard focus can be moved to an element on a web page using a keyboard interface, a user should also be able to move it away without encountering a problem. 

Should an action require more than unmodified arrow or tab keys, or non-standard exit methods, the user should be advised on the steps to take to move the keyboard focus. 

The purpose of this requirement is to ensure the keyboard focus never gets trapped without a user knowing what to do. This is generally an issue when there are multiple forms of content on a page. A pop-up would be a prime example. 

Character Key Shortcuts

Should you implement a content keyboard shortcut using only an upper or lower-case letter, punctuation, number, or symbol, the following requirements need to be met:

• Users should have the ability to turn the shortcut off.
• Shortcut remapping capabilities need to be in place to include one or more non-printable keys such as Ctrl or Alt.
• The shortcut should only be active when that component has focus. 

Implementing keyboard shortcuts is perfectly fine, but they can be a problem for speech input users or those who are prone to accidentally hitting the wrong keys. 

The only components that this requirement does not apply to is drop-down menus and list boxes because these components will generally have an automatic focus. 

Keyboard Accessibility Best Practices

Keyboard accessibility is an integral part of making your website accessible to disabled users and meeting essential WCAG requirements. Here are a few best practices you can apply to ensure you can achieve Level AA. 

Implement good HTML semantics. HTML semantics clearly describe the meaning of a website element to both the browser and the developer. These semantics will make it easier for a user to know which elements to focus on with their keyboard interface.

Design with simplicity in mind. You want to design your site in a way that truly simplifies the browsing process. A user should be able to reach and engage with content in as few keystrokes as possible. 

Test across browsers and screen readers. You never know how a keyboard shortcut might function based on the browser or screen reader being used, which is why it’s important to test across different versions and technologies.

Specify control appearance. Users with low vision will benefit from knowing how a keyboard focus will look. This also reduces the chance of inadvertent control activation.

Frequently Asked Questions