2.2.2 Pause, Stop, Hide
- Level A
- Operable
- Since WCAG 2.0
Summary
Content that moves on its own is a barrier for people with attention and cognitive disabilities, who can find it impossible to read anything else on the page while something nearby is in motion. It also disrupts people with vestibular disorders, screen magnification users whose enlarged viewport is hijacked by moving content, and screen reader users whose reading position is destroyed when auto-updating content replaces itself mid-read. This criterion gives all of them an escape hatch: a mechanism to pause, stop, or hide the movement.
The auditor's mental model has two branches. For moving, blinking, or scrolling content, three conditions must ALL hold before a mechanism is required: it starts automatically, it lasts more than five seconds, and it is presented in parallel with other content. If any one condition is missing, there is no failure. For auto-updating content (feeds, prices, scores), the five second test drops away: auto-start plus parallel content is enough, though the author may satisfy it with frequency control instead of pause. In both branches, "essential" movement (where stopping it would break the activity) is exempt. The single most common fail on marketing sites is the auto-advancing carousel with no pause control.
Official wording
For moving, blinking, scrolling, or auto-updating information, all of the following are true:
Moving, blinking, scrolling:
For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and
Auto-updating:
For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
EN 301 549 mapping
- Web pages
- Clause 9.2.2.2
- Software and native apps
- Clause 11.2.2.2 (via Table 11.5)
Clause 9.2.2.2 applies this criterion to web pages unchanged. For software, clause 11.2.2.2 carries the requirement through a word-substitution table (Table 11.5) that restates it for application user interfaces.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Start with the carousel. Load the page, take your hands off the keyboard and mouse, and watch: does the hero carousel advance on its own? Does it keep going past five seconds (a looping carousel always does)? Is there other content on the page (there always is)? If all three hold, look for a pause, stop, or hide mechanism. Next and previous arrows are not a pause mechanism: they change the slide but the auto-advance timer keeps running. Pause on hover alone is not sufficient either, because it is not available to keyboard or touch users and the motion resumes the moment the pointer moves away. The control must be operable, which means tab to it with the keyboard and confirm it actually stops the rotation, and confirm you can reach it before or very near the moving content rather than after fifty other tab stops.
Then sweep for the rest of the family: background hero videos (a pause control is required if the video runs longer than five seconds), animated banners and looping GIF adverts beside article text, scrolling news tickers, and CSS animations that run indefinitely. For auto-updating content (live chat panes, refreshing dashboards, price or score widgets), check for a pause control or a way to set the update frequency; remember the five second grace does not apply on this branch.
Check prefers-reduced-motion honestly. In browser devtools you can emulate the reduced motion media feature and see whether the site tones down its animation. Respecting it is genuinely good practice and worth recording as such, but grade it carefully: the criterion asks for a mechanism the user can find in the content, and many of the people this criterion protects have never heard of the operating system setting, so AUDITSU does not treat reduced-motion support alone as a substitute for a visible pause control on content that meets all three conditions.
iOS
The requirement applies to native apps: the European standard carries this criterion through to software by restating it for application user interfaces, so grade app screens against the same two branches. The most common iOS suspects are auto-playing videos in feeds and product listings, animated promotional banners on home and store screens, and live-updating scores, prices, or activity tickers presented beside other content.
Test with a stopwatch mentality. Open each screen, leave it alone, and watch what moves without input and for how long. A feed video that auto-plays needs a pause affordance (a tap-to-pause on the player counts, provided VoiceOver users can also reach and activate it; verify with VoiceOver running that the pause action is exposed rather than being a bare gesture). With VoiceOver active, also listen for the disruption itself: auto-updating regions that re-announce or shift focus while you are reading elsewhere are exactly the harm this criterion targets and strong evidence in your report.
Check whether the app honours the platform Reduce Motion setting (Settings, Accessibility, Motion). As on the web, treat it as a good-practice signal, not a substitute: record apps that respect it favourably, but a carousel that auto-advances indefinitely with no in-app pause still fails.
Android
The same two branches apply to Android apps through the European standard's software restatement. Look at auto-playing feed and listing videos, marquee-style scrolling text (Android's marquee ellipsize behaviour scrolls text automatically and is a classic offender when applied to headlines beside other content), animated promotional cards, and live-updating price, score, or notification widgets.
Procedure mirrors iOS: open each screen, wait, and log anything that moves automatically for more than five seconds alongside other content, or updates itself automatically at all. Then hunt for the mechanism and verify it with TalkBack running: the pause or hide control must be reachable and activable by assistive technology, not only by a sighted tap on the video surface. Layout Inspector can help confirm whether a moving element is a video view, an animated drawable, or a marquee text view when you need to describe the finding precisely.
Android's "Remove animations" accessibility setting (and the animator duration scales in developer options) mainly affect system transitions, not app content like video autoplay or data refresh, so do not rely on them when grading. An app that additionally respects the platform animation preferences earns a good-practice note; it does not earn a pass for unstoppable moving content.
Pass and fail examples
Passes:
- An auto-advancing carousel with a visible pause button that is keyboard focusable, properly named, and genuinely halts the rotation until the user restarts it.
- A hero animation that plays once on load and settles within five seconds: the "lasts more than five seconds" condition never triggers.
- A looping background video with a persistent pause control overlaid on it, reachable by keyboard and by screen reader.
- A live-updating dashboard with a refresh interval setting (every 30 seconds, every 5 minutes, manual only): frequency control satisfies the auto-updating branch.
- A full-screen animated onboarding sequence with nothing else on screen: it is not presented in parallel with other content.
Fails:
- An auto-advancing homepage carousel with next and previous arrows and slide dots but no pause, stop, or hide control: navigation controls do not stop the timer.
- A carousel that pauses on mouse hover only: the mechanism is unavailable to keyboard and touch users, so it is not a mechanism for them.
- A carousel with a pause button rendered as an unfocusable div, or placed after the entire page in the tab order: present visually, unreachable in practice.
- A scrolling news ticker or marquee headline that runs indefinitely beside the main content with no way to stop it.
- A looping animated GIF advert in an article sidebar with no hide control: GIFs have no native pause, so the author must provide the mechanism.
- A chat or activity feed that auto-inserts new items and scrolls the pane while the user is reading, with no pause and no frequency control.
Not a fail under this criterion:
- A loading spinner or progress bar: it is the classic non-fail, because the movement is essential progress indication and typically nothing else is presented in parallel while it shows.
- An animation the user starts themselves (tapping play on a video): condition one, auto-start, is not met. If it then cannot be paused, consider usability notes, not a 2.2.2 fail.
- Motion that lasts four seconds and stops: under the five second threshold.
- An auto-playing video whose problem is the sound: audio that plays automatically for more than three seconds belongs under SC 1.4.2 Audio Control. One autoplaying video can fail both criteria, but file the sound and the motion separately.
- Content flashing more than three times per second: that is a seizure risk graded under SC 2.3.1 Three Flashes or Below Threshold, and a pause button does not excuse it.
- A session that expires or content that disappears after a time limit: that is SC 2.2.1 Timing Adjustable, not moving content.
Commonly confused with
- SC 1.4.2 Audio Control. Sound versus motion. An autoplaying hero video with audio can fail 1.4.2 (audio plays automatically for more than three seconds with no way to pause, stop, or control its volume) and 2.2.2 (no way to pause the motion) at the same time; grade the two channels separately with separate evidence.
- SC 2.3.1 Three Flashes or Below Threshold. Frequency is the dividing line. Blinking content that distracts is 2.2.2 and is fixed by a pause mechanism; content flashing more than three times per second is a photosensitive seizure risk under 2.3.1 and no mechanism makes it acceptable.
- SC 2.2.1 Timing Adjustable. Both live under the "Enough Time" guideline. 2.2.1 covers time limits on what the user must do (sessions, timeouts, content that vanishes); 2.2.2 covers content that moves or updates while the user tries to do it. An auto-advancing carousel is 2.2.2; a checkout that expires in five minutes is 2.2.1.
- SC 2.3.3 Animation from Interactions. The Level AAA sibling covers motion triggered by the user's own actions (parallax on scroll, zoom transitions) and is where
prefers-reduced-motionsupport is the primary technique. Auto-starting motion stays here at Level A; do not downgrade a carousel finding to a AAA advisory because the site supports reduced motion.
How AUDITSU tests this
AUDITSU's audit walkthrough puts a moving-content check on every screen you review. The walkthrough prompts you to leave the screen untouched and record anything that moves, blinks, scrolls, or updates by itself, then walks the three-condition test for the motion branch (auto-start, longer than five seconds, parallel content) and the two-condition test for the auto-updating branch before asking for the mechanism. Where a pause control exists, the walkthrough has you verify it with the keyboard on web and with the screen reader running on iOS and Android, because an unreachable pause button is graded the same as no pause button. Each screen records a pass, fail, or not applicable result with evidence attached, so a carousel finding lands in your report tied to the exact screen, component, and missing mechanism.
For the full guided workflow, see the audit platform.