User Settings Supported

CharlesBelov's original ask (#183) was that where the OS exposes the request and the user agent passes it to content, not animating should satisfy AA — the user telling their OS that animation is problematic removes the need for anyone to decide whether a given animation is problematic. guyhickling points out that Android's "Remove animations", iOS's "Reduce motion" and Windows 10's "Show animations" are all binary switches that set the same flag, and that honouring it costs an author a media query rather than banning animation, with an opt-in button available where the animation is genuinely informational. mgifford and guyhickling both argue AAA is where requirements go to be ignored, because AA is the norm most IT teams work to. CharlesBelov later adds that the need goes beyond VIMS to hyper-vigilance and attention impairments, where even small, sub-second animation costs focus, and asks to be believed that an OS-level request is sufficient without waiting for a study.

prefers-reduced-motion is one bit, but users are affected by specific magnitudes and kinds of motion, so reading it as "no animation at all" would technically fail a page containing a single dot that fades by one opacity value. He cites Windows users who set the preference accidentally without realising what it does. His counter-proposal, building on mgifford's #182 suggestion that respecting user choices such as dark mode be at least AAA, is a generic "respect user settings" requirement at AAA covering dark mode, reduced motion and high contrast, phrased in Understanding rather than hard-coded to whichever media queries exist today, with honouring a preference offered as a sufficient technique rather than the normative bar — and even then subject to whether it is accessibility supported.

Specifying size across devices and zoom levels, and duration when the motion is triggered by user action such as scrolling, is exactly where this stalled during WCAG 2.1. Small animations such as icons changing on hover did not appear to be vestibular triggers, so a minimum size looks necessary before the requirement can sit at A or AA. The preference is not a 1:1 fit for the user need, so relying on it produces false positives and extra work; in a consensus process that means persuading the people who objected last time. Answering CharlesBelov's invocation of the W3C Code of Conduct, he redirects to the priority-levels wiki as the document that actually governs level decisions.

JAWS-test's cross-browser test of prefers-color-scheme (#182) found Edge reporting light even in Dark Mode and dark only under high contrast white-on-black, Firefox reporting light even in HCM, Chrome mapping some HCM modes to dark and others to no-preference, Android Chrome always reporting light even in Dark Mode, and only iOS Safari behaving as expected. mraccess77 reports the Windows setting blocks animations they want along with those they do not, and asks for finer control. MarjaE2 (#40) found user CSS forcing animation-timing-function and transition-timing-function to step-start is overridden by ::before and ::after pseudo-elements carrying their own timing functions, and argues disabled users should not have to become programmers to browse without being hurt. Myndex challenges the CSS Color Adjust rule that maps Canvas lightness (L below 33% or above 67%) onto prefers-color-scheme, on the grounds that CIELAB L is not perceptually uniform on self-illuminated displays and the real flip point is higher.

COGA (#737, filed by julierawe) wants haptics added to the note that currently lists font size, icon size, color scheme, magnification and motion, or the list reworded as "include but are not limited to", and asks whether the separate Haptic stimulation adjustable provision in the Animation section is still needed once haptics is covered here. JAWS-test asked the foundational question in 2020 — what does respecting a preference actually oblige an author to do, should pages invert, and what about a page already rendered light-on-dark. mgifford adds two cases nobody answered: dark mode can switch with the time of day so the preference changes mid-session without the user doing anything, and an on-page theme widget should take precedence over the browser preference.