accessibility-guidelines

This document is in beta. Help us by reporting issues via Github or email.

Back to the overview page

Keyboard

Make sure every task can be completed using just the keyboard.

It must be possible for someone using only a keyboard to access all content and complete all tasks.

---

On this page:

• Requirements
• Guidance for code
• Guidance for Quality Assurance
• More info

---

Requirements

• All actionable components can be reached and activated using the keyboard alone.

Why?

• This ensures that people with mobility or dexterity impairments who do not use a mouse can successfully complete their goals.

• Many people don’t rely on a mouse, trackpad or touchscreen to use websites:

  • People who have developed Repetitive Strain Injuries or Arthritis;
  • Screen reader users;
  • Computer power users find keyboard keys and shortcuts to navigate the web.

• Making a website or app accessible with a keyboard also ensures that it is accessible with other input devices that emulate keyboards, like Switch devices or Sip-and-puff devices.

How does this work?

See Rob Dodson explain ‘Focus’ in this short video:

---

Guidance for code

Native HTML interactive elements are keyboard accessible out of the box

• Use native HTML elements that provide keyboard access automatically;
• For inactive elements, ensure focus is disabled for controls that support the disabled attribute.

If you don’t make use of HTML interactive elements, you need to implement keyboard accessibility yourself

• If you create an interactive element yourself, make it focusable with the ‘Tab’ key with tabindex="0". When this element is disabled set tabindex="-1" to remove it from the tab order.

• Also make sure that you implement responses to keyboard presses that users expect.

  • For example, people expect to be able to activate buttons using either ‘Enter’ or ‘Space’.
  • One of the Rules of ARIA is:

  “All interactive ARIA controls must be usable with the keyboard.”

  • The ARIA Authoring Practices Guide tells you what keyboard support you should implement for many common user interface design patterns.

Hide hidden or off-screen elements for keyboard users and screen reader users too

• Hidden content (that is off-screen like a side-drawer, or behind other content such as a pop-over, for example), should not be navigable for users of assistive technology as they may think they can interact with this content.
  • Use aria-hidden="true" and tabindex="-1" on each element that would otherwise be focusable, or the inert attributed, which needs to be polyfilled, on an ancestor element.

Common mistakes

• A custom widget has been created, but the necessary keyboard support has not been provided. For example:
  • buttons created using span or div elements rather than button or input elements
  • links created using the span or div, rather than the a element
  • links using a a element but without a URL for their href attribute, or if preventDefault() has been used
• An <a> element has been used as the basis for a button, but the additional keyboard interaction (activation with the space key) has not been provided;
• The tabindex attribute has been used on an element with a value of -1 to mistakenly remove it from the tab order.

Example: A link with an image

<!-- standard element that is interactive by default -->
<a href="..."><img src="back.jpg" alt="back" /></a>

Failure example

<!-- clickable image that is not keyboard accessible -->
<img src="back.jpg" alt="back" onclick="myClickEvent();" />

Example: A carousel that is keyboard accessible

A carousel that supports swiping left and right touch events such as touchstart, touchend, and touchmove can supplement these gestures with keyboard access using buttons, or by watching key presses:

<button onClick="...">Previous</button> <button onClick="...">Next</button>

Failure example

Listening for touch gestures without providing equivalent control via keyboard:

<script type="text/javascript">
  // perform some action on touch
</script>

...

<div
  ontouchstart="touchStart(event);"
  ontouchmove="touchMove(event);"
  ontouchend="touchEnd(event);"
  ontouchcancel="touchCancel(event);"
>
  <!-- Carousel content -->
</div>

More guidance for Web

• Inert Polyfill – A11ycasts #02 by Rob Dodson and Google
• Keyboard accessibility article by WebAIM
• Accessible JavaScript article about JavaScript event handlers by WebAIM
• Using the tabindex attribute
• Ridiculously easy trick for keyboard accessibility
• W3C’s detailed explanation of this guideline with techniques and examples.

---

Guidance for Quality Assurance

This section is just a placeholder

1. On the web page, press the ‘Tab’ keyboard key several times
2. For every interactive element on the page:
   1. Check the ‘keyboard focus’ reaches it as you do 1.
   2. When a button or link is selected, press ‘Enter’. Check that this activated the button or link.

Note: If you’re testing on a mac using Safari or Firefox, you’ll need to do this first: https://dequeuniversity.com/mac/keyboard-access-mac. Alternatively, checking just in Edge or Chrome is enough for this.

---

More info

Official wording in the Web Content Accessibility Guidelines

2.1.1 Keyboard: 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. (Level A)

Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.

Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

See the W3C’s detailed explanation of this guideline with techniques and examples.

Sources

• W3C Web Content Accessibility Guidelines 2.1
• Government Digital Service WCAG 2.1 Primer
• Barclays’ Accessibility Design Standards
• The BBC’s Mobile Accessibility Guidelines

Contribute

This document is in beta. Help us by reporting issues via Github or email.

This site is open source. Improve this page.