WCAG 2.2.2 Pause, Stop, Hide: Making Moving and Auto-Updating Content Accessible

What WCAG 2.2.2 Pause, Stop, Hide means

WCAG 2.2.2 requires that moving, blinking, scrolling or auto-updating content has a user control to pause, stop or hide that content unless the movement is essential to the activity. The rule aims to prevent motion or surprise updates from interfering with reading, focus, concentration or assistive technology use.

When this success criterion applies

• Content that moves automatically, including carousels, slideshows and marquees.
• Animated icons or backgrounds that loop continuously.
• Auto-updating feeds or areas that change without user request, like live score tickers.
• Blinking or scrolling text started automatically.

Common exceptions and essential movement

Movement that is essential to a task may not require a pause control. Examples of essential movement include live video streams for a conference or a real-time collaboration cursor that is required for the activity. When movement is essential, document why it is essential and reduce its impact where possible.

Practical controls to meet WCAG 2.2.2

Controls must be simple, visible and keyboard accessible. Use clear labels and expose state to assistive technology.

• Visible toggle labelled Pause / Play or Stop.
• Hide button to collapse nonessential moving regions.
• Preference that remembers the user choice when sensible, for example via a cookie or local storage.

Minimum control requirements

• Focusable by keyboard using a native focusable element or tabindex=“0”.
• Operable with Enter and Space keys.
• Clear accessible name and state exposed via ARIA where necessary, for example aria-pressed or aria-label.
• Visible contrast and placement so users can find the control.

How this interacts with prefers-reduced-motion

The CSS media query prefers-reduced-motion is a user preference. Honor it by reducing or disabling non-essential animations. That does not replace a pause/stop/hide control, but it reduces the number of users who need to use the control.

Specific patterns and recommendations

Carousels and slideshows

• Provide a visible Pause button that stops automatic advance.
• Ensure keyboard users can pause, move slides and resume without losing focus.
• Announce changes to screen readers only when the user requests them. Avoid surprise updates via ARIA live unless the update is critical.

Auto-updating feeds and live regions

• Let users turn off automatic updates or hide the feed.
• Use polite ARIA live for non-critical updates so they do not steal focus or interrupt typing.
• For critical updates, provide a clear mechanism to acknowledge or read them on demand.

Looping animations and decorative motion

• Mark purely decorative motion so it can be suppressed for users who prefer reduced motion.
• Provide a Hide or Stop option when motion is not decorative.

Step-by-step: add a pause control to a carousel

1. Identify whether the carousel advances automatically. If it does, add a visible control labelled Pause.
2. Make the control a native button. Provide aria-pressed=“false” initially and aria-controls pointing to the carousel region.
3. On activation, stop the timer that advances slides and update aria-pressed to true and the visual label to Play.
4. Ensure keyboard users can reach the control before the carousel content. Do not trap focus inside the carousel.
5. Test with screen readers and a keyboard only. Confirm that pausing prevents auto-advance and that focus is preserved.

Step-by-step: make auto-updating text accessible

1. If updates are non-critical, avoid using assertive live. Use a polite live region or let users request updates.
2. Provide a Toggle Updates control that pauses DOM changes or hides the region.
3. When users pause updates, stop network polling and stop DOM replacement to avoid focus loss.
4. Offer a Read updates button that moves focus into a stable region showing the latest content.

Testing checklist for WCAG 2.2.2

• Can users pause, stop or hide all automatically moving content started on page load?
• Are controls reachable and operable using Tab, Enter and Space?
• Do controls have clear visible labels and sufficient contrast?
• Does pausing stop timers, CSS animation-play-state and DOM updates as appropriate?
• Does the site respect prefers-reduced-motion where possible?
• Do ARIA live regions announce only what is necessary and at the right assertiveness level?
• Have you tested with a screen reader, keyboard-only, and users who experience vestibular issues?

Common mistakes to avoid

• Providing a pause control but not making it keyboard accessible.
• Updating the DOM on every auto-update so keyboard users lose focus.
• Using assertive live for routine updates and interrupting the user.
• Relying solely on prefers-reduced-motion without offering controls.

Decision framework: should you add a control?

• If movement is essential to the content or task, document why and reduce its intrusiveness.
• If movement is not essential, add a pause, stop or hide control and respect user preferences.
• If movement is decorative, mark it as such and honour prefers-reduced-motion.

Final checks before release

• Run keyboard-only walkthroughs across affected pages.
• Test with at least one screen reader and a browser that supports prefers-reduced-motion.
• Confirm that pausing stops visual motion and stops automatic DOM changes.
• Document any essential movement and the accessibility rationale in your project notes.

Further reading

Refer to the official WCAG documentation for the exact success criterion wording and normative examples. Also review guidance on ARIA live regions and the prefers-reduced-motion media query for complementary techniques.