a11y gatherer hangs on https://almanac.httparchive.org/en/2021/ecommerce

[connorjclark]

This results in a PROTOCOL_TIMEOUT:

node cli https://almanac.httparchive.org/en/2021/ecommerce --only-categories=accessibility

Did not happen in 10.0

I bisected to: #15216

cc @tunetheweb

[connorjclark]

target-size is taking forever.

[tunetheweb]

FYI I have "identical-links-same-purpose": "off", in my config.

Will try it with target-size turned off too...

[connorjclark]

It will still run in axe, since we don't connect our audit ids to the axe config like that (but we should ..)

[adamraine]

I think we should upstream this bug to axe if we can. Even though the audit is hidden, we eventually want to use it and I think disabling it completely will lose value in HTTPA runs (ironic that this happens on https://almanac.httparchive.org/en/2021/ecommerce tho haha).

[tunetheweb]

FYI, I also saw problems with https://almanac.httparchive.org/en/2021/webassembly

Both have a lot of web mentions (which we render at the bottom of the page). Turning this functionality off (https://almanac.httparchive.org/en/2021/webassembly?nowebmentions) allowed the page to pass Lighthouse runs.

So either the DOM's got too large with those, or axe doesn't handle a page with a lot of similar things. A lot of them do have the same "View Source" link despite pointing to different sources which might fail the new identical-links-same-purpose (docs) audit?

[connorjclark]

target-size is taking forever.

should clarify, of that commit i bisected to this was the only thing that was a problem. Disabling target-size axe check was the only thing necessary to allow the run to finish.

[adamraine]

dequelabs/axe-core#4360

We can disable the target-size rule temporarily. If axe fixes this issue or we decide to elevate target-size to the report UI then we should re enable it.