Evaluating Complex Interaction

Introduction

HTML and CSS provide limited interactivity outside of form elements. But with JavaScript, user interfaces can provide more complex interactions. Examples of complex interactions include:

  • 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

  1. 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.
  2. 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.
  3. 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, excape, 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.
    • JavaScript manages keyboard focus in intuitive ways, especially when content is added to or removed from the page. Focus must not be lost during the interaction.
  4. 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.
  5. Screen reader guidelines:

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: