lighthouse
lighthouse copied to clipboard
a11y gatherer hangs on https://almanac.httparchive.org/en/2021/ecommerce
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: https://github.com/GoogleChrome/lighthouse/issues/15216
cc @tunetheweb
target-size
is taking forever.
FYI I have "identical-links-same-purpose": "off",
in my config.
Will try it with target-size
turned off too...
It will still run in axe, since we don't connect our audit ids to the axe config like that (but we should ..)
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).
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?
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.
https://github.com/dequelabs/axe-core/issues/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.