Review UIA events for ARIA state/property changes

[joanmarie]

The following table reflects the event mapping currently in the Core AAM for UIA. I noticed some inconsistencies in how things are written and would like a review of the current values and corrections if needed.

State or Property	UIA event
aria-activedescendant	See Focus Changes
aria-busy	PropertyChangedEvent
aria-checked	ToggleStateProperty as part of toggle pattern
aria-current	PropertyChangedEvent
aria-disabled	No event
aria-describedby	PropertyChangeEvent
aria-dropeffect	No event
aria-expanded	expand/collapse pattern events
aria-grabbed	No event
aria-hidden	StructureChangedEvent
aria-invalid	No event
aria-label and aria-labelledby	PropertyChangeEvent
aria-pressed	No event
aria-readonly	No event
aria-required	No event
aria-selected	See Selection
aria-valuenow	ValueProperty property change as part of value pattern
aria-valuetext	No event

My questions:

1. Several of the ARIA state/properties are mapped to "PropertyChangedEvent". Should the specific property be included in the mapping? As an example from ATK/AT-SPI2: if aria-busy changes, the event is object:state-changed:busy but if aria-checked changes, the event is object:state-changed:checked.
2. aria-checked and aria-valuenow are written as $PROPERTY property change as part of $PATTERN pattern. Are these property change events the same thing as PropertyChangedEvent, but written differently? Or are they totally different API?
3. aria-expanded mentions "expand/collapse pattern events". Should we specify these by name/type?
4. Are all the "No event" instances correct?

[melanierichards]

@joanmarie well this seems to have been a very fruitful exercise. :)

I can submit a PR with updates for these questions, if that works?

Answers to questions:

1. Sure, I think we can add the specific property to the notes on these events. Probably best to keep the same style as state and property table, e.g. Property: AriaProperties, rather than give the full UIA property ID that's returned by the event handler (UIA_AriaPropertiesPropertyId).
2. Good catch, the correct event for "As part of __ pattern" would still be PropertyChangedEvent, the properties referenced in the Core-AAM mapping table are what get returned. "As part of __ pattern" is still noteworthy for these events, and should be kept.
3. Yep, this is just another PropertyChangedEvent, with a particular returned value for the expanded/collapsed state.
4. "No event" properties aria-disabled, aria-dropeffect, aria-grabbed, aria-invalid, aria-pressed, aria-readonly, aria-required, and aria-valuetext all fire PropertyChangedEvent.

Other changes:

• aria-activedescendent fires PropertyChangedEvent in addition to the focus event in the Focus table.
• aria-hidden fires PropertyChangedEvent, in addition to StructuredChangedEvent.
• In 5.8.3 Selection, Multiple selections table: ElementAddedToSelection or ElementRemovedFromSelection should fire from the item, not the current container.

[joanmarie]

@melanierichards:

I can submit a PR with updates for these questions, if that works?

That doesn't just "work"; it would be super awesome! :smile: Thanks!!

[joanmarie]

I merged the change into master. We'll want to add tests before we merge it into stable. So leaving this open for now.

Thanks for doing this @melanierichards!

[melanierichards]

Sure thing, thanks @joanmarie!

[jnurthen]

@joanmarie @spectranaut - trying to merge things. Does this have tests?

[spectranaut]

I added tests here: https://github.com/web-platform-tests/wpt/pull/34797

And since this was a change to reflect the implementation, it looks ready to move to stable!