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.

Sign up for GitHub

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

Jump to bottom

Valid ARIA 1.1 combobox incorrectly flagged for missing aria-controls attribute #3141

Closed
ChipElavon opened this issue Aug 30, 2021 · 2 comments
Closed

Valid ARIA 1.1 combobox incorrectly flagged for missing aria-controls attribute #3141

ChipElavon opened this issue Aug 30, 2021 · 2 comments
Labels
info needed More information or research is needed to continue

Comments

@ChipElavon
Copy link

ChipElavon commented Aug 30, 2021 •
edited
Loading

Product: axe-core

Expectation: axe-core recognizes ARIA 1.1-compliant combobox as valid

Actual: axe-core flags ARIA 1.1-compliant combobox as missing a required attribute

Motivation: To remove what seems to be a false positive from the axe-core results


axe-core version: 4.3.1
axe DevTools Extension v4.12.2
Browser and Assistive Technology versions
macOS Chrome Version 92.0.4515.159 (Official Build) (x86_64)

Here's a minimal example that will show the issue:

<html>
  <body>
    <div role="combobox" aria-expanded="false"><input type="text" /></div>
    <div role="combobox" aria-expanded="false" aria-owns="explicit-textbox"><input id="explicit-textbox" type="text" /></div>
  </body>
</html>

Open the above html in Chrome and scan the page with the axe DevTools Extension. You'll see the top combobox has a "Required ARIA attributes must be provided" violation for a missing aria-controls attribute. The bottom combobox does not get flagged for this issue.

Based on my reading of the spec the aria-owns attribute should not be required to make the combobox compliant. From the spec: the combobox MUST "...contains or owns a text input element with role textbox..." and the definition of "owns" reads "An 'owned element' is any DOM descendant of the element, any element specified as a child via aria-owns, or any DOM descendant of the owned child." Since the first combobox in the example has a textbox descendant, the aria-owns attribute should not be required to show ownership of that element.

I believe this change in behavior was introduced when ARIA 1.2 combobox support was added in #3033.

This will negatively impact any users of the material-ui autocomplete component as it is being flagged as being out of compliance by axe scans.
@straker
Copy link
Contributor

straker commented Sep 2, 2021 •
edited
Loading

Thanks for the issue. With the change to the 1.2 combobox we dropped the requirements for owning elements, but added that aria-controls or aria-owns be present. Using the examples provided, both are missing the requirement that they own or control a listbox element.

When a combobox is expanded, authors MUST ensure it contains or owns an element that has a role of listbox, tree, grid, or dialog. This element is the combobox popup. When the combobox is expanded, authors MUST set aria-controls on the textbox element to a value that refers to the combobox popup element.

However, testing the combobox element on material-ui, I'm not seeing any violations using [email protected] when either the combobox is collapsed or expanded.

@straker straker added the info needed More information or research is needed to continue label Sep 2, 2021
@ChipElavon
Copy link
Author

If [email protected] no longer reports an issue with the material-ui combobox then that should resolve this issue. Looks like the latest Chrome extension still uses [email protected] so I'll wait for a new release of the extension and try again.
Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
info needed More information or research is needed to continue
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@straker @ChipElavon