fix: cancel all animations on page before running axe-core JS

[eoinkelly]

We noticed an issue with intermittent axe-core color-contrast false positive results on sites which animated in content at page load e.g. CSS like:

.hero {
  opacity: 0;
  transition: opacity .6s ease-out, transform .6s ease-out;
}
.hero.visible { opacity: 1 }

This change uses JS to forcibly cancel all active animations in the DOM just before the axe-core JS is run.

After a number of manual tests, this appears to fix the issue although it is hard to be 100% certain because the issue was intermittent.

[Copilot]

🟡 Changes recommended

The new document.getAnimations() call can throw or be undefined in some browser contexts, causing the entire audit run to fail unless it’s guarded.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR aims to reduce intermittent axe-core color-contrast false positives by stabilizing the DOM before running axe-core, specifically by canceling active animations right before axe.run(...) executes via Selenium’s execute_async_script.

Changes:

• Injects a JavaScript pre-step to cancel all active DOM animations immediately before running axe.run(...).

File summaries

File	Description
src/audit_plugins/axe_core_audit.py	Adds a JS snippet to cancel active animations before invoking axe-core in the browser context.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[eoinkelly]

We know exactly which browser and version we are using so this shouldn't be an issue.

[G-Rath]

it's probably still not worth doing, but fwiw the AI suggestion here is overcomplicated:

document.getAnimations?.().forEach(animation => animation.cancel())

[G-Rath]

unrelated: we should probably rename the function to something like run_axe_core cause we're doing more than just "loading" it 😅