Update UIA mappings for the <label> element

[benbeaudry]

The current mappings for the element indicate that a element should be mapped to a UIA_TextControlTypeId. However, since a element can have children, it's possible to have cases like this: my label which would then be exposed to UIA as

++UIA_TextControlTypeId ++++UIA_TextControlTypeId

This is invalid in the world of UIA. UIA expects UIA_TextControlTypeId to be a leaf node. It effectively makes Narrator, a UIA-based AT, read both UIA_TextControlTypeId nodes independently. Instead, I suggest we map the element to UIA_GroupControlTypeId and continue mapping its descendants like they should be. We just performed that change in Chromium, and it leads to an improved user experience with UIA based ATs.

I'm wondering if this could possibly lead to undefined behaviors, though. Thoughts?

[benbeaudry]

The change we did in Chromium: https://chromium-review.googlesource.com/c/chromium/src/+/5232179.

[scottaohara]

@benbeaudry what you're saying makes sense if that's how UIA's text control type is meant to work... but if that's the case then I think this potentially a far more pervasive issue than this single element. Arguably, based on your description I question if any element or ARIA role would reasonably map to this control type.

[benbeaudry]

Good point. The other UIA text mappings we have in html-aam are:

• legend
• abbr
• ruby
• figcaption

Are these all roles that can contain some complex web content structure, like <label>?

[scottaohara]

yes. they can all contain more than non-text content.

but that is also true for a bunch of ARIA roles as well.

did something change with the text control type, or was this always just wrong?

[benbeaudry]

It was always like that, I suppose we simply never noticed it and/or UIA-based ATs started enforcing this requirement more seriously.