-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update UIA mappings for the <label> element #524
Comments
The change we did in Chromium: https://chromium-review.googlesource.com/c/chromium/src/+/5232179. |
@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. |
Good point. The other UIA text mappings we have in html-aam are:
Are these all roles that can contain some complex web content structure, like |
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? |
It was always like that, I suppose we simply never noticed it and/or UIA-based ATs started enforcing this requirement more seriously. |
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?
The text was updated successfully, but these errors were encountered: