Keyboard Accessibility

Something to Think About...


Ensure that all content can be accessed with the keyboard alone.

Keyboard accessibility is one of the most important aspects of disability access. Blind people generally cannot use a mouse because they cannot see where to click. They use their keyboard almost exclusively. Additionally, some individuals with low vision may use a keyboard for improved interactions if the page is enlarged and the contrast is high.

Some individuals with motor disabilities cannot use a mouse or may have difficulty using a mouse. Some have tremors which don't allow for fine muscle control. Others have little or no use of their hands, due to a spinal cord injury, brain damage, or some other cause. Some people simply do not have hands, whether due to a birth defect, an accident, or amputation. There is an almost limitless list of conditions that could make mouse usage difficult or impossible.

Those who cannot use a mouse may not be able to use a keyboard either. Some use "puff and sip" devices activated by airflow from the mouth. Others use single-switch devices - consisting of a piece of hardware with one button that can be pushed. One thing that all of these devices have in common is that they interact with the computer in a way that mimics the functionality of the keyboard. If a web site is not keyboard-accessible, you will shut many people out.

Keyboard Testing

With modern web accessibility, there are many ways in which keyboard accessibility can become difficult or impossible. Fortunately, keyboard testing is easy - simply put the mouse away and test the page using only a keyboard. The tab and shift + tab keys can be used to navigate through links and form controls, and Enter can be used to activate links, buttons, or other interactive elements. Ensure that all page functionality is available using only the keyboard.

Potential Problems

Focus indicators

When navigating a page via the keyboard, a sighted user must be provided a visual indicator of what element currently has keyboard focus, and could thus be activated or manipulated via the keyboard. A basic focus indicators is provided by the web browser and is typically shown as a border (called an outline) around the focused element. CSS display:none; or display:0; causes the browser to turn off the default outline or focus indicator. Without focus indicators, a page is generally entirely inaccessible to sighted keyboard users. Avoid using CSS display:none; or display:0; on links, or if present, ensure that some other visual indicator of keyboard focus is present (usually done by using CSS a:focus { } styles). In addition to the default outline, you can enhance the focus indicator to make it more visually apparent and keyboard friendly by adding a background color or other visual change for focused links and other controls.

Navigation order

The order in which items are navigated via the keyboard is important. The default keyboard navigation order must be logical and intuitive. This generally means that it roughly follows the visual flow of the page - left to right, top to bottom (i.e., header first, then main navigation, then maybe page navigation, and finally the footer). This navigation order (and also the reading order for screen readers) is determined based on the source code order of the page. Structure your underlying source code so that the reading/navigation order is correct, then, if necessary, use CSS to control the visual presentation of elements on the page.

Non-navigable elements

Issues often arise when interactive elements are not keyboard navigable - primarily when something other than a link or form control (such as a <div> or <span>) is programmed with scripting to perform an action. Because only links and form controls are navigable via the keyboard by default, such items cannot be activated using a keyboard. Simply using a link or button for the control will allow keyboard accessibility. See the tabindex page for additional options.

Scripted elements and widgets

Keyboard accessibility can also be introduced with dynamic, scripted content. Complex menus, dialog menus, carousels, custom widgets, etc. must all be built to support keyboard accessibility. The ARIA specification provides mechanisms for and defines keyboard interaction guidelines for many of these types of elements. Sometimes even basic scripted functions, such as automatically focusing another element on the page can impact keyboard accessibility for better or worse.

Lengthy navigation

Keyboard navigation requires direct interaction - the user must press the tab key to navigate through interactive elements on the page. This can be particularly difficult for users with motor disabilities. Sighted mouse users can simply and more efficiently visually scan the page and directly click on any item. Because of this, long lists of links or other navigable items can pose burden and difficulty on keyboard-only users. Providing a "skip to main content" link on the page can greatly ease these issues. Using proper heading structure, ARIA landmarks, etc. can also facilitate keyboard navigation, though standard browser support for navigating via these elements is still lacking (though screen reader support is very good).