Web Checklist 7: User Input Methods - erinchambers/accessibility_wiki GitHub Wiki
Users need to be able to interact with web content. This includes all form elements, links, JavaScript features, custom widgets, and all other types of content. The primary methods for interacting are mouse, keyboard, touch, and voice. Other methods are available (e.g. eye tracking or single switch devices), but they all essentially make use of, or emulate, one of the other aforementioned methods. It is important to consider all aspects of input method accessibility,including functionality, focus management in custom widgets, visual focus and hover indicators, the unavailability of JavaScript gesture actions on mobile devices when the screen reader is turned on, etc. User input method accessibility ensures that users can not only read web content, but also interact with it and submit data when necessary.
- The click target size SHOULD be large enough to facilitate easy use with a mouse (including for users with tremors or limited dexterity) without risking activating an adjacent link or button.
- An enhanced visual hover indicator SHOULD be provided.
- The mouse cursor icon on hover SHOULD correspond to the type of action allowed by the element.
- For functionality that can be operated using a single-pointer, at least one of the following MUST be true:no down-event, can abort/undo, up reversal, or essential.
- Links, buttons, and interactive controls MUST be keyboard-focusable.
- The navigation order of focusable elements (links, form elements, etc.) MUST be logical and intuitive.
- tabindex of positive values SHOULD be avoided.
- All focusable elements MUST have a visual focus indicator when in focus.
- Focusable elements SHOULD have enhanced visual focus indicator styles.
- The contrast of all small visual focus indicators (smaller than 3px by 3px) against the background SHOULD be at least 4.5 to 1.
- The contrast of all large visual focus indicators (at least 3px by 3px) against the background) SHOULD be at least 3 to 1.
- Functionality MUST be available using the keyboard,unless the functionality cannot be accomplished in any known way using a keyboard.
- Keyboard focus MUST NOT be locked or trapped in a particular page element and the user MUST be ableto navigate to and from all navigable page elements using only a keyboard.
- The focus MUST be purposely moved or set (via JavaScript) onto the appropriate element when the user's action requires a change of context or location for effective keyboard or touch interaction.
- The focus MUST NOT become lost or reset to the top of the page, except when loading or re-loading a page.
- When moving or setting focus, the destination element MUST contain discernible text (either standard text or programmatically-associated text).
- Page-specified shortcut keys and access keys MUST NOT conflict with existing keyboard shortcuts in the browser, operating system, or assistive technologies.
- When custom keyboard behavior is required to use a component, keyboard instructions MUST be provided.
- ARIA widgets that require more than just the
Tab
key to interact with may be confusing to users, so you MAY provide keyboard instructions.
- Functionality MUST be available using standard touch methods, unless the functionality cannot be accomplished in any known way using a touch device.
- Functionality MUST be available using screen reader touch methods, unless the functionality cannot be accomplished in any known way using a touch device.
- The click/touch target size SHOULD be large enough to facilitate easy use with a finger, without risking activating an adjacent link or button.
- Touch/gesture focus MUST NOT be locked or trapped in a particular page element and the user MUST be able to navigate to and from all navigable page elements using standard touch actions or gestures.
- All functionality that uses multi-point or path-based gestures for operation MUST be operable with a single pointer without a path-based gesture, unless a multi-point or path-based gesture is essential.
- Web content SHOULD NOT restrict use of input modalities available on a platform except where the restriction is essential, required to ensure the security of the content, or required to respect user settings.
- Functionality that can be operated by device or user motion MUST also be operable by user interface components and MUST allow the ability to disable motion actuation.
- Transitions MUST NOT interfere with reading or interaction, unless the interference is brief.
- Transition effects SHOULD be kept to a minimum (to avoid nausea, dizziness, annoyance, etc.).
- Transitions SHOULD avoid parallax effects.
- Content SHOULD NOT move in a way that makes interactive elements difficult to activate.