Pause, Stop, Hide
Moving, blinking, scrolling, or auto-updating content that lasts more than 5 seconds and is presented in parallel with other content must be pausable, stoppable, or hideable by the user.
What it requires
WCAG 2.0 SC 2.2.2 covers carousels that auto-advance, hero animations that loop indefinitely, "as seen on" logo strips that scroll forever, and live ticker feeds. The user must have a documented control to pause, stop, or hide the motion.
The criterion does not ban motion — it requires user control. A 5-second hero animation that plays once is fine. A hero carousel that auto-advances every 7 seconds for the duration of the visit is not, unless a pause button is provided.
Common Shopify failure
Hero slideshow that auto-advances every 5 seconds with no pause control. Brand-logo "as seen on" infinite scroll strip with no pause. Animated promotional banners with no dismiss.
How to fix it
Provide an operable pause, stop, or hide control for applicable moving content, and consider `prefers-reduced-motion` as an additional accommodation. Test that the control governs the real animation state.
Merchant QA checklist
- Scan the storefront page where this pattern appears: product pages, collection pages, cart drawer, customer-account pages, and any landing page built with theme sections.
- Confirm the issue is fixed in the rendered browser output, not only in the Liquid file. Shopify section settings, app blocks, and third-party scripts can reintroduce the same 2.2.2 failure after a theme edit.
- Re-test the affected component with keyboard navigation and a screen-reader accessibility tree before publishing the theme, especially when the fix changes markup or ARIA attributes.
How AccessComply handles it
AccessComply uses automated rules to check supported patterns in the pages reached during a scan. Some WCAG requirements need human judgment, assistive-technology testing, or access to third-party content and cannot be established by an automated scan. This criterion is generally treated as a pattern that may have a supported suggested fix. If the app can safely match the issue to supported source code, the merchant must review and approve the suggested change before anything is written, and the result is checked afterward. Otherwise the merchant should use the guidance above and independent hands-on testing. The label is not a guarantee of detection, a fix, WCAG conformance, or legal compliance.
Primary source: W3C — WCAG 2.0 Understanding 2.2.2