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.


  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.

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

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.

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



-Olli

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

Received on Wednesday, 13 October 2010 12:58:20 UTC