feat: add a reference to the node a rule failed on

[stephenmathieson]

This patch adds a .node reference to an errored rule result. This can be used to determine which node the rule errored on and will be helpful for debugging purposes.

Closes #1317.

Reviewer checks

Required fields, to be filled out by PR reviewer(s)

• Follows the commit message policy, appropriate for next version
• Has documentation updated, a DU ticket, or requires no documentation change
• Includes new tests, or was unnecessary
• Code is reviewed for security by: @WilcoFiers

[stephenmathieson]

Seems this isn't quite as simple as I had hoped. Since the results object is serialized (JSON.stringify()), we can't just attach the node here (due to circular references). Perhaps a unique selector for the element would work instead?

Thoughts anyone?

[straker]

Would getting the outerHTML be sufficient for debugging in these cases?

[stephenmathieson]

I don't think outerHTML would be enough by itself, since it won't always point to a single node. For example, if axe-core errored on one of the <span>s in the below chunk of HTML, we wouldn't know which:

<div>
  <span>hello</span>
  <span>hello</span>
  <span>hello</span>
</div>

This is why I was thinking a (unique) selector would work, since we'd get back something like: div > span:nth-child(2) which paints a clearer picture.

This said, perhaps an object which resembles the following would work?

{
  "html": "<span>hello</span>",
  "selector": "div > span:nth-child(2)"
}

[straker]

I guess since axe reports issues using a unique selector then it would work. Though not being able to click on the inspect node button right above it might still be problematic for DOM that repeats structure. But I can't think of a better alternative without having the actual node to reference.

[jeeyyy]

@stephenmathieson, is it a DqElement at this point? If yes, there is a getter named selector which can return a unique CSS selector for the element

See - https://github.com/dequelabs/axe-core/blob/develop/lib/core/utils/dq-element.js#L56

[WilcoFiers]

Actually, Jey is right, we should get the selector and HTML of the element, not the element itself.

[stephenmathieson]

Looks like we can use the toJSON method which should provide all necessary information.

Updated

[stephenmathieson]

Turns out, this isn't a DqElement. It's something else. I'm trying to figure out what's going on here.

Didn't think this was going to be nearly as complicated as seems to be 🤷‍♀️

[stephenmathieson]

I figured out how to make node a DqElement here, but the tests are now erroring with:

Error: Expect axe._selectorData to be set up
    at generateSelector (http://localhost:9876/tmp/core/utils/get-selector.js:308:9)
    at Object.createUniqueSelector [as getSelector] (http://localhost:9876/tmp/core/utils/get-selector.js:377:10)
    at DqElement.get selector [as selector] (http://localhost:9876/tmp/core/utils/dq-element.js:58:43)
    at DqElement.toJSON (http://localhost:9876/tmp/core/utils/dq-element.js:84:19)

I do not understand the error here, so any help/suggestions would be appreciated.

[jeeyyy]

Updated. Tests are fixed.

[WilcoFiers]

This seems unnecessary.

[stephenmathieson]

The "max statements" rule seems unnecessary. We always increase the minimum rather than refactoring our code. IMO it should be disabled.