Re: IndieUI brainstorming

On Jan 7, 2013, at 11:48 PM, Dominic Mazzoni <dmazzoni@google.com> wrote:

> I spent some time reviewing the editor's draft, and I'm very happy and supportive of the general direction.
> 
> My only concern is that the set of events in this first draft might be a bit too limited. I tried to approach this methodically by going through all of the ARIA widget roles and considering which of the UI Request events might apply, and what might be missing. Here's what I found.
> 
> For a value change request on a slider or scroll bar, are "increment_max" and "decrement_max" supposed to be the same as "skip to start" and "skip to end", for example what might happen if you press Home or End? Also, I think it'd be useful to explicitly have equivalents to Page-Up and Page-Down - it often makes sense to scroll by one "page".

I was hoping to clarify that with the informative keyboard example here, that includes PageUp/PageDown, 
https://dvcs.w3.org/hg/IndieUI/raw-file/tip/src/indie-ui-events.html#UIValueChangeRequestEvents

PageUp would most likely send INCREMENT_LARGE.
PageDown would most likely send DECREMENT_LARGE.

> What if you have a listbox, grid, or tree? It's not clear to me which UI Request events you'd use to manipulate those controls. Value change doesn't really fit, and "Move" specifically talks about deltas in CSS coordinates, not discrete items. I'd like to see, at a minimum: next/previous and first/last for a list or tree, and up/down/left/right, and row-start/row-end/col-start/col-end for a grid.

I think those will more covered by the focus change events (for non-linear navigation) and markrequest for selection non covered by the default activation event, but neither of these are in the spec yet. We do have a few actions tracking them though.

https://www.w3.org/WAI/IndieUI/track/actions/13
https://www.w3.org/WAI/IndieUI/track/actions/14
https://www.w3.org/WAI/IndieUI/track/actions/15
https://www.w3.org/WAI/IndieUI/track/actions/25

> UI Request events like next/previous and first/last might also apply when you have a pop-up menu (combobox), radio button group, or tablist.
> 
> Finally, what if you have an editable text widget? The web is now full of text editors, code editors, word processors, and terminal emulators. Web authors currently have to listen for platform-specific keystrokes or gestures in order to implement things like moving by word or extending the selection by character, word, or line. How about an action representing a text cursor change request where the fields could indicate movement by character, word, or line - and a boolean field could indicate whether the cursor should move or the selection should be extended?

I think the custom RTE view problem is complex enough that it may require an API that is outside the scope of IndieUI 1.0. We currently have a custom text editing issue open for ARIA 2.0, but we haven't made much progress on it yet.

> My apologies if any of these suggestions are duplicates or inappropriate. I don't want to hold up this draft - I think the general direction is good and it makes sense to get the first draft out soon.

Not at all. Thanks for the feedback. Let me know if I can clarify anything else.

James

Received on Wednesday, 9 January 2013 02:39:12 UTC