Add support for shadowDOM

[dylanb]

Similar to what is in accessibility-developer-tools https://github.com/GoogleChrome/accessibility-developer-tools/blob/master/src/js/AuditRule.js#L129

[felixzapata]

hi, any update about this issue? With the Chrome extension for a project demo built with Polymer, with Shadow DOM the extension says that there are no errors, but without Shadow DOM the extension can analyze the page.

I've used the API with the console too, and the results are the same.

[marcysutton]

@dylanb I think the original Chrome A11y Developer Tools source may have changed, so it's unclear which part of the source was supposed to be linked.

We use document.querySelector methods which don't step into the Shadow DOM, right? Does the Chrome version do the work of iterating over nodes to audit instead of relying on DOM APIs? We might need something similar to support a subset of rules for testing virtual DOM (using JSDOM, pre-compiled Angular 2, etc.).

[dylanb]

This work is backlogged. @marcysutton it is a lot more complex than just iterating into shadow roots. For example IDs can be unique within each shadow root. Also, trying to figure out what the computed styles are...

@felixzapata best short-term route is to use the polymer polyfilled DOM and ignore unique ID issues when the IDs live in their own shadow DOM

[seancurtis]

Could you check for a shadow root on each node (maybe just on custom elements) and then just test the markup within it in isolation of the rest of the page? They're supposed to be a new document context anyway. Maybe not all tests are needed (eg you could potentially ignore ID uniqueness).

[alice]

@seancurtis That would seem to be in the spirit of Shadow DOM, yeah. And you wouldn't need to ignore ID uniqueness since IDs should be unique to a shadow root.

[WilcoFiers]

The difficulty is in keeping this performant. It makes sense to limit Shadow DOM testing to custom elements. If anyone is interested in helping out building this into axe, I'd be happy to pitch in.

[alice]

On the performance issue, do you track performance already?

@ricksbrown did an amazing refactor of accessibility-developer-tools where he pulled the entire "gather" step into one single tree traversal, instead of doing a traverse or select (which does a more efficient traverse on the browser-side) for each rule. Would that be feasible for axe-core?

Short of that, how would you find custom elements in the page? Is there a way to do it without traversing? And, obviously, this wouldn't handle cases where developers have used Shadow DOM without using custom elements (see: Chrome DevTools for an example), but I guess that's enough of a corner case not to worry about?

[marcysutton]

Side-note: I'm working on performance right now as part of #240. That work should definitely help since we're using a style cache for lookups instead of more expensive calculations on the tree over and over.

[TalhaAydin]

Hi all. When shadow dom support is released, how big do you expect the breaking changes to be to the current API and generated results object (if any)?

[marcysutton]

@TalhaAydin you can review the work being conducted in the shadowDOM branch: #317

[dylanb]

@TalhaAydin there will be no changes to the API when you use the library

There will be changes to the API that rules use, so if a rule uses commons or utils functions, it may have to be updated. Rules that do not use commons and util functions will continue to function as before

The results object will only change for violations that are found within shadow DOM. The target attribute of the node objects that are part of the violations and other arrays will be an array of either strings or array(s) of strings instead of just being an array of strings.

We will update the version number to 3.x because of these changes.

[marcysutton]

Closed with #317.