Documenting Motion in Accessibility Conformance Reports

Part of WCAG Animation Conformance in Accessible Motion Architecture.

The problem

A procurement team asks for an accessibility conformance report. The engineering team has done real work on motion — reduced-motion support, pause controls, no flashing — but the draft report says only “Supports” next to every criterion, with no evidence. A reviewer asks how autoplaying content can be paused and nobody can point to the control. Elsewhere the report claims full support for a criterion the product genuinely fails, which is a bigger problem than the failure itself.

A conformance report is a factual document about a specific version of a product. Motion is one of the areas where vague claims are easiest to make and easiest to disprove.

Root cause analysis: which criteria motion touches

Five criteria commonly apply to animation, and each asks a different question.

2.2.2 Pause, Stop, Hide (Level A). Any content that moves, blinks or scrolls automatically for more than five seconds must have a mechanism to pause, stop or hide it. Carousels, ambient motion, marquees and autoplaying video all fall here — the requirement covered in providing pause controls for autoplay motion.

2.3.1 Three Flashes or Below Threshold (Level A). Nothing may flash more than three times per second unless it is below the general and red flash thresholds, the measurement described in auditing animations against the three flashes threshold.

2.3.3 Animation from Interactions (Level AAA). Motion animation triggered by interaction can be disabled unless it is essential. This is where prefers-reduced-motion support is documented.

1.4.2 Audio Control (Level A) applies when animated media carries sound.

2.4.7 Focus Visible (Level AA) intersects with motion when focus indicators animate, the subject of animated focus indicators and WCAG focus criteria.

The language is defined. In a VPAT-style report, “Supports” means the criterion is met throughout, “Partially Supports” means some functionality does not meet it, and “Does Not Support” means the majority does not. Overstating support is the most common and most damaging error: it is discovered quickly, and it undermines the parts of the report that were accurate.

Step-by-step resolution

Production code pattern

The pattern here is documentary rather than code. A useful format for each criterion:

Two details make these entries useful rather than decorative. Each names a mechanism and a location, so a reviewer can verify it in minutes. And the partial-support entry names the exact exception, a remediation target and a tracking identifier, which is more credible than a blanket “Supports” and more useful than an unexplained “Partially Supports”.

// Keeping the report honest: a release check that lists animations not covered
// by the reduced-motion branch, so the report's exceptions stay accurate.
const uncovered = [...document.querySelectorAll('*')]
  .flatMap((el) => el.getAnimations())
  .filter((a) => a.effect?.getComputedTiming().duration > 0)
  .map((a) => a.animationName ?? a.transitionProperty ?? '(script)');
console.table([...new Set(uncovered)]);   // run with reduced motion emulated before each release

Rendering Impact: none. The check runs in a test environment with reduced motion emulated; anything it lists is either a bug or an exception the report must name.

Keeping the report current

A conformance report describes a version. Animation changes frequently — a new marketing page adds a carousel, a component library update introduces an entrance — so the motion sections go stale faster than most. Tie re-verification to releases: run the automated reduced-motion and flash checks in CI, run the manual audit on changed flows, and update the report’s version and date whenever a motion-related claim changes.

Where a claim is time-bound, say so. “As of release 4.2” is honest and useful; an undated “Supports” invites the assumption that it still holds two years later.

Verification checklist

• Every motion-related criterion is addressed, including AAA where claimed
• Each entry names a mechanism and where to find it
• Partial support entries name the exact exception
• Remediation notes include an owner and a target release
• Evidence is reproducible by a reviewer
• The report’s version and date match the release it describes

Constraints and trade-offs

• Honest partial-support entries can affect procurement decisions; inaccurate claims affect them worse.
• Detailed evidence takes time to write and to keep current.
• AAA criteria are optional to claim, but claiming them without support is misleading.
• Automated checks cannot verify every criterion; manual evidence is still required.
• Reports describe one version; keeping several product versions documented multiplies the work.

Frequently asked questions

Which WCAG criteria apply to animation?

Most often 2.2.2 Pause, Stop, Hide; 2.3.1 Three Flashes; 2.3.3 Animation from Interactions at AAA; 1.4.2 where media has sound; and 2.4.7 where focus indicators animate.

Can a product claim full support if reduced motion is implemented?

Only if every interaction animation is genuinely removed or the remaining ones are essential. A single uncovered component makes it partial support.

What evidence should a conformance report cite for motion?

The specific mechanism and its location — the pause control and where it is, the preference support and what it removes — so a reviewer can verify it quickly.

How often should motion sections be re-verified?

Every release that changes animations, with automated checks in CI and manual audits of changed flows.

Related

• WCAG Animation Conformance — the criteria in detail
• Manual Motion Accessibility Audit Checklist — producing the evidence
• Auditing Animations Against the Three Flashes Threshold — measurement for 2.3.1