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

[Ojan Vafai]

Heh. There's clearly still a good deal of confusion about what the intended
behavior here is. Well, I'm confused anyways. :)

On Fri, Nov 5, 2010 at 9:32 PM, James Craig <jcraig at apple.com> wrote:

> Ojan Vafai wrote:
>
> How is [ DOMAttributeChangeRequestEvent ] any different than
> DOMAttrModified? The spec claims it doesn't have the problems that
> DOMAttrModified has, but I don't see how that's the case.
>
> DOMAttrModified is a notification, but DOMAttributeChangeRequestEvent is a
> request. The reason these all inherit from UIRequestEvent is because they
> are all requests, not notifications. For example, the following sequences
> may occur in a real user scenario.
>

I think this is the core of my confusion. In some cases I get that these
events are requests. In this case, it's a request to change an attribute.
But there are other cases where it seems like they have a default action.
For example, when the user scrolls, we fire a UISrollRequest and if the web
page does nothing, then the page scrolls, right? And if they user hits the
delete key, we fire a DeleteRequest and delete if the web page doesn't
cancel it. But then the AT software can also fire a DeleteRequest that does
nothing if the web page doesn't cancel it?

Am I misunderstanding? If the events are always requests with no default
action, calling these request events might make sense, but then it seems
that these would only be for AT software and should be named appropriately.

My first intuition is that we should not try to do AT specific events *if*
we can avoid it because web developers will largely ignore them, but I'd
like to understand the current proposal first.

*DOMAttrModified*
> "I took your dollar. By the way, my dad and granddad are probably gonna
> some cash from you, too."
>
> *DOMAttributeChangeRequestEvent*
> Path 1: "Can I have a dollar? No? Okay."
> Path 2: "Can I have a dollar? Yes? Sweet."
>

Heh. I see they these are different. DOMAttributeChangeRequestEvent is not
actually a notification that something changed or that something is about to
change?

On Fri, Nov 5, 2010 at 10:29 PM, James Craig <jcraig at apple.com> wrote:
>
> There are some cases where UIScrollRequests or UIValueChangeRequests might
> pile up. The spec should probably handle the case of key repeat; for
> example, what happens if an author has registered for UIScrollRequest and
> the user falls asleep on the PageDown key. We may want a way for the app to
> say "suppress this series of repeated request events."
>

Actually, I'm not sure we need to worry about this. For example, we don't
worry about this with keydown events. We'll just keep firing them until the
user wakes up. :)

Ojan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101110/b01939e1/attachment.html>