Skip to content

Implicit combobox role cannot be found #927

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

Closed
just-boris opened this issue Apr 1, 2021 · 5 comments
Closed

Implicit combobox role cannot be found #927

just-boris opened this issue Apr 1, 2021 · 5 comments

Comments

@just-boris
Copy link

  • @testing-library/dom version: v7.30.3
  • Testing Framework and version: react-scripts: 4.0.3
  • DOM Environment: JSDOM

Relevant code or config:

<button aria-haspopup="listbox" aria-expanded="false">
  Select
</button>

The code above has an implicit combobox role, as you can see in the devtools:

Screenshot 2021-04-01 at 21 30 15

However, when I am trying to query it using getByRole("combobox", { name: "Select" }), it does not find a match.

Reproduction:

Here is a codesandbox demo with the repro:

https://codesandbox.io/s/aria-haspopup-demo-nvdty

Suggested solution:

There was a PR mentioning this issue:
#406

However, in the end it was discarded in favor of another one and did not fix the issue

@eps1lon
Copy link
Member

eps1lon commented Apr 2, 2021

Thanks for the report.

Note that chrome devtools is only a secondary source of truth.

At first we look at assistive technologoy and the ARIA specs. In this case we would need to look at html-aam and how e.g. JAWS, NVDA and VoiceOver behave.

@just-boris
Copy link
Author

just-boris commented Apr 2, 2021

Yeah, in the description I put simplified implementation.

Here is the real component implementing this pattern: https://dlcqh.csb.app/ (Source code)

Different tools support different versions of WAI-ARIA spec and following 1.1 implementation breaks tools using 1.0. Because WAI-ARIA spec changed regarding where explicit combobox role should be placed (on a container or the actual focusable trigger) we resort to avoid placing it anywhere at all. This works for the mentioned tools.

However, it is not clear, what exact aria-attribute assigns implicit combobox role. I guess, it is aria-haspopup, but I could not find evidences in WAI-ARIA standard.

@eps1lon
Copy link
Member

eps1lon commented Apr 2, 2021

This works for the mentioned tools.

I couldn't find any reference. Or do you only test this with chrome devtools and no AT at all?

@just-boris
Copy link
Author

just-boris commented Apr 2, 2021

We thoroughly test our library in NVDA and VoiceOver.

You can also double check this using the codesandbox demo.

@eps1lon
Copy link
Member

eps1lon commented Jun 2, 2021

I just tested

<button aria-haspopup="listbox" aria-expanded="false">
  Select
</button>
<select>
  <option>select</option>
</select>

in NVDA 2020.4 with FireFox and Chrome and neither combination announced the button as a combobox while the select was announced as a combobox.

I think there's a case to be made that button[aria-expanded][aria-haspopup="listbox"] should be a combobox but this is not the appropriate avenue. https://github.com/w3c/html-aam/ seems like the better option.

@eps1lon eps1lon closed this as completed Jun 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants