label-content-name-mismatch should consider cases that don't use `aria-label` (such as sr-only elements)

[botic]

Product

axe-core

Feature Description

Take the following HTML with accessible names defined via aria-label:

<button aria-label="1: View all">1: View all</button>
<button aria-label="2: View all videos">2: View all</button>
<button aria-label="3: View all of my videos">3: View videos</button>

Variants 1 and 2 pass the "label-content-name-mismatch" rule because it just checks the prefix of the aria-label against the actual text content of the node. Variant 3 fails the test because all of my is inserted in the middle of the label, but is clearly a more descriptive label for the given button.

The "label-content-name-mismatch" rule should be more relaxed and just check if all words of the accessible name are in occuring in the same order as in the visible text.

Here a screenshot of a concrete example in Lightouse 11 with axe-core 4.8:

Should pass

<button aria-label="one">one</button>
<button aria-label="one two">one</button>
<button aria-label="one two three">one three</button>

Should fail

<button aria-label="one">two</button>
<button aria-label="three two one">one two three</button>

[straker]

Thanks for the issue. The reason the example provided fails is that the accessible name of the button does not match the beginning of the aria-label. This follows Technique G208 of how to meet SC 2.5.3 in that the visible button text matches the beginning of the accessible name. Due to how speech recognition software works, trying to activate the button by saying "view videos" may not match the button's accessible name of "view all my videos" since there are words in between. It is best to avoid these problems by making sure the visible text label of the button also matches the beginning of the accessible name.

In situations where the visible label is considered inadequate as the accessible name, it is possible to supplement text in the accessible name. However, in order to meet 2.5.3 Label in Name, the text string that makes up the visible label must occur in its entirety in the accessible name. In most situations, where it is felt that additional context is needed, it is recommended that the visible text should precede the additional text. When authors make sure that the visible label of a control is included, intact, in the accessible name of that control, speech input users can be confident that their input will be correctly interpreted.

[botic]

Thanks for pointing this out! After some more testing with G208 in mind: I think the test could be stricter to catch workarounds with CSS. But this might be impossible to detect via automated testing.

Button number 3 fails as before, but recreating the same effect with the infamous sr-only screenreader-only CSS class didn't trigger axe-core. Since the visible label does not match the elements text, speech recognition might fail on finding it in the DOM. An acceptable solution is the last button, where the more specific information is carried out as a prefix and thus keeps the visible label intact.

<ol>
  <li><button aria-label="View all">View all</button>
  <li><button aria-label="View all videos">View all</button>
  <li><button aria-label="View all of my videos">View videos</button>
  <li><button>View <span class="sr-only">all of my</span> videos</button>
  <li><button aria-label="Your library - view videos">View videos</button>
</ol>

Thanks for pointing me in the right direction and I hope my additional feedback is helpful on this topic.

[straker]

Thanks for the suggestion. We'll look into what it would take to implement this. Since the original issue and this suggestion are a bit different, I'm going to update the title of the issue to describe the feature rather than the bug so we can track this easier.