Open rgallagherab opened 4 months ago
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>
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.
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.
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" />
Product
axe-core
Product Version
4.9.1
Latest Version
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 toaxe-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
withrole="combobox"
would still be considered when checking for "discernible text".Actual
Currently when a
button
hasrole="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; thebutton
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:button
to some extent considering the "Buttons must have discernible text" error is presented.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 ofbutton
andcombobox
is being handled.As far as I can tell
button
should be a valid element to userole="combobox"
on. If this was not the case I'd expect to see a failure forcombobox
not being an allowed role.