Keyboard Accessibility
- Christina Lutz-Hatfield
Table of Contents
- 1 Overview
- 2 Allow Users to Navigate Content Using Only the Keyboard
- 3 Create a Logical Tab Order
- 4 Create a Logical Focus Order
- 5 Landmarks and Landmark Roles
- 6 Buttons and Role Attribute
- 7 Keyboard Focus Indicator
- 8 Ensure that Keyboard Users are Not Trapped
- 9 Ensure that Keyboard Interactions and Functionality are Predictable
- 10 Ensure That Content is Not Obscured When Receiving Keyboard Focus
- 11 Reduce Accidental Activation of Keyboard Shortcuts
- 12 Hover States and Focusable Content
- 13 Testing for Keyboard Accessibility
- 14 WCAG Related Guidelines
Overview
Keyboard accessibility is one of the most important aspects of web accessibility.
Many users with motor disabilities rely on only using a keyboard to access online content. These are users who are unable to use a mouse.
Screen reader users who are blind or vision impaired will also use the keyboard to access and interact with content.
Make all functionality available from a keyboard.
Ensure that 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.
Allow Users to Navigate Content Using Only the Keyboard
Natively-Accessible Keyboard Elements:
By default, users can navigate to links, buttons, and form controls with a keyboard. These elements are natively-accessible by using the following keystrokes.
Tab: Navigate to links and form controls.
Shift + Tab: Navigate backwards.
Enter: Activate links and buttons.
Spacebar: Activate checkboxes and buttons.
Arrow keys: Radio buttons, select/dropdown menus, sliders, tab panels, autocomplete, tree menus, etc.
Keystrokes Accessible Only Through a Screen Reader:
In addition to the natively-accessible keystrokes, screen reader users have many other keystrokes available to them to help them navigate through a webpage. For example they can use the “H” key to tab through all the headings on a page.
Create a Logical Tab Order
Keyboard tab order allows keyboard users to properly navigate a web page. If tab order is implemented correctly a webpage will read similar to a book to a keyboard user. When done incorrectly a keyboard user may miss out or become confused with the order of the web page.
Tab order is important for proper navigation through a keyboard interface. The keyboard tab order must be coordinated with the structure of the webpage. The default keyboard navigation order must be logical and intuitive. The tab order should follow the visual flow of the page: left to right, top to bottom – header first, then main navigation, then page navigation (if present), and finally the footer.
The best practices for keyboard tab order should include the following:
Tab order should have a logical reading order, similar to a book. It should be from left to right and top to bottom.
As you are tabbing through a website, there must be a visible indication of where the tab focus is at.
When using the tabindex to adjust the tab order, use tabindex= "0" or tabindex= "-1" ONLY
Tabindex values of 1 or higher must NOT be used.
Please see our section entitled “Create a Logical Tab Order” for more detailed information and examples on how to create a logical tab order.
Create a Logical Focus Order
Keyboard users should be able to navigate content in a correct order.
Elements should receive focus in an order that preserves meaning.
Ensure that when users navigate sequentially through content, they encounter information in an order that is consistent with the meaning of the content and can be operated from the keyboard.
This reduces confusion by letting users form a consistent mental model of the content.
There may be different orders that reflect logical relationships in the content. For example, moving through components in a table one row at a time or one column at a time both reflect the logical relationships in the content.
The focus order may not be identical to the programmatically determined reading order as long as the user can still understand and operate the web page.
For example, a screen reader user interacts with the programmatically determined reading order, while a sighted keyboard user interacts with the visual presentation of the Web page. Care should be taken so that the focus order makes sense to both of these sets of users and does not appear to either of them to jump around randomly.
For example:
Focusable components need to receive focus in an order that preserves meaning and operability only when navigation sequences affect meaning and operability.
In those cases where it is required, there may be more than one order that will preserve meaning and operability.
If there is more than one order that preserves meaning and operability, only one of them needs to be provided.
Please see more detailed information on how to comply with this guideline.
Landmarks and Landmark Roles
Break the web page into areas/regions and assign landmark roles. Use HTML 5 in combination with ARIA roles.
Assistive technologies such as screen readers provide shortcut keys to navigate through page elements that have been defined as landmarks/regions and roles, or to jump to specific structural elements (for instance, M for the main content), and/or provide a list of all structural elements in the document.
Screen readers provide a list of all landmarks/regions on a page and shortcut keys to navigate among them.
Screen reader users can also navigate by landmark role.
Here is an example:
<header role="banner">
<p>Put company logo, etc. here.</p>
<nav role="navigation">
<ul>
<li>Put primary/global navigation here</li>
</ul>
</nav>
</header>
<main role="main">
<p>Put main content here.</p>
</main>
<footer role="contentinfo">
<p>Put copyright, and footer related content , etc. here.</p>
</footer>
Common Landmarks and Roles
Provide other landmarks and roles as needed to specify areas/sections on a webpage.
header / banner
Site-orientated content, such as the name of the web site, title of the page, and/or the logo.
<header role="banner"> </header>
main / main
The main or central content of the page.
<main role="main"></main>
search
This section contains the search functionality for the site.
<form role=”search”></form>
article / article
Stand-alone content that makes sense out of context from the rest of the document.
<article role=”article”></article>
aside / complementary
Supporting content for the main content. For example, related links in a sidebar.
<aside role=”complementary”></aside>
footer / contentinfo
Informational child content, such as footnotes, copyrights, links to privacy statement, links to preferences, and so on.
<footer role=”contentinfo”></footer>
Buttons and Role Attribute
Most HTML elements have a default role that is presented to assistive technology. For example, a button has a default role of "button" and a form has a default role of "form".
Always use the native button role so that keyboard only users are able access/select the buttons by using the tab and enter keys.
Example:
<form action="/action_page.php" method="get" id="form1"></form>
<button type="submit" form="form" value="Submit">Submit</button>But there are also buttons that are created that are not using a form element, just a regular hyperlink. Add a role attribute to those types of button links to help screen reader users identify the purpose of the link and for them to quickly be able to tab to all the buttons on the page by clicking on the “B” key.
Example:
<a href="#" role="button" onclick="" class="btn btn-primary"><span>Apply Online</span></a>
Keyboard Focus Indicator
Add a keyboard focus indicator to menu items, buttons, links and form elements.
A keyboard user typically uses the Tab key to navigate through interactive elements on a web page—links, buttons, fields for inputting text, etc. When an item has keyboard "focus", it can be activated or manipulated with the keyboard.
A sighted keyboard user must be provided with a visual indicator of the element that currently has keyboard focus. For example a border or outline.
Browsers will by default provide a visual border around these elements when they are in focus. Usually a blue border or dotted outline. However the default style may not provide enough color contrast between foreground and background. In other cases the outline may not be visible as the element may have already been styled with a specific border or outline or made invisible.
Apply a keyboard focus outline that has sufficient color contrast against the background by using the following CSS attribute,
A:focus
The contrast ratio of the keyboard focus indicator must be at least 4:5 against the background and 3:1 against adjacent colors.
Example:
Ensure that Keyboard Users are Not Trapped
Ensure that content does not "trap" keyboard focus within subsections of content on a web page.
There may be times when the functionality of the web page restricts the focus to a subsection of the content. When this is the case, keyboard users should be provided with a mechanism to leave that state and "untrap" the focus by using only the keyboard.
Please see more detailed information on how to comply with this guideline.
Ensure that Keyboard Interactions and Functionality are Predictable
On Focus
When a user interface component receives keyboard focus, it should not initiate or trigger a change of context.
For example:
forms should not automatically be submitted when a form element receives keyboard focus;
new windows or popups should not be launched when a component receives keyboard focus;
focus should not unexpectedly be changed to another component when that component receives keyboard focus;
Users should be provided with a mechanism to initiate the change of context.
Please see more detailed information on how to comply with this guideline.
On Input
Forewarn users if their context will change based on their input.
Content that behaves predictably is especially important to people with disabilities.
Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.
Ensure that entering data or selecting a form control has predictable effects.
Changing the setting of any user interface component is changing some aspect in the control that will persist when the user is no longer interacting with it. So checking a checkbox, entering text into a text field, or changing the selected option in a list control changes its setting, but activating a link or a button does not.
Changes in context can confuse users who do not easily perceive the change or are easily distracted by changes.
Changes of context are appropriate only when it is clear that such a change will happen in response to the user's action.
Provide users with a submit button to initiate a change of context.
Describe what will happen before a change to a form control that causes a change of context to occur is made.
Please see more detailed information on how to comply with this guideline.
Ensure That Content is Not Obscured When Receiving Keyboard Focus
Ensure that when an item gets keyboard focus, it is at least partially visible.
People who can't use a mouse need to see what has keyboard focus.
Keep the focused item visible.
For sighted people who rely on a keyboard (or on a device that operates through the keyboard interface, such as a switch or voice input), knowing the current point of focus is critical.
The component with focus signals the interaction point on the page.
Where users cannot see the item with focus, they may not know how to proceed, or may even think the system has become unresponsive.
Reduce Accidental Activation of Keyboard Shortcuts
Reduce accidental activation of keyboard shortcuts. Character key shortcuts work well for many keyboard users, but are inappropriate and frustrating for speech input users — whose means of input is strings of letters — and for keyboard users who are prone to accidentally hit keys.
Allow users to turn off or reconfigure shortcuts that are made up of only character keys.
If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following should apply:
Turn off
A mechanism is available to turn the shortcut off;
Remap
A mechanism is available to remap the shortcut to include one or more non-printable keyboard keys (e.g., Ctrl, Alt);
Active only on focus
The keyboard shortcut for a user interface component is only active when that component has focus.
Please see more detailed information on how to comply with this guideline.
Hover States and Focusable Content
Additional content that appears and disappears in coordination with keyboard focus or pointer hover often leads to accessibility issues. Reasons for such issues include:
the user may not have intended to trigger the interaction
the user may not know new content has appeared
the new content may interfere with a user's ability to do a task
Examples of such interactions can include custom tooltips, sub-menus and other nonmodal popups which display on hover and focus. The intent of this success criterion is to ensure that authors who cause additional content to appear and disappear in this manner must design the interaction in such a way that users can:
perceive the additional content AND
dismiss it without disrupting their page experience.
There are usually more predictable and accessible means of adding content to the page, which authors are recommended to employ. If an author does choose to make additional content appear and disappear in coordination with hover and keyboard focus, this success criterion specifies three conditions that must be met:
dismissable
hoverable
persistent
Please see more detailed information on how to comply with this guideline.
Testing for Keyboard Accessibility
Testing for Keyboard Accessibility
WCAG Related Guidelines
1.3.1 Info and Relationships (Level A)
1.3.2 Meaningful Sequence (Level A)
1.4.11 Non-Text Contrast (Level AA)
1.4.13 Content on Hover or Focus (Level AA)
2.1.2 No Keyboard Trap (Level A)