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 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.
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.

> 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.

> 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.


>  >
>  > 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?
Do you have links to the relevant discussions?

> 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.)

>
> 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
>  > >
>  >
>

Received on Wednesday, 13 October 2010 15:00:44 UTC