How Chromium Handles the prefers-reduced-motion Query

This article provides a technical overview of how the Chromium web browser detects operating system accessibility settings to support the prefers-reduced-motion CSS media query. It covers the specific OS-level APIs Chromium monitors across Windows, macOS, Linux, and Android, how the browser communicates these user preferences to its Blink rendering engine, and how web pages dynamically adapt to these settings to create a safer browsing experience for users with motion sensitivities.

Operating System API Detection

Chromium does not have its own persistent accessibility toggle for reduced motion. Instead, it relies entirely on the host operating system's native accessibility configurations. Chromium’s platform-specific UI code actively queries and listens for changes in the following OS APIs:

• Windows: Chromium monitors the SPI_GETCLIENTAREAANIMATION flag via the Win32 SystemParametersInfo function, as well as modern UWP UISettings.AnimationsEnabled APIs. If the user turns off "Show animations in Windows" in the OS settings, Chromium registers that reduced motion is preferred.
• macOS: The browser listens to the NSWorkspace notification center, specifically checking the accessibilityDisplayShouldReduceMotion boolean property. This corresponds to the "Reduce motion" checkbox in macOS System Settings.
• Android: Chromium checks the global system settings via Settings.Global.ANIMATOR_DURATION_SCALE. If the user disables animations or sets the animator duration scale to 0.0 in Android's Developer Options or Accessibility settings, Chromium enables the reduced motion flag.
• Linux: Because Linux uses various desktop environments, Chromium primarily relies on GTK settings. It monitors the gtk-enable-animations property. If this property is set to false, Chromium activates the prefers-reduced-motion state.

Communicating with the Blink Rendering Engine

Chromium uses a multi-process architecture, meaning the part of the browser that talks to the operating system (the Browser Process) is separate from the part that renders the webpage (the Renderer Process, powered by the Blink engine).

To bridge this gap, Chromium follows a strict communication pipeline:

1. Event Detection: When a user toggles their OS motion setting, the OS broadcasts a system-wide event. Chromium's Browser Process captures this event in real time.
2. Updating WebPreferences: The Browser Process updates an internal data structure called WebPreferences. Within this structure, a boolean state for prefers_reduced_motion is switched to true.
3. Inter-Process Communication (IPC): The Browser Process sends an IPC message containing the updated WebPreferences to all active Renderer Processes.
4. Blink Notification: Each Renderer Process receives the IPC message and updates the local settings of its Blink instance. This ensures that the user does not need to restart the browser or refresh the webpage for the accessibility setting to take effect.

Evaluating the Media Query in CSS and JavaScript

Once the Blink rendering engine receives the updated preference, it immediately re-evaluates the state of the active document.

For CSS, Blink scans the CSS Object Model (CSSOM) for any @media (prefers-reduced-motion: reduce) blocks. If the OS setting is active, Blink applies the styles within those blocks and recalculates the page layout and style rules, instantly stopping or altering CSS transitions and keyframe animations defined by the web developer.

For JavaScript, Blink triggers change events on any active MediaQueryList objects created via window.matchMedia('(prefers-reduced-motion: reduce)'). If a web application is listening to this API to control JavaScript-driven animations (such as WebGL, Canvas, or third-party animation libraries), the event listener fires immediately, allowing the script to halt motion on the fly.

Overriding OS Settings via DevTools

For testing purposes, Chromium allows developers to bypass the operating system detection pipeline entirely. Within Chrome DevTools (under the "Rendering" tab), developers can emulate the prefers-reduced-motion media feature. When enabled, DevTools intercepts the WebPreferences state and forces Blink to render the page as if the OS has requested reduced motion, without actually altering the host machine's accessibility configurations.