mark custom elements missing an open shadow for needs review if it fails a rule

[straker]

If a custom element is picked up by a rule it can fail under two cases which probably shouldn't:

1. the element isn't defined in the CustomElementRegistry
2. the element is defined but uses a closed shadow root

It would be nice if axe-core detected these two cases and marked the element as needs review rather than fail it for any rule it fails.

We can easily detect the first case by using CustomElement.get to see if the element name has been defined. For the 2nd case, it might be safe enough to assume that if the element is defined but does not have content or an open shadow root, it has a closed shadow root and we should mark it for needs review as we can't tell for certain anything about the node.

[dbjorge]

+1 for case 2; we just hit a case today where an Accessibility Insights user contacted us about a false positive in the aria-required-parent rule where a custom element of form <custom-tree-item role="treeitem" /> is slotted into a <div role="group"> that is hidden behind a closed shadow root. Repro codepen

[dylanb]

@dbjorge tell them to not use closed shadow root. I predicted that this would happen when that flag was being considered (but Apple was not prepared to listen). I think we should consistently coax people to not use it because there is no easy way for us to consistently avoid these issues.

[dbjorge]

Recommending that they avoid using closed shadow roots is definitely our first step! Unfortunately it isn't always easy for the impacted user to do so; in the particular motivating case I mentioned above, the issue was in a UI framework which the user didn't have a lot of choice in using.

Obviously the best solution here is to convince the UI framework to stop using closed shadow roots, too, but in the meantime (or if a dependency isn't receptive), we think it would be more user-friendly to present the unanalyzable cases as requiring human review rather than false positives.

[brennanyoung]

I just learned today that custom components have no default semantic role.

Not sure if this means that it is impossible to determine whether (e.g.) naming is supported.

Is there no reliable way to discover what (if any) semantics are exposed by a custom component?

[straker]

@brennanyoung until AOM is adopted and supported, custom element won't expose any accessibility semantics by themselves. So a user would have to add all that information themselves to the DOM.