False failure: button with role of combobox fails for missing discernible text

[rgallagherab]

Product

axe-core

Product Version

4.9.1

Latest Version

• I have tested the issue with the latest version of the product

Issue Description

Note: I was only allowed to select one product, but this was observed both in axe-core running in our Ember integration tests and in the extension in Chrome. I thought that a fix to axe-core may also make its way into the extension, but wanted to call this out to be sure.

Expectation

The expectation is that the inner text of a button with role="combobox" would still be considered when checking for "discernible text".

Actual

Currently when a button has role="combobox" axe scans fail with the error "Buttons must have discernible text". The list of potential issues states in the first bullet point "Element does not have inner text that is visible to screen readers". This is not actually true; the button has text contents.

How to Reproduce

The issue can be observed here: https://codepen.io/rgallagherab/pen/JjqKKpE

This is a non-functional example, but the markup includes all required ARIA attributes and elements for combobox role, and no other failures relevant to the example markup (although there are 2 issues observed in the Codepen layout elements).

Additional context

From what I can gather it appears that while the element should be assessed as a combobox role two things are true:

1. It is still being considered a button to some extent considering the "Buttons must have discernible text" error is presented.
2. More importantly: axe-core is not considering the inner text of the element as described under the "fix at least (1) of the following" list. I assume this is likely some sort of conflict in how the combination of button and combobox is being handled.

As far as I can tell button should be a valid element to use role="combobox" on. If this was not the case I'd expect to see a failure for combobox not being an allowed role.

[straker]

Thanks for the issue. There's a lot going on with this so I'll try to list them as best as I can.

The main issue is that the button-name rule tries to run the button-has-visible-text check to see if the button has any text content, but since the button has a role of combobox the function skips looking at the visible text as comboboxes aren't named from content. So it ignores the text content and thus creates the violation.

Using a label for a button is not currently supported in axe-core as we found it lacked support in some assistive technologies. This may change as we readjust what our accessibility supported assistive technologies are, in which case we'll need to update the rule to handle buttons that are named from labels.

I tested out a button with role combobox in various screen readers and this is the result:

<button id="combobox-el" role="combobox" aria-controls="cb-listbox" aria-required="true" aria-expanded="false">
  <div>Combobox Display Text</div>
</button>

• VoiceOver / Safari - announces the button as "Combobox DisplayTe, required list box pop up, Menu popup combox." It cuts off the last 2 letters for some reason. I tested it with various words and lengths and it was consistently cutting off the last 2 letters.
• JAWS / Chrome - announces the button as "Combobox required, combobox display text"
• NVDA / Firefox - "Combobox, combobox display text, collapsed required"

So it seems the text content is supported, but with VoiceOver and Safari I would still call this an accessibility supported issue. So using text content for the name of a combobox button can cause problems.

Lastly, I don't think button-name is the correct rule to run on this setup. Button name is suppose to be run for button roles. Instead I believe the correct rule to run is the aria-command-name rule which is suppose to run for for elements with role combobox. It doesn't though since the matcher on the rule specifically ignores elements with native naming methods (such as button) in order to prevent throwing two naming violations on the same element. aria-command-name doesn't look at text content so it won't use a remediation message that doesn't make sense for the context. We'll need to update the rule in order to handle this and other similar cases.

[scottaohara]

came across this issue today because we were getting similar false positives for valid use of button[role=combobox] that are correctly named by an associated label element (codepen provided in the op is sufficient to demonstrate) - obviously related to the other false positive i've mentioned with #3696

concerning the way this issue was raised, specifically the mention of the fact that there is text within the button (combobox) - i'd have to agree with @straker that the button name test isn't appropriate to run here - particularly since it lead to this misunderstanding of what the rule is actually trying to call out:

This is not actually true; the button has text contents.

that text is not the name of the combobox, it's the value - so it shouldn't be validated against the button name rule.

[arthurlbrjc]

Came across what I think is the same issue when using a label with a button[role=switch] .
Either with implicit or explicit labelling the rule button-name fails.

<label>
  <button type="button" role="switch" aria-checked="true" />
  Activé
</label>

or

<label htmlFor="button-switch">Activé</label>
<button id="button-switch" type="button" role="switch" aria-checked="true" />

or

<label id="button-switch--label">Activé</label>
<button aria-labelledby="button-switch--label" type="button" role="switch" aria-checked="true" />

[straker]

Github should not have closed this with the #4607. Guess my paragraph saying it shouldn't close this pr triggered a close. Reopening.