You are currently viewing Success Criterion 2.1.1 Keyboard

Success Criterion 2.1.1 Keyboard

WCAG Principle: Operable

Guideline 2.1: Keyboard Accessible (Make all functionality available from a keyboard)

Conformance Level: A (Minimal Requirement)

What is Success Criterion 2.1.1?

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.

This success criterion requires websites to be easily usable with a keyboard alone, without relying on other input devices like a mouse or touch screen. This means users should be able to navigate and interact with content and elements such as links, buttons, and form fields using keyboard commands. The exception to this rule are functions that rely on the path of the user’s movement instead of endpoints, e.g., websites that support drawing.

How does it make your website accessible?

Using a mouse can be difficult for people with mobility or dexterity impairments and virtually impossible for blind users. Meeting this success criterion allows them to access your web content using keyboards or keyboard emulators. (Keyboard emulators are assistive technology solutions, such as speech input software, sip-and-puff software, on-screen keyboards and scanning software.)

How to Meet Success Criterion 2.1.1

Common mistakes that cause websites to fail success criterion 2.1.1:

  • Widgets lacking keyboard support.
  • Access keys conflicting with assistive technology keys.
  • Incorrect use of Tabindex, making elements inaccessible via sequential keyboard navigation.
  • Inaccessible image links opening in new tabs.
  • Dialogue boxes without keyboard-accessible closing options.

How to fix these mistakes:

  • Make all widgets and interactive elements keyboard accessible. 
  • Use unique key combinations to avoid any conflicts between access keys and assistive technology keys.
  • Use the <tabindex=0> attribute for custom UI elements to make them focusable. 
  • Ensure that image links opened in new tabs or windows are accessible via the keyboard.
  • Include visible closing options for dialogue boxes. A good option is to use standard keyboard commands, such as the Esc key.

Helpful tips for developers:

  • Prioritize HTML accessibility by writing clean HTML and CSS codes since they are keyboard-operable by default.
  • Make sure that there is a visible focus for all the active elements on the page.
  • Provide appropriate event handlers for custom-scripted elements so that they are operable by their respective keys.

How to test if you've met compliance:

  • Identify all functionality on the content.
  • Check that all functionality is accessible via  the keyboard or keyboard interface.
  • Use the keyboard to make sure everything is in the tab order using the tab key to navigate from item to item.
  • Ensure that the order goes from left to right and from top to bottom. (Read this article on WCAG 1.3.2 to learn about meaningful sequence).  

If checks 1 – 4 are true, then your web content passes this success criterion.

Bad and Good Examples (Developer Code)

bad Code Snippet

<div class="widget" onclick="performAction()">
  Click Me
</div>

In this code snippet, there is a clickable widget represented by a <div> element. The onclick attribute triggers the performAction() function when the widget is clicked. However, this code does not provide keyboard accessibility. Users who rely on keyboard navigation won’t be able to interact with the widget because it lacks keyboard support.

good Code Snippet

<button class="widget" onclick="performAction()" onkeydown="handleKeyDown(event)">
  Click Me
</button>

This improved code snippet has a button element (<button>) which represents a widget. It includes the onclick attribute to trigger the performAction() function when clicked. Also, the code includes the onkeydown attribute to handle keyboard events by invoking the handleKeyDown() function, passing the event object as an argument.

Including the onkeydown event handler ensures that keyboard users can activate the button using the keyboard’s Enter or Space key. The handleKeyDown() function would contain the necessary logic to handle keyboard interactions, such as detecting the appropriate key press and performing the desired action accordingly.

Frequently Asked Questions

What is keyboard-only testing?

Keyboard-only testing is a way to evaluate the accessibility of a website or app using only the keyboard. The goal is to ensure all users, especially those with disabilities who depend on assistive technologies, can navigate and interact with the content effectively.

Why should I test for keyboard accessibility?

You should test for keyboard accessibility to identify issues that makes navigating your web content via keyboard difficult or impossible. It is important because such issues can result in a poor user experience for people with disabilities.

Ready To Become
Compliant?

Leave a Reply