Need more tests for nested label edge cases

[cookiecrook]

@twilco asked in another thread:

Given this markup:

<label id="label-1">
    One
    <label id="label-2"> Two <input type="checkbox"></label>
    <label> Three <input type="checkbox"></label>
</label>

When focusing the first checkbox, macOS VoiceOver reads:

• Safari: "One Two Three Two"
• Chrome: "One Two Three"
• Firefox: "Two"

This is a simplification of real markup […]

Following the letter of the spec, all labels associated with a control must be concatenated together. And if you call HTMLLabelElement.control’ on #label-1 and #label-2, they will both return the first checkbox. So by this definition, Chrome is most correct, and Safari follows the same algorithm as Chrome but duplicated part of the string. But in this case, Firefox's technically non-spec compliant behavior is the best.

If you use the for attribute, Firefox will output "One Two Three Two" (seems like a bug, like with Safari)? Seems like Firefox's behavior is that when finding labels to concatenate, it only references the nearest-ancestor label, plus the label of any number of explicit relationships with for.

Which browser seems right? If Firefox, maybe the spec needs to be clarified?

[cookiecrook]

I think in this case, there are definitive answers if we trace AccName and HTML-AAM, but it’s complicated enough to not be certain from memory. We should probably build a WPT test case with all the edge cases we can think of, determine where the implementation differences are, and clarify the AccName or HTML-AAM specs if needed.