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

Make browser globals optional #1417

Closed
WilcoFiers opened this issue Mar 7, 2019 · 3 comments
Closed

Make browser globals optional #1417

WilcoFiers opened this issue Mar 7, 2019 · 3 comments
Assignees
Labels
core Issues in the core code (lib/core) feat New feature or enhancement
Milestone

Comments

@WilcoFiers
Copy link
Contributor

WilcoFiers commented Mar 7, 2019

Currently, axe-core assumes it runs in the browser and thus it assumes it has access to all default browser. Things like window and document are required for axe-core to run.

This creates a challenge when using axe-core with things like JSDOM. To use axe-core, someone has to set up a number of global variables before they can include axe-core.

const doc = jsdom.jsdom('<!doctype html><html><body></body></html>');
global.document = doc;
global.window = doc.defaultView;

const axe = require('axe-core');

This implicit reliance on globals is problematic, and can lead to issues like #1404. A much cleaner solution would be if axe-core would infer its document / window objects from whatever context it is passed:

const results = await axe.run(elm)

You can infer an element's document and what the corresponding window is. The only time we would need access to a global object is if axe.run() wasn't passed any argument, and ideally, we'd do it only once.

This is a significant piece of work. I think we would have to pass document and window objects around as arguments to check and matches functions. Alternatively we could also add those two objects to the context object. That would be a breaking change, but IMO it is a cleaner solution.


An interim solution would be for us to tighten ESLint and only allow document and window objects as globals. That would prevent a problem like we had in #1404.

@WilcoFiers WilcoFiers added feat New feature or enhancement core Issues in the core code (lib/core) labels Mar 11, 2019
@dylanb
Copy link
Contributor

dylanb commented Jun 16, 2019

Which of the proposals would assist in the work we are doing towards abstracting the DOM dependencies?

@WilcoFiers WilcoFiers added this to the Axe-core 4.0 milestone Dec 10, 2019
@mohanraj-r
Copy link
Contributor

Could better context detection also help with Executing axe in headless chrome yields different results · Issue #2088 · dequelabs/axe-core?

@padmavemulapati
Copy link

devTask

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

6 participants