Add support for implicit role selectors

[solimant]

Is your feature request related to a problem? Please describe.
I'm always frustrated when I'm unable to select HTML elements by their implicit/default ARIA roles.

Describe the solution you'd like
Would like to be able to select an element (e.g. a button) by its implicit role:

<button>Click me</button>

browser.$('[role=button]').getText(); // Click me

Describe alternatives you've considered
No alternatives. Setting the element's implicit role explicitly on the element is not recommended practice.

Additional context
The purpose of this feature is to keep tests agnostic of any implementation, especially if implementation of a certain UI changes over time; e.g. a button implementation changes from being a button element to a label element with a "button" role. Without the ability to select by role, all tests will have to be changed.

[jayandran-Sampath]

Would like to work on this enhancement

Solution planning to implement:
step 1. Create seperate strategy to identify role based selector
step 2. Manipulate the selector string into CSS/Xpath format and pass to selenium to identify the element

[role=button] => button || [role='button'] || input[role='button']

Catch i could foresee : could not find all default/implicit tags list which have mapping to roles (eg: role=button can be ,)

Note: if there is any other solution please share that as well

[christian-bromann]

The difficulty here is how do you find the computed role of that element? I think what @solimant is describing is being able to find an element that has a computed role of button, hence:

<button>Click me</button>

if the element already has that role assigned like

<button role="button">Click me</button>

It would be an easy xpath change. But this way it is much more difficult because getting the accessibility tree is not trivial

[jayandran-Sampath]

@christian-bromann Able to get implicit role based element detail by using aria-query library.

Also i'm able to convert that detail into XPATH locator. will raise PR in a day or two

eg:

selector : $('[role=button]') => this will be identified using XPATH with below string

//*[@role=“button”]|//input[@type="checkbox”]|//summary[@aria-expanded="false”]|//summary[@aria-expanded="true”]|//input[@type="button”]|//input[@type="image”]|//input[@type="reset”]|//input[@type="submit"]|//button

[christian-bromann]

This has been merged and will be released in v7.1 soon (waiting for 2 more PRs to get in first). Thanks @jayandran-Sampath for the contribution!

[mohamadov1]

Why can JavaScript locate an element with a role="link" but WebDriver API cannot?

A: In JavaScript, it is possible to locate elements with an explicit ARIA role attribute, even if it doesn't exist in the HTML code of the page. This is because modern browsers implement the WAI-ARIA specification, which allows web developers to add roles, states, and properties to HTML elements to improve accessibility.

Therefore, if you use JavaScript to locate a link element using the "link" WAI-ARIA role attribute, the browser will be able to find the element even if it doesn't have an explicit role attribute in the HTML code of the page.

On the other hand, with the WebDriver API, if the WAI-ARIA role attribute is not explicit, it will not be taken into account when searching for elements on the page, because the search is based on the DOM of the page. If the element doesn't have an explicit WAI-ARIA role attribute, it won't be possible to locate it using WAI-ARIA roles.

[clshortfuse]

I believe this should be reopened. Reading DOM is not accurate. You actually need to parse the accessibility tree. Web Components that use ElementInternals do not write anything to the DOM or the ShadowDOM.

Similarly, just because something is referenced via aria-labelledby doesn't actually guarantee the label is given because either the author referenced something that doesn't exist, or because browser bugs which can be discovered by testing.

The proper way to get the Accessible Role and Accessible Label is either iterate the accessibility tree or use getComputedRole on the element ree. Support seems pretty good at the moment:

https://wpt.fyi/results/webdriver/tests/classic/get_computed_role?label=master&label=experimental&aligned

Telling devs [role=button] is fine is misleading.

[christian-bromann]

@clshortfuse you are absolutely right, however we can't call getComputedRole on every element on the page. The WebDriver Bidi spec is planning to have a command to get the a11y tree which would allow us to do our own querying based on a a11y label.

The proper way to get the Accessible Role and Accessible Label is either iterate the accessibility tree or use getComputedRole on the element ree. Support seems pretty good at the moment:

I am not aware of any JS interface that would allow to return the accessibility tree, even then if the tree returns 1000 elements it would be not feasible to call getComputedRole on every element of them.

[christian-bromann]

Just fyi: I requested a selector strategy for elements with with accessibility name: w3c/webdriver-bidi#443

[clshortfuse]

@christian-bromann Thanks!

I didn't really find AXTree being planned so I threw a comment over at web-platform-tests/interop-accessibility#2 (comment) (though I could just be bad at searching.)

I've been using playwright to test AX trees on Firefox and Webkit, but found a couple of bugs in their implementation. The playwright team has some custom patches for Webkit which is where their magic is. But they've deprecated AX tree snapshotting, so I'm looking for another viable solution.

microsoft/playwright#16159

[christian-bromann]

The playwright team has some custom patches for Webkit which is where their magic is.

WebdriverIO is based on web standards and doesn't do any monkey patching of browsers to give you the ability to test in a browser that none of your users use. I am working with the WG to get this landed cross browser so keep an eye on the issue I've shared 😉