Should it be possible to use a `ShadowRoot` as context?

[pomerantsev]

Product

axe-core

Product Version

4.11.0

Latest Version

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

Issue Description

Expectation + Actual

At the moment, passing a ShadowRoot instance as context to axe.run() results in an error: "No elements found for include in page Context".

It's either a bug, or an issue with TypeScript types (see below).

Consider either:

• Supporting a ShadowRoot as context (the TS types suggest that context may be of type Node, and ShadowRoot is a descendant of Node).
• Aligning the types with the documentation, which mentions that context should be an "element" (not a "node" — Element is also a descendant of Node).

How to Reproduce

CodePen: https://codepen.io/pavelp/pen/QwNEpwv

Additional context

• I ran into this due to noticing a bug in Accented, a library that I maintain. There's a MutationObserver there, and the nodes that the mutation observer passes to its callback get passed as context to axe.run(). The mutation observer may pass a ShadowRoot instance there, causing the bug. It will be easy enough to fix it downstream by passing the shadow root's host to axe.run() instead of passing the shadow root. However, axe would be a little more robust if it accepted the shadow root directly.
• It's not clear whether such treatment of shadow roots was intentional or not, and how easy that would be to change. I poked at the code a little, and it seems that axe maintains a cache of all the elements on the page, and the code that populates it omits the shadow roots themselves, jumping straight to their children.

[WilcoFiers]

I see no reason why axe shouldn't be able to support ShadowRoot, it accepts document nodes too after all. I'm inclined to treat this as a bug. In practice what I think we'd need to do is update context.js, when it encounters a ShadowRoot, have it work on the child nodes instead. That's likely a relatively easy fix if anyone's up for it. As mentioned, the docs and types should also be updated as part of this.

[pomerantsev]

Thanks @WilcoFiers, I can try to fix it.

Types may not need to be updated in this case — the logic will rather be updated to match the current types.

[WilcoFiers]

Much appreciated!

[pomerantsev]

@WilcoFiers would you mind taking a look at #4952? The change ended up being only 2 lines, and if you think it looks good, let me know what else I should do in order for you to accept it. Any specific contributor guidance that I should pay attention to?
I know you require test coverage, but this file doesn't seem to have any dedicated tests, so any suggestions would be appreciated.

I don't know if it makes sense to update any specific docs — this code solves my specific issue, but it still does not cover everything (there are many more node types out there, even if for most of them, it doesn't make sense to pass them to Axe).

[WilcoFiers]

I asked @straker to review. At a quick glance it at least needs a test, and I think updated docs / types is probably also useful here.