Re: Comments: User Interface Independence for accessible Rich Internet Applications

On Aug 8, 2012, at 10:30 PM, Jason White <jason@jasonjgw.net> wrote:

> This submission, which antedates current work, suggests interfaces pertinent to
> both IndieUI Events and User Contexts. Some aspects of the proposal are beyond
> the scope of this working group, for instance the functions to access an
> assistive technology cursor and to create speech output.
> 
> My initial comments concern the event-related aspect of the proposal. The
> details of interfaces and event types will be developed in due course in
> response to use cases. There are, however, wider issues to consider as well.
> 
> The proposal establishes the following behaviour for events that it defines:
> 
> 1. An abstract user interface event is dispatched and may be handled by
> registered listeners.
> 
> 2. If it handles an abstract event successfully, the Web application calls
> preventDefault() to suppress the default action.
> 
> 3. Otherwise, the user-agent may dispatch the underlying device-specific
> events (e.g., keyboard events).
> 
> Effectively, the Web application only receives the underlying device-specific
> events if the associated abstract events are not cancelled and the UA happens
> to forward the device-specific events.

This was the original intention, but this might not be feasible because this seems to indicate a blocking operation between the rendering engine and the UI. WebKit2, used in both Safari and Chrome, operates in a separate process (or processes) from the containing application, so that hung or crashing web pages will not prevent the user from accessing the application interface like chrome, toolbars, menus, etc. Other engines may implement a similar approach.

> The following alternative design would be more consistent with the DOM Level 3
> Events specification, for example the relationship between mouseup, mousedown
> and click events.
> 
> 1. The UA assigns default actions to certain device-specific UI events and
> event sequences; these actions dispatch the associated abstract events.
> 
> 2. Consequently, the Web application receives both the device-specific events
> corresponding to a user's interaction and the abstract events defined in
> IndieUI events.

I agree this is the better approach, due to the reason mentioned above.

> 3. If a device-specific event is cancelled, then (per DOM Level 3 Events), the
> default action, namely the dispatching of the associated abstract event, is not
> performed.
> 
> 4. If there is no device-specific event defined in the user-agent's API
> corresponding to a user's input (for instance, no event associated with speech
> input), then only the abstract event is dispatched.
> 
> There are trade-offs to be made in both designs, and these alternatives are
> not exhausive. My purpose is merely to place the issues before the working
> group.
> 
> I found it helpful in reviewing the submission that specific interfaces have
> been put forward in the proposal. These will contribute to our work,
> especially in connection with events.
> 
>

Received on Friday, 10 August 2012 21:43:22 UTC