Re: Agenda: DOM3 Events Telcon, 21 April 2010

Rich Schwerdtfeger
CTO Accessibility Software Group

Olli Pettay <Olli.Pettay@helsinki.fi> wrote on 10/13/2010 07:56:10 AM:

> From: Olli Pettay <Olli.Pettay@helsinki.fi>
> To: James Craig <jcraig@apple.com>
> Cc: Doug Schepers <schepers@w3.org>, "www-dom@w3.org" <www-
> dom@w3.org>, Olli.Pettay@gmail.com, Travis Leithead
> <Travis.Leithead@microsoft.com>, Janina Sajka <janina@rednote.net>,
> Richard Schwerdtfeger/Austin/IBM@IBMUS, "Gregory J. Rosmaita"
> <oedipus@hicom.net>, David Bolter <david.bolter@gmail.com>, Cynthia
> Shelly <cyns@exchange.microsoft.com>
> Date: 10/13/2010 07:58 AM
> Subject: Re: Agenda: DOM3 Events Telcon, 21 April 2010
>
> On 10/12/2010 11:12 PM, James Craig wrote:
> > Hi Doug, I'd like to address the comments that this is partially
covered
> > by the HTML5 Undo Manager and WheelEvent. My comments inline below.
> >
> > Also, please familiarize yourself with the basic interface of VoiceOver
> > on iOS devices, because this will likely come up in the discussion.
> >
> > Direct link to a demo video (5 minutes, Quicktime MOV format)
> > http://movies.apple.com/media/us/iphone/2009/accessibility/apple-

> ed-accessibility-iphone_navigation-us-20090909_r640-9cie.mov
> >
> > Someone also reposted a lower-quality version on YouTube.
> > http://www.youtube.com/watch?v=WxQ2qKShvmc

> >
> >
> > On Oct 12, 2010, at 9:15 AM, Doug Schepers wrote:
> >
> >> Agenda:
> >> * discussion of UI Independence for ARIA proposal [1], ISSUE-135 (30
> >> minutes)
> >> * overview of UIScrollRequestEvent, UIValueChangeRequestEvent, and
> >> DOMAttributeChangeRequestEvent interfaces [2] (10 minutes)
> >
> >> [2]
> >> http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/

> UserInterfaceIndependence.html
> >
> > …snip…
> >
> >> We are inviting some of the WAI Protocols and Formats WG to discuss
> >> these issues with us. We have many issues to cover, so we will be
> >> adhering to a strict queue for this telcon.
> >>
> >> There are two separate proposals to add features to DOM3 Events to get
> >> editing actions, the UIRequestEvent Interface (with events like
> >> 'UndoRequest', 'RedoRequest', 'EscapeRequest', and 'DeleteRequest')
> >> [2], and the 'beforeInput' proposal [3], which have some overlap in
> >> intent and use cases.
> >>
> >> Note also that HTML5 defines editing actions and APIs [6],
> >> specifically the UndoManager interface [7].
> >
> >> [7] http://www.w3.org/TR/html5/dnd.html#undomanager

> >
> > 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.
> >
> > 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.
> >
> > I also believe that WheelEvent is an inappropriate alternative to our
> > UIScrollRequest proposal, because ours is a semantic request from the
> > user agent or assistive technology to the web application (which could
> > be triggered by any number of low-level physical events), whereas a
> > WheelEvent is a low-level physical event that is only appropriate to
> > trigger with a pointer scroll event.
> Why you think it is only appropriate to trigger 'wheel' using some kind
> of pointer scroll event?
> 'wheel' isn't bound to any particular device - that is one reason
> why the name isn't mousewheel.
>
Hi Olli,

One thing the device independent events are intended to do is support
direction from assistive technologies. The commands being generated are
logical scrolling commands and not low level device commands. For example,
if you had a list box, an up scroll might move one entry. What an up entry
would be depends on the type of UI widget you have. Scroll wheel is very
device specific and does not take into account the type of UI component. A
Device independent event passed to a list box would leave the determination
regarding the amount of scroll up to the UI widget.

So, imagine my creating a listbox out of <div>s and <span>s. The AT is does
not care about how big an open is in pixels within the listbox but an
application does. So, an up scroll could scroll the listbox the size of one
element.

We would also want to apply this same strategy to the equivalent of home,
end, right, and left. Now a wheel could easily support these limit type
commands but I think you have the general idea.

In this sense, a wheel event is very device dependent. This was the point I
was trying to convey to Doug at our last call regarding device
independence. If wheel could also be made to support these logical UI
Events then we could indeed use wheel although being a developer I might
not look a mouse wheel event for accessibility. This, I suspect, is why we
first overlooked wheel events on our first pass of DOM events.

>
>   For example, UIScrollRequest could
> > be triggered by any number of events, including AT API events,
> > mainstream UA keypress events (such as SpaceBar, PageDown, etc).
> It is IMO ok to trigger wheel in these cases.
>
See above.

> > Squeezing API or keyboard events into a physical MouseEvent designed
> > specifically for mouse wheels (even if it could be also be used for
> > physical trackpad events) seems like a bad idea.
>
> I see 'wheel' as a generic event, a bit the same was as what
> 'click' is.
>
See above.

> Few other comments:
>
> (1)
> May I ask why the need for AXFocus/AXBlur or AXFocusIn/BlurIn?
> In which case isn't focus/focusin or blur/blurin not enough?
> Or are you trying to capture caret movements? Then the event name
> shouldn't contain focus or blur, but should be something else.
>
> (2)
> Another question about AXDragDrop. Why is it needed? Why not just
> dispatch 'drop'?
>
> (3)
> "interface Speech" This kind of thing will be designed in the HTML
> Speech group.
>
> (4)
> Why the need for ScreenReaderID or MagnifierID?
> Yet another way to fingerprint user and/or write
> code which might break particular screenreader or magnifier
> and cause security problems.
>

For the discussion we were trying to limit this to device independent
events. I have privacy issues around the screen reader and magnifier ids.

> (5)
> I don't quite understand the need for focusPosition, elementsChanged or
> screenChanged. If the use case is that web page can update AT's cache or
> something, shouldn't that all just happen automatically like it
> happens know, AFAIK.
> Tough, for focusPosition I can see the use case for <canvas> based UIs.
> Having the method in window.navigator.accessibility.magnifier is quite
> strange. window.getSelection() might be better place, or
> perhaps <canvas> should have some method to indicate where the caret is
> when the element is focused.
>
We have been met with push back from the editor on having a caret API for
canvas. I am looking at binding getSelection to canvas but we need a method
to drive focus to the caret or selection point.  The value of having a DOM
based method for reporting caret API is we could use this for other
technologies like SVG and not just canvas.

I think for the purposes of this call we should focus on the device
independent events which is what we focused on for Monday's call.

>
>
> -Olli
>
> >
> > We can discuss this more on the call tomorrow.
> >
> > Thanks,
> > James
> >
>