Update UIA aria-readonly mappings

[sivakusayan]

Closes #127

I accidentally closed #192 messing around with my fork (woops), so I'm resubmitting - sorry for the trouble 🙁.

Duplicating the original PR's content here.

---

Preview | Diff

[sivakusayan]

Closes #127

The UIA aria-readonly mappings only accounted for controls that implemented the IValueProvider interface. Now, it also accounts for controls that implement the IRangeValueProvider, and otherwise puts the information in AriaProperties if a control implements neither IValueProvider nor IRangeValueProvider.

Implementation

• WPT tests: Update UIA aria-readonly mappings web-platform-tests/wpt#42551
• Implementations (link to issue or when done, link to commit):
  • WebKit: N/A
  • Gecko: N/A, no UIAutomation support.
  • Blink: Commit. Here is the current code. Full support, although Chromium does seem to implement certain UIAutomation patterns (I think) unnecessarily, but functionally everything seems correct.

As an aside, if you want to observe this mapping in Blink, you'll need to use Edge or run Chromium with UIAutomation enabled - the UIAutomation bridge will not map IA2 STATE_SYSTEM_READONLY to the AriaProperties property when appropriate.

---

Preview | Diff

[benbeaudry]

nit: Can we remove the "?view=windowsdesktop-7.0" parameters from the URLs? I counted 8 instances.

[benbeaudry]

Are we absolutely certain about this? Our approach in Chromium is to always expose the AriaProperties in this property, regardless of whether it is already exposed in other more relevant UIA properties. I believe this is also what the documentation indicates as well: https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-ariaspecification#w3c-aria-states-and-properties-mapped-to-microsoft-active-accessibility-and-ui-automation.

[sivakusayan]

Thanks for that link - I got the impression from 4.3 Exposing attributes that do not directly map to accessibility API properties that AriaProperties is supposed to be used purely to expose unsupported semantics. I guess I would be curious why these properties are exposed in AriaProperties when there are UIAutomation mappings that described them just as well, but in any case it's probably best to just align with the with the UIAutomation documentation.

As an aside, I notice that there are a lot of properties in that link that seem to need AriaProperties exposure, but aren't documented in the Core-AAM as such. I guess that's an issue we can address separately.

Edit: Ahh, I see - this is the problem you brought up here.

[benbeaudry]

Your interpretation of it is not wrong. 4.3 specifically says

When WAI-ARIA roles, states and properties do not directly map to an accessibility API, and there is a mechanism in the API to expose the WAI-ARIA role, states, and properties and their values, user agents MUST expose the WAI-ARIA data using that mechanism as follows

and later says

User agents MUST also expose the entire role string through this mechanism and MAY also expose WAI-ARIA attributes and values through this mechanism even when there is a direct mapping to an accessibility API.

In this case, I believe the UIA documentation is more restrictive than the Core-AAM one, but both can be respected if we add AriaProperties on all aria attributes.

[sivakusayan]

Addressed comments - as you mentioned in the UIA aria-haspopup issue, there is a wider problem that a lot of mappings don't call out the need for UIA AriaProperties exposure, but I think it makes sense to address that in the generalized fix for #196. Let's individually call it out for aria-readonly here for now.

[benbeaudry]

LGTM! Thank you, Sayan.

[w3cbot]

spectranaut marked as non substantive for IPR from ash-nazg.

[spectranaut]

This is great, thanks :)

I opened a new issue for the lack of AriaProperties entries: #209