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

Proposal: Query by accessible name #6307

Closed
3 tasks done
johanbay opened this issue Aug 5, 2020 · 3 comments · Fixed by #6472
Closed
3 tasks done

Proposal: Query by accessible name #6307

johanbay opened this issue Aug 5, 2020 · 3 comments · Fixed by #6472
Assignees

Comments

@johanbay
Copy link
Collaborator

johanbay commented Aug 5, 2020

Motivation

Currently Puppeteer supports querying the DOM using CSS selectors. While this provides a versatile way to select DOM elements by for example id, tag, or class-attributes, these properties are often subject to change or even generated at build-time.
Alternatively, we could support querying the accessibility tree for accessible names.
This could provide the following benefits:

  • Make selectors in test scripts more resilient to source code changes.
  • Make test scripts more readable since the accessible names should carry semantic context.
  • Motivate good practices for assigning accessibility properties to elements.

Current state of affairs

Querying by accessible names is currently possible by implementing a custom query handler to traverse the DOM and check accessible names along the way. This is what puppeteer/recorder currently does. Since there is no direct way to get the computed accessible name and role from the browser-side, one has to compute those on demand which is not a trivial task.
One can instead access and traverse the accessibility tree through Puppeteer where the computed accessible names and roles are available. The catch then is that Puppeteer only gives access to a static snapshot of the accessibility tree.
To support interaction, we need a mapping to live DOM nodes.

Proposal

Extend Puppeteer to support querying the accessibility tree with support for interaction.
The steps for achieving this could be:

@johanbay johanbay self-assigned this Aug 5, 2020
johanbay added a commit that referenced this issue Sep 21, 2020
The logic for waitForXPath and waitForSelector is currently very tightly coupled. This commit tries to untangle that relationship. This is the first step towards introducing built-in query handlers that are not executed in the page context (#6307).
johanbay added a commit that referenced this issue Sep 23, 2020
This commit changes the internal representation of query handlers to contain Puppeteer-level code instead of page functions.
The interface `CustomQueryHandler` is introduced for user-defined query handlers. When a `CustomQueryHandler` is registered using  `registerCustomQueryHandler` a corresponding Puppeteer-level handler is created through `makeQueryHandler` by wrapping the page functions as appropriate.
The internal query handlers (defined by the interface `QueryHandler`) contain two new functions: `waitFor` and `queryAllArray`.
- `waitFor` allows page-based handlers to make use of the `WaitTask`-backed implementation in `DOMWorld`, whereas purely Puppeteer-based handlers can define an alternative approach instead.
- `queryAllArray` is similar to `queryAll` but with a slightly different interface; it returns a `JSHandle` to an array with the results as opposed to an array of `ElementHandle`. It is used by `$$eval`. 

After this change, we can introduce built-in query handlers that are not executed in the page context (#6307).
johanbay added a commit that referenced this issue Oct 5, 2020
This commit adds a new built-in handler for querying by accessible name and role (#6307).
Support for waitForSelector will be added in a follow-up commit.
@johanbay johanbay linked a pull request Oct 7, 2020 that will close this issue
johanbay added a commit that referenced this issue Oct 7, 2020
This commit adds waitFor to the built-in aria handler (#6307).
@WickyNilliams
Copy link

Hey, sorry to jump on a closed issue - i'm wondering if there are any docs available for this feature? The introductory blog post mostly explains about the internal implementation details, and doesn't explain the feature set.

Love the idea here, I'm eager to put it to use in my test suite!

@mathiasbynens
Copy link
Member

mathiasbynens commented Feb 5, 2021

That's a good point. While we do have docs on how to register custom query handlers, we don't really document the built-in ones. Let’s use a new issue for this: #6822

@WickyNilliams
Copy link

Thanks @mathiasbynens!

This was referenced Jun 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants