Evaluating Complex Interaction
- expandable sections of content
- custom input elements
- hover or animations
- overlays or dialogs
- single page apps
- using AJAX for dynamic updates
Complex interactions present particular accessibility challenges to mobile, keyboard, and screen reader users, and validating complex interaction accessibility can be time consuming. Projects should budget enough research, design, and QA time for complex interaction. To mitigate risk, consider avoiding complex interactions for important functionality.
Below is a checklist for validating complex interactivity.
General Complex Interaction Guidelines
- Updating, animating, or moving content:
- Avoid having content move or update automatically. If content must update or move automatically, provide a way to pause, stop, or hide the motion or updates.
- Do not change the user agent, viewport, focus, or page content when an element receives focus or when changing the value or setting of any element.
- When content is updated or a status message is otherwise presented to the user, it is presented using an ARIA live region.
- Content must not flash or flicker more than three times per second.
- Touch guidelines:
- Drag, swipe, multi-finger gestures, or other gestures are not required to complete interactions. When the ability to use such gestures are present, non-gesture alternatives are also present.
- Targets should be at least 44px wide and 22px tall.
- Keyboard guidelines:
- All functionality is operable through a keyboard alone, without requiring specific timings for the individual keystrokes, on all devices, including mobile devices.
- Keyboard focus can move to and away from elements using a keyboard only, using conventional keyboard techniques (tab, arrow keys, escape, etc). The keyboard focus is never trapped on an interface.
- Access keys are not necessary and are generally avoided. When implemented, access keys do not conflict with conventional operating system or browser keyboard shortcuts.
- If non-conventional, keyboard-specific interactions are implemented, instructions are available.
- The tab order for all focusable elements is intuitive and sensible.
- Avoid setting tabindex to be greater than 0.
- Keyboard focus is always on a visible element, and keyboard focus styles are designed to be more salient than browser defaults.
- Content triggered by hover or keyboard focus:
- Content triggered by a hover should also be triggerable by a keyboard.
- The triggered content can be dismissed without moving the mouse or keyboard focus.
- The triggered content can be hovered over without disappearing.
- The triggered content remains visible until the hover or focus are moved, the content is dismissed, or the information is no longer valid.
- Screen reader guidelines:
- If the interaction has a corresponding WAI-ARIA Authoring Practices design pattern, the implementation adheres to the design pattern.
Interaction- and Widget-Specific Guidelines
When native HTML elements are available, developers should prefer those elements instead of creating custom widgets.
Developers unsure how to implement particular ARIA roles should seek consultation. The W3C recommends not implementing ARIA roles, states, and properties at all rather than implementing them correctly.
The W3C provides model implementations and design patterns for many widgets and interactions:
- Fly-out menus
- The ARIA Authoring Practices document provides dozens of model implementations and instructions for various interactions.