This document is in beta. Help us by reporting issues via Github or email
On this page:
Make sure every task can be completed using just a keyboard.
It must be possible for someone using a keyboard to complete all tasks in a website or app. This ensures that people with mobility impairments who do not use a mouse can successfully complete their goals.
This ensures that people with mobility or dexterity impairments who do not use a mouse can successfully complete their goals.
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.
This section needs more content. Contribute via Github or email.
See the W3C’s detailed explanation of this guideline with techniques and examples.
This section needs more content. Contribute via Github or email.
This section needs more content. Contribute via Github or email.
This section needs more content. Contribute via Github or email.
disabled attribute.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. Look at the keyboard support and focus management guidance in the ARIA Authoring Practices Guide, which covers many common user interface design patterns.
One of the Rules of ARIA is that:
“All interactive ARIA controls must be usable with the keyboard.”
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.span or div elements rather than button or input elementsspan or div, rather than the a elementa element but without a URL for their href attribute, or if preventDefault() has been used<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;tabindex attribute has been used on an element with a value of -1 to mistakenly remove it from the tab order.<!-- standard element that is interactive by default -->
<a href="..."><img src="back.jpg" alt="back" /></a>
<!-- clickable image that is not keyboard accessible -->
<img src="back.jpg" alt="back" onclick="myClickEvent();" />
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>
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>
This document is in beta. Help us by reporting issues via Github or email