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 content. Screen reader users who are blind or vision impaired will also use the keyboard to access and interact with content. Here are some general best practices.
Users Should Have the Ability to Navigate 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.
Landmarks and 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> </header> <nav role="navigation"> <ul> <li>Put primary navigation here</li> </ul> </nav> <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.
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
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
Stand-alone content that makes sense out of context from the rest of the document.
<article role=”article”></article>
complementary
Supporting content for the main content. For example, related links in a sidebar.
<aside role=”complementary”></aside>
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>
Add a Keyboard Focus Indicator to Menu Items, Buttons, Links, 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 by using the following CSS attribute,
A:focus
Example:
.top-box:focus {
outline-style: solid;
outline-width: 3px;
outline-color: #32a1ce;
}
<input class="top-box" value="I'll be blue when focused.">
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.