misc: reorganize accessibility gatherer #12076
Conversation
brendankenny
requested review from
connorjclark
and removed request for
a team
| const isNotApplicable = notApplicables.find(result => result.id === this.meta.id); | ||
| if (isNotApplicable) { | ||
| return { | ||
| score: 1, | ||
| score: null, |
There was a problem hiding this comment.
threw this one in for #12075 (comment) and because technically I did this, when I was updating old rawValue: trues to score: 1s all over the place :)
| // Simplify `nodes` and collect nodeDetails for each. | ||
| const nodes = result.nodes.map(node => { | ||
| const {html, target, failureSummary, element} = node; | ||
| // TODO: with `elementRef: true`, `element` _should_ always be defined, but need to verify. |
There was a problem hiding this comment.
very debatable TODO. The type is {element?: HTMLElement}, true, and we could be defensive, but AFAICT with elementRef: true element is always set.
- On the one hand I haven't been able to verify that it's always set (there doesn't seem to be a single place in the code that sets it, but maybe I'm missing it).
- On the other hand we've been assuming that it's always set since 2016.
So...worth marking it TODO or just a comment?
There was a problem hiding this comment.
Ideally we could generate a warning if this invariant fails (and when it does, just skip this node and not show it in the results / or keep and fake a nodeDetails / use the body node). would require a not-ideal restructure of these two functions, so maybe not worth it generating a warning.
am hesitant to have it fail the entire run, but it is an option to just throw an error if element does not exist..
There was a problem hiding this comment.
Ideally we could generate a warning if this invariant fails (and when it does, just skip this node and not show it in the results / or keep and fake a nodeDetails / use the body node). would require a not-ideal restructure of these two functions, so maybe not worth it generating a warning.
what do you think of beaconing to Sentry? I assume we'd get some kind of Cannot read property 'whatever' of undefined if we really did sometimes have no element, but I can't find any hint of that in Sentry for the accessibility gatherer or audits. But this way it would be explicit and we'd have as good a signal as any after a month that it really can't ever happen?
| if (!returnedValue) { | ||
| throw new Error('No axe-core results returned'); | ||
| } | ||
| if (!Array.isArray(returnedValue.violations)) { |
There was a problem hiding this comment.
we trust our evaluate() by now and don't do these checks in other gatherers. No need to keep these
| @@ -102,10 +102,9 @@ describe('Accessibility: axe-audit', () => { | |||
| } | |||
| const artifacts = { | |||
| Accessibility: { | |||
| passes: [{ | |||
| * @param {import('axe-core/axe').Result} result | ||
| * @return {LH.Artifacts.AxeRuleResult} | ||
| */ | ||
| function createAxeRuleResultArtifact(result) { |
There was a problem hiding this comment.
nice idea to pull this out to its own function
| // Simplify `nodes` and collect nodeDetails for each. | ||
| const nodes = result.nodes.map(node => { | ||
| const {html, target, failureSummary, element} = node; | ||
| // TODO: with `elementRef: true`, `element` _should_ always be defined, but need to verify. |
There was a problem hiding this comment.
Ideally we could generate a warning if this invariant fails (and when it does, just skip this node and not show it in the results / or keep and fake a nodeDetails / use the body node). would require a not-ideal restructure of these two functions, so maybe not worth it generating a warning.
am hesitant to have it fail the entire run, but it is an option to just throw an error if element does not exist..
| if (!returnedValue) { | ||
| throw new Error('No axe-core results returned'); | ||
| } | ||
| if (!Array.isArray(returnedValue.violations)) { |
brendankenny
force-pushed
the
cleana11y
branch
from
2772e13
to
b11ef6c
Compare
| }, | ||
| { | ||
| "id": "tabindex", |
There was a problem hiding this comment.
all these changes are correct? looks like a lot of deletions
There was a problem hiding this comment.
all these changes are correct? looks like a lot of deletions
yes. It's a little annoying in the diff because incomplete and notApplicable switched places in the artifact, but it reads better in the gatherer in that order, and I figured preserving artifacts.json order shouldn't negate that
There was a problem hiding this comment.
oh, and lots of deletions because all we offer for notApplicable is the id:
lighthouse/types/artifacts.d.ts
Line 182 in 11d33bb
so there's no need to keep the rest around
with the recent talk about the
accessibilitygatherer, I thought I would bring out this change which I had in another branch but is probably worth it on its own. This gatherer was written in ancient times so does some odd things, and it returns a bunch more stuff than we have inartifacts.d.ts, which means it's not usable by audits and so is wasted.axe-corealso ships with types now, so we should use them :)The goal is that it should be easier to follow and clearer where every part of the artifact comes from. No smoke test changes.
Can update after #12075 lands.