Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for shadowDOM #87

Closed
dylanb opened this issue Jul 29, 2015 · 12 comments
Closed

Add support for shadowDOM #87

dylanb opened this issue Jul 29, 2015 · 12 comments
Labels
core Issues in the core code (lib/core) feat New feature or enhancement

Comments

@dylanb
Copy link
Contributor

dylanb commented Jul 29, 2015

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

@dsturley dsturley removed their assignment Jul 31, 2015
@dsturley dsturley added feat New feature or enhancement core Issues in the core code (lib/core) labels Jul 31, 2015
felixzapata pushed a commit to felixzapata/axe-core that referenced this issue Aug 13, 2016
@felixzapata
Copy link
Contributor

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.

shadow-dom

no-shadow-dom

@marcysutton
Copy link
Contributor

marcysutton commented Oct 3, 2016

@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
Copy link
Contributor Author

dylanb commented Oct 4, 2016

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
Copy link

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
Copy link
Contributor

alice commented Nov 3, 2016

@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
Copy link
Contributor

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
Copy link
Contributor

alice commented Nov 7, 2016

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
Copy link
Contributor

marcysutton commented Nov 7, 2016

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
Copy link

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 pushed a commit that referenced this issue Apr 25, 2017
fix (audit): don't override custom helpUrl
@marcysutton
Copy link
Contributor

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

@dylanb
Copy link
Contributor Author

dylanb commented Jun 29, 2017

@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
Copy link
Contributor

Closed with #317.

mrtnvh pushed a commit to mrtnvh/axe-core that referenced this issue Nov 24, 2023
…quelabs#87)

Bumps [bl](https://github.com/rvagg/bl) from 4.0.2 to 4.0.3.
- [Release notes](https://github.com/rvagg/bl/releases)
- [Commits](rvagg/bl@v4.0.2...v4.0.3)

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Issues in the core code (lib/core) feat New feature or enhancement
Projects
None yet
Development

No branches or pull requests

8 participants