Cooking Portal Review: Read prefers-reduced-motion

When a cooking-service portal mentions prefers-reduced-motion, the phrase can sound like a warranty: the site promises that nothing will move. The inspected 19 February 2026 W3C Media Queries Level 5 Working Draft describes the feature more narrowly. It is work in progress, rather than a newly issued Recommendation. It detects whether the user has asked the system to minimize non-essential motion, not whether the page has obeyed. The signal arrives at the page as a condition; what the page does with it is a separate design decision. A reviewer who treats the media query as proof of a motion-free experience has skipped the step that actually matters.

The distinction is not academic. A portal may use the query to soften a decorative transition while leaving a carousel auto-advancing, a modal sliding in, or a status indicator pulsing. Each of those behaviors is an implementation choice. The query is a door that opens onto a room the developer still has to furnish. Reading the specification as a guarantee confuses the availability of a signal with the completeness of a response.

What the Media Query Actually Reports

The specification defines prefers-reduced-motion as a feature that detects a user request for the system to minimize non-essential motion. The wording matters. "Non-essential" is a judgment the page must make about its own content, and "minimize" is not the same verb as "eliminate." A fictional page might replace a slide with an instant change. Whether a particular implementation satisfies a stated requirement needs separate examination; an author’s essentiality label alone does not settle that question. The query reports a preference; it does not audit the result.

This is why a portal's source code can contain the query and still fail a motion review. The query may be present in a stylesheet that is never loaded on a particular route, or it may be scoped to a component that is not the one the reviewer is watching. Presence in a repository is not presence in a delivered page. A delivered-interface observation is needed for a claim about what the reviewer actually encountered under the stated condition. Source inspection and observation can answer complementary questions.

Optional Interface Motion on a Cooking Portal

In a hypothetical cooking-service portal, possible review targets include several places where motion may be optional. A menu card that lifts on hover, a progress bar that sweeps while an order is submitted, a banner that rotates through promotions, a confirmation checkmark that draws itself. Whether any of these effects is essential depends on the particular information and functionality. Do not decide that from the component’s name alone. The review should ask what each effect contributes and what alternatives the delivered page offers.

The informative W3C explanation of WCAG 2.2 Success Criterion 2.3.3, a Level AAA criterion, frames interaction-triggered motion in terms of essentiality. It distinguishes such motion from automatically initiated animation; one criterion should not be treated as a complete motion audit. Motion triggered by interaction can be disabled unless it is essential to the functionality or the information being conveyed. For the fictional checkmark or status display, ask whether the information and functionality can be achieved another way. Neither a checkmark shape nor a status label alone establishes essentiality. The reviewer's job is to ask what the motion carries, not merely whether it exists.

Motion that is triggered by scrolling deserves its own attention. The guidance notes that moving new content into the viewport is essential to scrolling, but parallax effects, where backgrounds move at a different rate from foregrounds, are often non-essential. A portal that layers a slow-moving illustration behind its order history is adding motion the user did not request and cannot control through the scroll itself.

A Hypothetical Review of One Portal Route

Imagine a reviewer opening a cooking-service portal on a test device with the operating system's reduce-motion setting enabled. The reviewer navigates to the order-status page, where a stylized pan icon rotates beside the word "preparing." The reviewer notes that the rotation continues. The reviewer then opens the browser's developer tools and confirms that a prefers-reduced-motion block exists in the loaded stylesheet, but it targets only a modal transition on the checkout route. The rotating pan is not covered.

This is the kind of finding that separates a signal from a guarantee. The portal has the query; it does not have a complete response. The hypothetical record stays with the observed rotation and the stated stylesheet scope. No full accessibility conclusion follows from this single observation, and the source’s interaction-triggered scope must also be considered before applying that criterion to the example. The record states what was seen, on which route, under which condition, and what the stylesheet did and did not cover. That is the honest shape of a review.

Separating a Preference Signal from a Motion Guarantee

The cleanest way to write about this in a procurement or acceptance document is to keep two columns apart. One column lists what the system reports: the media query is supported, the operating-system setting is detected, the stylesheet contains a response block. The other column lists what was observed: which elements moved, which did not, under which condition, on which route. A reviewer who merges the columns produces a claim the evidence cannot carry.

This separation also protects the portal team. A developer who has written a careful prefers-reduced-motion block for the checkout modal deserves credit for that work, even if another route still has motion. The review should name the scope of the response, not grade the whole site on the presence of one block. Specificity is what makes the finding useful.

What to Ask Before Accepting a Motion Claim

Before accepting a statement that a portal "supports reduced motion," ask which routes were tested, which elements were observed, and whether the test used the operating-system setting, a browser emulation, or both. Ask whether the response is implemented in CSS, in JavaScript, or in both, and whether any animation is driven by a third-party widget outside the portal's stylesheet. Ask what the portal classifies as essential motion and on what basis.

These questions do not require the reviewer to inspect every line of code. They require the portal team to describe the boundary of their claim. A team that says "we respect prefers-reduced-motion on the checkout and account pages, and we have not yet reviewed the marketing banners" has given a reviewable answer. A team that says "the site supports reduced motion" has given a slogan. The difference is the difference between evidence and assurance.

For teams planning a review, the category pages for technical information category and related resources category offer related ways to frame what a delivered page does and does not demonstrate. The goal is the same: a record that matches what a user can actually see.