Re: Agenda: DOM3 Events Telcon, 21 April 2010

On Oct 13, 2010, at 5:56 AM, Olli Pettay wrote:

> On 10/12/2010 11:12 PM, James Craig wrote:
> 
>> 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.

If it's really the case that this is a semantic 'scroll' event and not a 'mousewheel' event, then it's misnamed. I understand that it inherits from MouseEvent so that it can have x/y coordinates if necessary, but I think this will a significant amount of author confusion if this was triggered, say, from a keypress. See next comment.

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

Does the rest of the DOM group agree with you? If that were the case, this might work. 

Just to be clear, we would need the semantic event to fire *before* any discrete literal events (such as a keypress) so that the author could call preventDefault on the semantic event in order to cancel any subsequent events from the same user action. For example, if the user pressed the PageDown key, the WheelEvent would fire with a type of DOM_DELTA_PAGE and a deltaY of 1. 

Then, if the author called preventDefault on the event, the user agent would not send any events for keyup or keypress on that same keystroke. Are you sure the DOM group agrees with having WheelEvent prevent subsequent key events for the same user action?

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

Then again, I think it's misnamed.

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

Screen reader cursors can move to any element in the DOM at any time (even to elements that may not receive standard KB focus), and therefore needs to be separate from the standard focus and blur events.

Watch the video "VoiceOver in Action" to see an example.
http://www.apple.com/accessibility/voiceover/

> (2)
> Another question about AXDragDrop. Why is it needed? Why not just dispatch 'drop'?

I could be persuaded to remove the accessibility specific drag&drop events if HTML5's drag and drop implementation took accessibility into account. 

> (3)
> "interface Speech" This kind of thing will be designed in the HTML Speech group.

The HTML Speech group was not formed at the time I authored the proposal, but I would be happy if they would incorporate our pattern using window.navigator.accessibility.speech. 

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

From the proposal:

In certain cases, it is beneficial for web authors to be aware of the assistive technology in use. This section defines a collection of attributes that can be used to determine, from script, the kind of assistive technology in use, in order to be aware of considerations for a particular assistive technology, including the need to support the UI Change Request Events or Accessibility Events defined in previous sections. Web authors should always limit client detection to detecting known versions. Web authors should always assume future versions and unknown versions to be fully compliant.

> and cause security problems.

And again from the proposal:

User agents may return an empty string if the user has chosen to disallow sharing this information with the requesting domain.
Note: The authors recommend that user agents adopt a domain-level security policy for the ScreenReader interface that is similar to the security policy for location data or cookies. A user should be able to explicitly disallow sharing of this information altogether, or on a per-domain basis.

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


I think you now understand focusPosition from the follow-up discussion in this thread.

elementsChanged would be an explicit method authors could call when a node in the DOM has been updated. In theory, you're right, this should just happen automatically. In practice it doesn't always for performance reasons (Mutation events were deprecated for similar reasons). In the cases where UA or AT heuristics aren't perfect, this allows the author to *nudge* the UA and AT into doing the right thing.

pageChanged is a semantic event that is lacking in most modern web applications. Screen readers typically have special behavior that occurs after a full page refresh. pageChanged allows the author to notify the UA/AT that the web application view has *completely* changed. This would be nearly impossible for the UA/AT to do with heuristic methods alone.

James

Received on Wednesday, 13 October 2010 17:02:43 UTC