[webkit-dev] W3C Proposal: User Interface Independence for Accessible Rich Internet Applications

[Ojan Vafai]

On Mon, Nov 1, 2010 at 1:03 PM, Chris Fleizach <cfleizach at apple.com> wrote:

> You reviewed- the first pass at an implementation of this proposal
>

Sorry for not responding sooner.


> https://bugs.webkit.org/show_bug.cgi?id=47301
>

> but haven't responded to this thread. Do you have any other objections.
>

Yes, but I don't know much about screen readers or ARIA, so I might just not
understand the proposal.


> On Oct 27, 2010, at 2:57 PM, James Craig wrote:
>
> James Craig responded:
>
> The main difference seems to be that our Undo and Redo *request* allows the
> web application to determine what (if anything) should be undone, or redone,
> where the HTML5 undo manager requires that the user agent make the change
> directly to the DOM or editable content. The UIRequestEvent interface allows
> the app to determine the outcome of the events based on the business logic
> of the app, which the browser does not know about.
>
> I don't really understand how putting "request" in the name of the event is
useful. There are plenty of existing events that "allows the app to
determine the outcome of the events based on the business logic of the app"
but aren't request events.

> The reason these are all called 'request' events is because they don't
> change anything. They only send a 'request' to the web application (not to
> the user agent) to make a change on the user's behalf. The web application
> can then intercept or ignore the event as needed. If ignored (if the web app
> hasn't registered that event listener, or if the event is not canceled with
> preventDefault) then the user agent or assistive technology can fall back to
> whatever behavior is deemed appropriate, including then using the HTML5 undo
> manager.
>
> Back to Tony's email:
>
> Ojan also proposed renaming the textInput event to just beforeInput because
> it seems like it can apply to more than just text (e.g., undo'ing the
> insertion of an image).  Do you think the use of textInput/beforeInput would
> meet the use cases needed by UIRequestEvent?
>
> In some cases, it may be appropriate, but my response to the previous
> question may provide additional understanding of why textInput/beforeInput
> is not sufficient, and why these two proposals are not mutually exclusive,
> even if they do overlap in some places.
>
> I still don't see why beforeInput would not be sufficient. It might be more
clear if you enumerated the list of things you expect to have
UIRequestEvents for.

> As I stated in the bug tracker comments, the W3C DOM and PF working groups
> discussed this, and the outcome was to work on a standalone specification as
> a joint effort of the two groups. The initial document editors will likely
> be Doug Schepers (W3C staff contact for www-dom) and me. From the
> teleconference discussions, these will be an add-on to DOM 3 Events and/or
> ARIA 1.0, because both of those documents are currently in Last Call. The
> only major change to the proposal so far that we're discussing a new method
> to the Event object (perhaps 'suppressEvents' or 'suppressRelatedEvents') so
> that we don't have to cancel the event by overloading the original use of
> the preventDefault method.
>
> What's the difference between preventDefault and suppressEvents?

Also, earlier in this thread, you said that you don't know of anything that
requires these events to be synchronous, but that seems to contradict
James's point above and the patch in question fires the events
synchronously. The spec text all also implies that the event fires, then
application has the chance to prevent it and then the action happens. So,
unless I'm misreading, the events need to be synchronous and fire before the
associated action occurs.

To be clear, my concern so far has just been about UIRequestEvent, which
seems to overlap 100% with beforeInput.

Some other concerns with the proposal:
-UIScrollRequestEvent: Don't we already have a scroll event? Can we just add
a scrollType property to it?
-UIValueChangeRequestEvent: This doesn't seem generic enough for the example
listed. For example, with a range widget, lets say the range is from 1-10
and the user tries to move it from 2 to 5. Is that an INCREMENT_SMALL or
INCRMENT_LARGE? If it's just INCREMENT, shouldn't there be some way to
communicate the amount it changed?
-DOMAttributeChangeRequestEvent: The spec text is pretty vague as to what
should and shouldn't fire this. With the spec text, without the
note/example, this event sounds a lot like DOMAttrModified and has all the
associated problems. There's a note that claims it doesn't have the same
problems, but I don't see how that's the case. I'd be happier with this if
it were explicitly about ARIA attributes, i.e. AriaChangeEvent.

Sorry again for not responding sooner.

Ojan

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101102/90fa7e07/attachment.html>