January 23, 2024 · reala11y team

Respecting prefers-reduced-motion on WordPress

Why default-on animation hurts users who get sick from it, and how to build motion that respects prefers-reduced-motion on your WordPress site.

For some of your visitors, a slick parallax hero or an auto-playing carousel is not delightful. It is nauseating. People with vestibular disorders, migraine triggers, or certain attention conditions can experience real dizziness, headaches, and motion sickness from animation they did not ask for. The web platform gives them a way to say “less, please” — the prefers-reduced-motion setting — and the honest thing to do is listen.

This is not an edge case you can wave away. It is a documented WCAG concern (2.2.2 Pause, Stop, Hide; 2.3.3 Animation from Interactions), and on WordPress it is one of the easier accessibility wins to get right. It is also one of the easiest to get wrong by accident, because so many themes and page builders ship animation that is on by default.

What prefers-reduced-motion actually is

prefers-reduced-motion is an operating-system preference that the browser exposes to CSS and JavaScript. When someone turns on “Reduce motion” in macOS, Windows, iOS, or Android, their browser starts reporting it. Your site can read it and respond.

There are two values that matter:

• no-preference — the user has not asked to reduce motion.
• reduce — the user has explicitly asked for less motion.

The trap most sites fall into is treating animation as the default and reduction as the exception. They animate everything, then bolt on a @media (prefers-reduced-motion: reduce) block to switch some of it off. That block almost always misses something.

Flip the default

A more reliable mental model: base styles have no animation, and you add motion only when the user has not opted out. Animation becomes the enhancement, not the baseline.

/* Base: still, stable, no motion. */
.reveal {
  opacity: 1;
  transform: none;
  transition: none;
}

/* Motion only for users who have not asked to reduce it. */
@media (prefers-reduced-motion: no-preference) {
  .reveal {
    opacity: 0;
    transform: translateY(8px);
    transition: opacity 600ms ease, transform 600ms ease;
  }
  .reveal.in-view {
    opacity: 1;
    transform: none;
  }
}

The payoff: anyone who has reduced motion at the OS level simply never enters the animated branch. There is no “off switch” to forget, because off is where you started. New components inherit the safe default for free.

The WordPress-specific reality

Here is the catch on WordPress: you rarely control all of your own markup. A typical site stacks a theme, a page builder, a slider plugin, and a handful of effect libraries — and several of those ship animation that ignores the user’s preference entirely.

A practical audit pass:

• Theme and builder settings. Check for global “scroll animations,” “entrance effects,” or “parallax” toggles. Many can be switched off site-wide in one place.
• Sliders and carousels. Auto-advancing carousels are the worst offenders. If you must keep one, it should pause on hover and on focus, and stop auto-advancing under reduce.
• Animation libraries. AOS, WOW.js, and similar tools bolt motion onto elements via attributes. Confirm whether the version you ship honors prefers-reduced-motion — older setups often do not.
• Background video. A full-bleed autoplay video is motion too. Offer a still poster frame for reduced-motion users.

For motion you genuinely cannot disable at the source, a defensive CSS rule helps as a backstop:

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

Treat that as a seatbelt, not a strategy. The right fix is to stop emitting unwanted motion in the first place; the blanket rule just catches what slips through third-party code you do not own.

A few hard lines worth holding

• No auto-playing animation that loops forever without a way to stop it. Indefinite marquees and looping background effects need a pause control.
• Nothing flashing more than three times per second. That is a seizure risk, full stop.
• Never convey information through motion alone. If a number counts up, the final value must be in the DOM from the start so a screen reader reads it correctly.
• Focus indicators appear instantly. A focus ring that fades in slowly is a focus ring that is briefly invisible.

If you want the underlying success criteria spelled out, our WCAG 2.2 guide walks through the motion-related ones. WCAG 2.2 has been a W3C Recommendation since 5 October 2023, and the motion criteria carried over from earlier versions — this is settled guidance, not a moving target.

Where automated tooling fits — and where it doesn’t

Motion preferences are one corner of accessibility where tooling helps but cannot finish the job. A scanner can flag a viewport meta tag that blocks zoom, or surface a <video> with autoplay, and reala11y fixes issues like these at the code level rather than papering over them with an overlay widget. But no automated check can feel whether your hero animation makes someone queasy. That judgment is human.

This is the honest framing we hold ourselves to: automated tools, ours included, detect roughly 30–40% of WCAG issues by criteria. The rest needs a person. Respecting prefers-reduced-motion lands squarely in the part you have to decide on purpose.

The honest takeaway

Reduced-motion support is not a niche toggle for a handful of users — it is a small, durable courtesy that costs you almost nothing and spares some visitors real discomfort. Start from stillness, add motion only for people who have not opted out, and audit the plugins quietly animating behind your back. Do that, and you are moving toward WCAG 2.2 AA conformance on this front the right way: deliberately, and without pretending a switch made your whole site accessible.