Accessibility Tip: Make Your Website Keyboard Accessible

In my new Accessibility Tip blog series, I’m going to focus, and expand on, one accessibility guideline in each post. If you’d like to view every single guideline, you can visit W3’s WCAG website. Otherwise, stop back here to see all of my tips and hopefully you can learn something new!

I think everyone in the web world has been hearing the buzz about accessibility lately, but let me give a quick introduction for those who are unfamiliar.

What is Website Accessibility?
Web accessibility is the inclusive practice of ensuring there are no barriers that prevent interaction with, or access to, websites by people with disabilities. Web Content Accessibility Guidelines (WCAG) defines how to make web content more accessible to people with disabilities. These Guidelines are broken down into 4 main principles:

1. Perceivable
2. Operable
3. Understandable
4. Robust

Today, I’m going to cover Guideline 2.1, which falls under the “Operable” Principle. Here we go!

Guideline 2.1: Keyboard Accessible

Goal: Make all functionality available from a keyboard.

Sounds simple enough, right? Well, there’s a lot to watch out for with this one. Here are the criteria to keep in mind:

Success Criteria 2.1.1: Keyboard

From WCAG: “All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints. The phrase “except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints” is included to separate those things that cannot reasonably be controlled from a keyboard. 

The intent of this Success Criterion is to ensure that, wherever possible, content can be operated through a keyboard or keyboard interface (so an alternate keyboard can be used). When content can be operated through a keyboard or alternate keyboard, it is operable by people with no vision (who cannot use devices such as mice that require eye-hand coordination) as well as by people who must use alternate keyboards or input devices that act as keyboard emulators. Keyboard emulators include speech input software, sip-and-puff software, on-screen keyboards, scanning software and a variety of assistive technologies and alternate keyboards. Individuals with low vision also may have trouble tracking a pointer and find the use of software much easier (or only possible) if they can control it from the keyboard.”

TL;DR: Wherever possible, content can be operated through a keyboard or keyboard interface.

Who does this help?

• People who are blind or with low vision (who cannot use devices such as mice that require eye-hand coordination or who may have trouble finding or tracking a pointer indicator on screen).
• People with motor disabilities may find using a mouse difficult and therefore use a keyboard.

What should I do?

Go through your website and pay attention to items such as links, menus, buttons, check boxes, radio buttons and form fields. After that, look at features like drag and drop, selecting text, resizing regions or bringing up context menus. Other examples of functionality may based on tasks such as adding or removing an item from a shopping cart or initiating a live chat session.

• Can users add an item to their cart using only the keyboard?
• If you have drag-and-drop functionality on your website, can items also be moved with only the keyboard?
• Can your users operate a Flash section embedded on your website? If so, great. If not, you should really consider rebuilding this section in HTML (Adobe will no longer support Flash starting in 2020).
• When you tab through your website, can you access every interactive element?
• When you tab through your website, do you see the focus indicator appear? If you don’t see this, or if you see it and then it disappears, this makes your content only accessible by mouse and needs to be rectified.

Note: If you want to meet the highest WCAG level guidelines (AAA), then you must ensure that all content is operable from the keyboard. There are NO exceptions.

Success Criteria 2.1.2: No Keyboard Trap

From WCAG: “If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.”

TL;DR: If I can tab into an element, I need to be able to tab out of it.

Who does this help?

• People who use their keyboard, or alternative technologies, to navigate the web.

What can I do?

Go through your website and pay attention to your navigation, any embedded/i-framed/plug-in elements on your website, or any other elements with special functionality.

• Can you tab into your main content section after going through your navigation? A common trap is a website’s navigation–a user will be able to tab through each item in the navigation, but then are unable to jump down to the main content. This makes nearly your entire website inaccessible.
• Can you tab into any of your other embedded or special functionality sections? Can you then tab out of them?

Success Criteria 2.1.4: Character Key Shortcuts

From WCAG: “If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then a mechanism is available to turn them off, a mechanism is available to remap the shortcuts, the shortcut is only active when that component has focus.”

TL;DR: If there are keyboard shortcuts in your website/web-app, they need to be able to be turned off or modified.

Who does this help?

• “Speech users will be able to turn off single-key shortcuts so they can avoid accidentally firing batches of them at once. This will allow speech users to make full use of programs that offer single-key shortcuts to keyboard users.”
• “Keyboard-only users who have dexterity challenges can also be prone to accidentally hitting keys. Those users would be able to avoid problematic single character shortcuts by turning them off or modifying them to include at least one non-character key.”
• “Allowing all shortcut keys to be remapped can help users with some cognitive disabilities, since the same shortcuts can be assigned to perform the same actions across different applications.”

What can I do?

Does your website have any custom keyboard shortcuts? No? Great! You don’t need to do anything. Yes? Then:

• Allow your users to be able to turn off these shortcuts.
• Allow your users to change the shortcuts to their own preferences. For example, if your shortcut is to press the letter “s” to activate a search bar, that can be disruptive to those who accidentally hit the “S” key or for those who already have their “S” key programmed to do something else. If they can re-program your website to push CTRL, for example, instead of “S”, it will make the experience much less frustrating for them.

That’s it for this post! I hope you can take away a few key points and boost your website’s accessibility!