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 09:58:45 AM:

> From: Olli Pettay <Olli.Pettay@helsinki.fi>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: Olli@pettay.fi, Cynthia Shelly <cyns@exchange.microsoft.com>,
> David Bolter <david.bolter@gmail.com>, Janina Sajka
> <janina@rednote.net>, James Craig <jcraig@apple.com>, "Gregory J.
> Rosmaita" <oedipus@hicom.net>, Olli.Pettay@gmail.com, Doug Schepers
> <schepers@w3.org>, Travis Leithead <Travis.Leithead@microsoft.com>,
> "www-dom@w3.org" <www-dom@w3.org>
> Date: 10/13/2010 10:07 AM
> Subject: Re: Agenda: DOM3 Events Telcon, 21 April 2010
>
> On 10/13/2010 04:57 PM, Richard Schwerdtfeger wrote:
> >
> >
> > 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
ofVoiceOver
> >  > > 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.
> Indeed. That is what wheel events are.
>
> > 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.
> Browser gets only some kind of "scroll this area" events which are then
> converted to 'wheel' event (or currently mousewheel or DOMMouseScroll
>   or MozPixelScroll, depending on the implementation).
>
>
> > A Device independent event passed to a list box would
> > leave the determination regarding the amount of scroll up to the UI
widget.
> Right. This can be done with 'wheel' event.
> Google Maps for example binds mousewheel/DOMMouseScroll to zoom-in/out.
>
> >
> > 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.
> I assume you mean something like (I know, my example is a bit ugly)
> <div style="overflow: auto;">
>    <span>line1</span><br>
>    <span>line2</span><br>
> </div>
> Then you could scroll one "span" at time using line scrolling, or
> the height of div using page scrolling.
>
Correct.

> > We would also want to apply this same strategy to the equivalent of
> > home, end, right, and left.
> This is something 'wheel' doesn't support currently, but we could just
> add a new delta mode, DOM_DELTA_MAX or something like that.
> Or one could page scroll with max/min size of long delta. That would
> effectively do the same thing.
>
yes.

> > 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.
> >
>
> I'm just trying to avoid having two almost similar events in the web
> platform. So, IMO, better to try to come up with a solution which
> works with non-a11y cases and with a11y.
> And as far as I see, 'wheel' is already quite close to that.
>
OK. Lets' talk about it on today's call.
>
> >  >
> >  > 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.
> Editor of which specification? HTML5?
yes.

> Do you have links to the relevant discussions?
>
Here is the tracker issue: http://www.w3.org/html/wg/tracker/issues/131


Regarding discussions, take your pick:
http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/

http://lists.w3.org/Archives/Public/public-canvas-api/2010JulSep/

http://lists.w3.org/Archives/Public/public-canvas-api/2010AprJun/



> > 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.
> Ah, SVG sounds like a very valid use case.
> (Though, one could support caret above svg the same way as with <canvas>
> - using invisible caret in some html element. But
> that is a bit hackish way to support all this.)
>
sure.

> >
> > 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.
> Sure.
>
>
>
> -Olli
>
> >
> >  >
> >  >
> >  > -Olli
> >  >
> >  > >
> >  > > We can discuss this more on the call tomorrow.
> >  > >
> >  > > Thanks,
> >  > > James
> >  > >
> >  >
> >
>