Possible false positive for label-title-only, caused by aria-describedby

[fymmot]

Product

axe-core

Description:

I think I may have found a false positive bug for the label-title-only rule when using a combination of aria-labelledby, aria-describedby and aria-hidden on the labelling element.

Reproduced and explained here: https://codepen.io/fymmot/full/XWgQJLw

(My purpose for using aria-labelledby and aria-hidden in this way is to avoid duplicate announcements of the label texts for screen reader users. In our particular use case, we are using multiple elements to construct the label, which causes multiple swipes or down arrow interactions to move past it for the user.)

Expectation:

I expect that I can label an <input type="radio"> using aria-labelledby and having aria-hidden set on the labelling element.

I also expect that I can use aria-describedby on the same <input>, without it triggering a label-title-only error in aXe.

Actual:

When using a combination of aria-labelledby, aria-hidden and aria-describedby, aXe throws a label-title-only error.

I also get the same error if using hidden instead of aria-hidden.

I can remove the error by removing the aria-describedby attribute but keeping aria-labelledby.

I can also fix the error by removing aria-hidden or hidden from the labelling element.

Motivation:

This behavior does not seem logical, or intended. I don't think the presence of aria-describedby should affect the label-title-only test, as long as the aria-labelledby is valid.

If the combination of aria-labelledby and aria-hidden is discouraged or disallowed, it should throw an error regardless of aria-describedby, which it does not

axe-core version: 4.3.3
axe devtools extension (MacOS Chrome) version: 4.17.1

[straker]

Thanks for the issue. The reason this happens is that the check looks to see if the input does not have a label but uses title or aria-describedby. That's why the first case gets flagged (as the label is hidden) but the rest don't.

However the label is read by screen readers even if it is hidden. That's why the label rule isn't reporting a violation for the inputs. Confirming with @WilcoFiers to see if we need to check the visible state of the label for this rule.

[straker]

We determined that this is indeed a false positive.

[macjohnny]

a fix is implemented in #3183

[nolandanley]

I noticed that the prior fix seems to only account for elements that have aria-hidden="true". A developer at my company has a use case where they have temporarily used style="display: none" on a label element and encountered this issue.

At first I thought it made sense that a label provided programmatically to assistive tech but not visually would raise a violation, but then I noticed that even with the non-visual aria-label or with style="visibility: hidden", no violation is raised, so I would expect these use cases to either all raise a violation or for none of them to raise one.

<!-- 
  Copyright 2023 Google LLC.
  SPDX-License-Identifier: Apache-2.0
-->

<span id="description">Description</span>

<!-- Does not raise label-title-only violation because of fix -->
<span id="aria-hidden-label" aria-hidden="true">ARIA hidden label</span>
<input aria-labelledby="aria-hidden-label" aria-describedby="description" />

<!-- Raises label-title-only violation -->
<span id="no-display-label" style="display: none">Label not displayed visually</span>
<input aria-labelledby="no-display-label" aria-describedby="description" />

<!-- Does not raise label-title-only violation -->
<span id="no-visibility-label" style="visibility: hidden">Label not displayed visually</span>
<input aria-labelledby="no-visibility-label" aria-describedby="description" />

<!-- Does not raise label-title-only violation -->
<input aria-label="Label not displayed visually" aria-describedby="description" />

I tested this with v4.7.0 and with Chrome+VoiceOver.

[straker]

@nolandanley Would you mind opening a new issue for that? We recently refactored how we handle detecting visibility on elements (screen reader vs visual) so we might just need to move over to that since they didn't exist when the original fix for this issue was created.