Form-Associated Custom Elements are not Associated to Labels

[break-stuff]

Product

axe Extension

Product Version

4.58.3

Latest Version

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

Issue Description

Expectation

When using the ElementInternals API, form-associated custom elements should be able to be referenced by <label> elements using the for attribute.

Actual

The extension cited a critical issue saying the element was missing a label.

How to Reproduce

• Go to 'https://cdpn.io/break-stuff/fullpage/qBQPGVb?nocache=true&view=fullpage'
• Open developer tools and select "axe DevTools" tab
• Click "Scan All of my Page"

Additional context

The source code for this can be found here - https://codepen.io/break-stuff/pen/qBQPGVb

[straker]

Thanks for the issue. I'm not sure the ElementInternals are working correctly for screen readers. Here's how different screen readers and browsers read the input when focused:

• VoiceOver / Safari - "Edit text, blank"
• JAWS / Chrome - "My Input, edit, type of text"
• NVDA / Firefox - "Edit has autocomplete, blank"

Checking the internals.labels property and the label is indeed associated with the element according to the API, but it appears that screen readers haven't caught up to this approach yet. As such I think it is correct that axe-core fails these.

[break-stuff]

Oh, interesting. VoiceOver on Chrome and Firefox are working for me - "Edit text, blank, My Input, group".
MS Narrator also appears to read it.

[break-stuff]

I went ahead and filed bugs for both NVDA and Apple about the above issues.

[WilcoFiers]

I think we're going to need to figure out a way to detect this and report a separate issue for it. Missing for labels is a big problem, I wouldn't want to pass this, but it would be useful if we explicitly stated this technique isn't broadly supported yet.

[break-stuff]

After doing some digging, it looks like in Safari it is a bug on their end. The element is not properly referencing the label.

[mrazzari]

Oh, interesting. VoiceOver on Chrome and Firefox are working for me - "Edit text, blank, My Input, group". MS Narrator also appears to read it.

The VO + Chrome implementation isn't great either.

• The "group" in your test is a smell. Only actual groups, like a fieldset, should be announced as groups.
• Using arrow navigation (VO + Right Arrow) each field results in 3 stops:
  1. My input, group.
  2. Text edit, empty.
  3. End of, My input, group
  • Compare with a regular form field which is just 1 stop: My input, text edit.
• If we disable grouping then the control name is not announced when using arrow navigation.

Other tests:

• Narrator + Chrome: no label announced.
• Narrator + Edge: like VO, announces the label OK, but also "group".

Seems like major red flags on poor or inconsistent support for this feature.

[Westbrook]

@break-stuff Looking at this, without Reference Targets, I'm not sure why you would think that this label would point to the <input>. The <input> is on the other side of the shadow boundary, and while you've form associated the <my-input> you haven't given it a role, so it can't be "labelled" in the accessibility tree.

If that's true, isn't this more a bug of false positivity in Chrome and Firefox?

If you add a role, it performs as expected across all three browsers with Voice Over, sorry I don't have access to other screen readers just right now: https://codepen.io/Westbrook/pen/xxobNBe

[break-stuff]

I agree. I was a bit naive in my understanding of what ElementInternals actually did for custom elements. Reference targets would solve this issue.