preload-media should avoid blocking on uninteresting media elements

[dbjorge]

Product

axe-core

Product Version

4.10.2

Latest Version

• I have tested the issue with the latest version of the product

Issue Description

The only axe-core rule that actually uses preload-media, no-autoplay-audio, only cares about a specific subset of media elements (autoplay elements that are neither paused nor muted). However, axe-core's preload-media step blocks until all src-ful media elements have reached a nonzero readyState, even if those elements won't be relevant to any rule. This means that if a lazy-loaded media element exists on a page (and the page isn't in a state that will cause it to try to load), axe-core under default settings will block for 10 seconds waiting for preloading to timeout, even if the lazy-loaded media is irrelevant to any rule.

Expectation

We should avoid blocking axe-core on preload steps that might be elided and that no rule cares about.

Actual

A page with a <video muted paused preload="none"> element will cause axe-core to take 10s+ to run under default settings, even though preloading its metadata isn't be relevant to any existing rule.

How to Reproduce

Minimal repro:

<video preload="none">
  <source src="https://www.w3schools.com/html/mov_bbb.mp4" type="video/mp4">
</video>

In the motivating repro, the real video appears below the fold of the page and the page uses a scroll handler to implement a script-based lazy loading setup, and the delay is occuring within the context of @axe-core/watcher scanning such that it causes substantial delay to the containing test suite.

Additional context

There are a few options I can think of for improving this:

1. I think the least controversial improvement here would be to make preload-media ignore cases that we have no reason to expect will actually preload just by us waiting (ie, elm.preload === 'none' && elm.networkState !== NETWORK_LOADING)

2. We might also want a change to no-autoplay-audio-evaluate.js to make it more willing to deal with non-preloaded cases (ie, instead of immediately warning and incompleting, we could first say that if it has controls, return true regardless of whether duration is known, and if it doesn't have controls and does loop, return false regardless of whether duration is known)

3. We might consider making preload-media ignore cases that will be irrelevant to no-autoplay-audio (non-autoplay, paused, muted). This might reduce unnecessary preload time under default settings, but would technically be a breaking change (if a custom rule cares about broader preload behavior, or if someone's test depends on the timing of the current preload behavior). We might have to undo it if we add a new rule in the future that needs the broader preload behavior.

I'd lean towards doing just the first 2 options for now. We discussed this as a team today and decided that we'd like to do all 3 options as part of the fix.