Complete the reward state when non-essential motion is reduced

Removing a celebration animation should not remove the event that unlocks the next action. This fixture checks that motion preference changes presentation without trapping the player in an unfinished state.

This edition is a laboratory fixture. Node and the companion HTML page execute the authored functions against synthetic cases. No physical device panel was run, no ad network reviewed the build, and no campaign result is inferred from a passing test.

What the documentation actually supplies

MDN: reduced motion is the governing reference for the browser primitive. MDN describes prefers-reduced-motion as a media feature reflecting a user's preference to reduce or replace non-essential motion. It does not require hiding the information or outcome an animation communicates. The fixture policy around that primitive is ours.

The failure the fixture isolates

The model separates the semantic reward completion from whether a celebratory animation runs. The broken branch waits forever for an animation that was skipped. The corrected branch completes the reward immediately in reduced-motion mode and uses the normal animation path otherwise.

The broken branch is retained so a producer can see the exact mistake, not only the repaired output.

All 3 fixed-branch cases matched the spec when executed in Node on 19 September 2026.

What a pass does not prove

A pass proves the supplied state transition completes in both modes. It does not constitute an accessibility audit or show that the actual visual treatment is comfortable. The alternative presentation still needs to communicate the reward clearly and leave keyboard, pointer and screen-reader access coherent.

Untested cells in this edition: physical devices, host SDKs, network packaging limits, store-opening callbacks, and campaign performance. Those remain empty on purpose.

Next check on a real build

Identify actions currently triggered only by animation-end callbacks. Move the essential state change into a path that can complete with or without motion. Test a real preference change before launch and during a transition, then confirm that the next control remains available and no duplicate completion fires.

Open the runnable fixture to re-execute the cases in a browser. Download the case record to keep inputs, expectations and limits with a QA ticket.

Background in the archive: Playable ad device testing matrix and Playable spec sheet before you build. Those guides describe practice; they are not a substitute for this fixture and this check does not recertify their every claim.