Keyboard Accessibility： 网页键盘按钮响应

原文地址：http://webaim.org/techniques/keyboard/

Introduction

Important

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

Keyboard accessibility is one of the most important aspects of web accessibility. Many users with motor disabilities rely on a keyboard. Blind users also typically use a keyboard for navigation. Some people have tremors which don't allow for fine muscle control. Others have little or no use of their hands. Some people simply do not have hands, whether due to a birth defect, an accident, or amputation. In addition to traditional keyboards, some users may use modified keyboards or other hardware that mimics the functionality of a keyboard.

Potential Problems

There are many ways that a webpage can introduce difficulties for users who rely on a keyboard for navigation. Below are a few of the most common issues.

Focus indicators

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 avisual indicator of the element that currently has keyboard focus. A basic focus indicator is provided automatically by the web browser and is typically shown as a border (called an outline) around the focused element. However, these outlines can be hidden by applying outline:0 oroutline:none CSS to focusable elements.

Important

Avoid outline:0 or similar styles on links and other elements that can receive keyboard focus.

In addition to the default outline, you can use CSS to make the focus indicator more visually apparent and keyboard-friendly by adding a background color or other visual style to links, and other controls that will receive keyboard focus. The outline can be styled to match your site design.

Navigation order

As a keyboard user navigates through the page, the order in which interactive items receive keyboard focus is important. The default keyboard navigation order must be logical and intuitive. This generally means that it follows 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. This navigation order (and also the reading order for screen readers) is determined by the web page's source code. For best results:

• Structure your underlying source code so that the reading/navigation order is correct.
• Then, if necessary, use CSS to control the visual presentation of the elements on your page.
• Do not use tabindex values of 1 or greater to change the default keyboard navigation order.

Items that cannot receive keyboard focus

By default, users can only navigate to links, buttons, and form controls with a keyboard. These natively-accessible elements should be used whenever possible. If this is not possible, you may need to use tabindex="0" to ensure an element can receive keyboard focus.

Note

Note: An <a> element is only keyboard accessible when it has a non-empty href attribute. <a> and <a href=""> should not be used for links.

Inaccessible custom widgets

Although elements that are natively keyboard accessible should be used when possible, there are times when HTML falls short and custom "widgets" are necessary. Complex menus, sliders, dialogs, tab panels, etc. must all be built to support keyboard accessibility. This means the following must occur:

• The interaction is presented in an intuitive and predictable way
• JavaScript event handlers work with a keyboard and a mouse.
• The interaction uses standardized keystrokes.

The ARIA design patterns describe standard keyboard interactions for many common widgets.

Lengthy navigation

Sighted mouse users are able to visually scan a web page and directly click on any item. Keyboard users must press the Tab key or other navigation keys to navigate through the interactive elements that precede the item the user wants to activate. Tabbing through lengthy navigation may be particularly demanding for users with motor disabilities.

Long lists of links or other navigable items may pose a burden for keyboard-only users. The following best practices can facilitate efficient keyboard navigation:

• Provide a "skip to main content" link on the page.
• Use a proper heading structure.
• Provide ARIA landmarks or HTML5 structural elements (<main>, <nav>, etc.)

Keyboard Testing

Testing with a keyboard is an essential part of any accessibility evaluation. The basics of keyboard testing are simple—the Tab key can be used to navigate through links and form controls, Enter(and sometimes Spacebar) selects an element, and the arrow keys are sometimes used for other navigation. However, when testing with a keyboard, you are not just trying to interact with the page successfully, you also want to ensure all interactions are predictable. This requires an understanding of common keyboard interactions.

The following table includes many of the most common online interactions, the standard keystrokes for the interaction, and additional information on things to consider during testing.

Interaction	Keystrokes	Notes
Navigate to most elements	Tab Shift + Tab - navigate backward	Keyboard focus indicators must be present. Navigation order should be logical and intuitive.
Link	Enter
Button	Enter or Spacebar	Ensure elements with ARIA role="button" can be activated with both key commands.
Checkbox	Spacebar - check/uncheck a checkbox	Checkboxes should be used when one or more option can be selected.
Radio buttons	↑/↓ or ←/→ - select an option. Tab - move to the next element.	Radio buttons should be used when only one option from a group can be selected.
Select (dropdown) menu	↑/↓ - navigate between menu options Spacebar - expand	You can also filter by typing letters, but this behavior varies by browser. Some will filter as you type, like autocomplete. Others will only sort by first letter. E.g., in a list of US States, hitting A then R may take you to Arizona, or it may take you to Alabama and then Rhode Island.
Autocomplete	Type to begin filtering ↑/↓ - navigate to an option Enter - select an option
Dialog	Esc - close	Modal dialogs should maintain keyboard focus. Non-modal dialogs should close automatically when they lose focus. When a dialog closes, focus should usually return to the element that opened the dialog.
Slider	↑/↓ or ←/→ - increase or decrease slider value Home/End - beginning or end	For double-sliders (to set a range), Tab/Shift + Tabshould toggle between each end. In some sliders PageUp/PageDown can move by a larger increment (e.g., by 10).
Menu bar	↑/↓ - Previous/next menu option Enter - expand the menu (optional) and select an option. ←/→ - expand/collapse submenu	Not all menus should have these controls. Simpler menus should usually rely on Tab/Enter.
Tab panel	Tab - once to navigate into the group of tabs and once to navigate out of the group of tabs ↑/↓ or ←/→ - previous/next tab.	This is for 'application' tabs that change without loading a new page. If a menu looks like a group of tabs, but is actually a group of links to different pages, Tab and Enter are more appropriate. The tab content should update automatically when pressing the arrow keys. You should not hit Enter to activate the tab.
'Tree' menu	↑/↓ - Navigate Previous/next menu option ←/→ - expand/collapse submenu, move up/down one level.
Scroll	↑/↓ - scroll vertically ←/→ - scroll horizontally Spacebar/Shift + Spacebar - scroll by page	Minimize horizontal scrolling.

Note

The ARIA authoring practices document provides additional information for these and other common interactions.