ISSUE-9: text editing events, potentially including rich text editing

[MichaelC]: relates to PFWG-ISSUE-92

[MichaelC]: relates to https://www.w3.org/WAI/PF/Group/track/issues/92

Rather than rich text editing (which is a big can of worms), I propose we only consider "cursor movement events" for now, and deal with the *rich* part later after rich text editing specs in ARIA and HTML5 are more mature.

In particular, I think that cursor movement events are useful for a wide range of apps, beyond those with rich text editors. Something as simple as a web form might listen for arrow keys in an attempt to move the user seamlessly between three fields of a U.S. phone number with area code, for example. In the spirit of Indie UI, we should make it possible to listen for higher-level events instead of arrow keys.

Note that these events differ depending on the native platform: on Mac OS X, for example, option-rightarrow moves to the end of the current word, while on Windows, control-rightarrow moves to the beginning of the next word. On mobile platforms, there might be gestures to control moving the cursor.

Perhaps these events could all be simply subtypes of a single "cursor movement" event.

* next character
* previous character
* beginning of current word
* end of current word
* beginning of next word
* end of previous word
* beginning of line
* end of line
* cursor up one line
* cursor down one line
* cursor up one page
* cursor down one page
* beginning of document/field
* end of document/field

Additionally, there should be a boolean field indicating whether this should extend a selection, corresponding to whether the shift key is held down.

I believe that this set of events would be sufficient for a web app to observe or intercept all cursor/selection movement within any editable text field, without ever listening to raw key events, and it would allow a mobile user agent to define alternative gestures to enable text editing that would work within any supported app.

Even if we don't go with the "rich" text editing, an API abstraction for document text contents and setting a selection range may be better here. If a UA/AT has to way for responses on all those events you listed, it will probably result in a severe lag when doing even the most basic text editing or even just text navigation.

Also the boolean you mention for shift selection is partially covered in markRequest. I think the current name is "fromLast" (open to other suggestions) for things like Shift+Click, and "retainMarks" for things like Option+Click (which, IIRC might be Shift+Alt+Click on Windows)

s/has to way for responses/has to *wait* for responses/

One more thing that appears to be lacking from the events above is how a user agent is supposed to determine where the current selection *is* on a custom textfield. IOW, even if these events were implemented, the caret position or selection may change, but the UA/AT would not know what to speak, b/c there is no interface to inspect the new selection after the change.

On standard edit fields like textarea and contenteditable, that inspection interface exists, but the events you propose are only necessary on custom edit fields where no such interface exists.