Core-AAM state/prop change section needs rewrite

[cookiecrook]

I think Core-AAM 4.8.1 needs a rewrite.

User agents MUST notify assistive technology of state changes as defined in the table below, SHOULD notify assistive technology of property changes if the accessibility API defines a change event for the property, and SHOULD NOT notify assistive technology of property changes if the accessibility API does not define a change event for the property.

The main problems are with the final of the three requirements:

User Agents […] SHOULD NOT notify assistive technology of property changes if the accessibility API does not define a change event for the property.

1. Unlike the prior two, this use of "property" is ambiguous. Does it mean "attribute" here? If not, why is there not a similar requirement for "states"?
2. What is the goal of requiring that UAs not notify AT about changes unless there is a specific API for that property? Isn't that potentially harmful? For example, UAs remap ARIA all the time to things other than property-unique change events. It feels overly prescriptive to preclude UA engineers from finding another way to make it work. I think all UAs are ignoring this requirement, and following it would make the Web less accessible. Can it be removed entirely?

In addition to those, I have editorial concerns with RFC-2119 requirements being jammed together in a run-on sentence. If these were separated for example, it would leave room for explanatory notes about why state changes are a MUST but property changes are a SHOULD. I suspect that's a Windows-centric holdover from earlier days, but I'm not sure.

I mentioned earlier the first two are unambiguous because they are counterpart requirements for "states" and "properties." As such, those would be more clearly phrased if the distinctions were made at the beginning of the sentence, rather than in the middle. For example:

• When an ARIA State changes, User Agents MUST…
• When an ARIA Property changes, User Agents SHOULD…

Furthermore, all of these requirements are invalidated by a fourth that allows UAs MAY "trim" [sic] notifications that "ATs typically ignore."

For simplicity and performance the user agent MAY trim out change events for state or property changes that assistive technologies typically ignore, such as events that are happening in a window that does not currently have focus.

Though there is a single example, the "typical scenarios" are undefined and ambiguous, meaning none of these requirements are testable.