Mutations and events

[marcoscaceres]

The spec defines:

          interface AccessibleInputEvent : Event {
          };

          interface AccessibleSetValueEvent : AccessibleInputEvent {
            attribute DOMString value;
          };

Firstly, it seems odd to just have AccessibleInputEvent as an abstract class with no attributes or methods?

Secondly, AccessibleSetValueEvent is a "mutation event", thus should be modeled in the same way as other mutations in the platform. Maybe we want mutation observers here?

[minorninth]

If we don't end up having any attributes or methods common to all accessibility input events, then

SetValue is a bit odd, I think it has more in common with an input event (like a keypress) than a mutation.

An input event is a user-initiated request to interact with the document. A click event on a button is a request to press it, a key press event in a text field is typically a request to add a character.

A mutation is the opposite direction - it's a notification to the developer that the DOM was changed in some way.

Accessibility input events are much more like click or key press events. Even SetValue is just a request - it's a request from some third-party client to set the value of a control to a particular string. Just like with other input events, it may not succeed, like if the control is disabled or if that value isn't legal. If it does succeed, it'd generate a mutation event that could be caught by the app.

Now, separately we may want some sort of analog to mutation observers for the AOM, but that's a separate issue.

[marcoscaceres]

Thanks for the clarification. I had trouble understanding the above in the current spec. It might be worth then revisiting that section of the spec to make sure it's more clear.