Unexpected error and guidance raised for button with accName from label element

[scottaohara]

Product

axe-core

Product Version

4.4.2

Latest Version

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

Issue Description

The following code snippet (reduced test case) was flagged as a critical impact error under the button-name rule. However, the button does have an accessible name as it is provided by its parent <label> element.

<label>
  <button role=switch aria-checked=false></button>
  Enable something	
</label>

Example codepen: https://codepen.io/scottohara/pen/vYjrboB
Additional use case for associating a <label> with a <button> provided in pen.

It seems that maybe the rule for checking if a button has an accessible name doesn't take into account that a button can be provided its name via a <label> element association.

===

As a related note to this rule, the "to solve this problem, you need to..." section that accompanies this error ends with

Element's default semantics were not overridden with role="none" or role="presentation"

That seems out of place or incomplete guidance with this rule, as those roles would not be respected on a <button> due to the presentation role conflict resolutions and these roles are ignored outright so long as the button remains focusable.

So that bullet seems like it should either be removed, or it needs to explicitly indicate that the <button> needs to also have the disabled attribute so those roles won't be ignored on the button.

Related to the documentation piece of this issue, I've filed an issue against ARIA in HTML to better expose when role=none | presentation would be allowed on <button> and <input> elements.

[straker]

I wonder if this is similar to #2488. That one used an explicit label to give a button a name, but we found it didn't work in Dragon Naturally Speaking. I can take a look to see if wrapping the button in an implicit label proves any better for it.

[scottaohara]

per the results you have from the codepen test cases you have in that other issue, there are some tests that aren't valid - specifically <div role=button> as being a <div>, it cannot be named by a <label> element. I want to make sure that those aren't being taken into consideration as unsupported instances, when the use case isn't valid.

[straker]

Makes sense. I think I did that originally just for completeness of a test case. But I can rule out some of the more invalid cases when we do our retesting.

[scottaohara]

Would appreciate that. Also, per Wilco's comment in the previous thread, I would completely agree with throwing a warning for support with Dragon (if it's still an issue. haven't checked myself) and that there are honestly better ways to name a button. I'm not going to argue about that at all, naming a button with a label element is kinda weird, but valid. So per other than what is being tested here, wcag conformance vs software support, it would be more accurate to surface this particular pattern as a warning for the potential lack of support - specifically with dragon, than saying it's a flat out failure.

[WilcoFiers]

Update: We've tested this out. While explicit labels seem to work in Dragon 16, implicit labels on buttons still do not work, regardless of what role is put on them. Thanks for helping out @mfairchild365!

Michael made a fair point here though, that maybe Dragon shouldn't be in our baseline anymore. There are alternatives to it, including on Windows.