add blur and some more notes/questions

[cookiecrook]

From today's incubator call, we agree it'd be useful to outline the event object's properties here...

Feel free to edit this comment if you spot something wrong @alice.

contextmenu event: the related mouse events would need at least:

• .button: 2 (secondary click)
• .target/.srcElement: TBD... (likely element in AT focus or descendant element at/near the center of AT focus via mouse hit testing)
• Deprecated (Only synthesize these if the UA would send them normally.)
  • .which: 3 (legacy right-click)

Arrow key events (increment/decrement):

• .key: ArrowLeft/ArrowUp/ArrowRight/ArrowDown
• .code: ArrowLeft/ArrowUp/ArrowRight/ArrowDown
• .location: 0 (DOM_KEY_LOCATION_STANDARD)
• .target/.srcElement: same as document.activeElement (focused element or body)
• Deprecated (Only synthesize these if the UA would send them normally.)
  • .charCode: 0
  • .keyCode: 37/38/39/40
  • .keyIdentifier: Left/Up/Right/Down
  • .keyLocation: 0
  • .which: 37/38/39/40

Escape key event (dismiss):

• .key: Escape
• .code: Escape
• .location: 0 (DOM_KEY_LOCATION_STANDARD)
• .target/.srcElement: same as document.activeElement (focused element or body)
• Deprecated (Only synthesize these if the UA would send them normally.)
  • .charCode: 0
  • .keyCode: 27
  • .keyIdentifier: U+001B (Unicode Character 'ESCAPE')
  • .keyLocation: 0
  • .which: 27

Does focus need to synthesize related key events for Tab? If so, it would need to send keydown and blur on the previously focused element, then focus and keyup on the newly focused element. I'm leaning toward the extra key events being unnecessary since there are plenty of other ways an element can become focused.

Relevant Event obj props for those would be:

• .key: "Tab"
• .code: "Tab"
• .location: 0 (DOM_KEY_LOCATION_STANDARD)
• Deprecated (Only synthesize these if the UA would send them normally.)
  • .charCode: 0
  • .keyCode: 9
  • .keyIdentifier: "U+0009"
  • .keyLocation: 0
  • .which: 9

[cookiecrook]

Note: as discussed in the call, I'll remove blur fro the PR as that could potentially "out" AT users.

[cookiecrook]

Someone on the ARIA call this morning implied the pageup/pagedown key event might have a relevant gesture outside the example of scrolling.... I'm not sure what was mentioned, but I noted it here to review.

[cookiecrook]

@jnurthen mentioned scrollbar events might be complicated by scrolling direction, especially since the scrollbar thumb direction and the gesture direction is inconsistent between platforms, and allows further user customization in some contexts.

E.g. to "increment" a vertical scrollview, shouldn't ArrowDown/PageDown be synthesized rather than ArrowUp/PageUp as mentioned above? Perhaps arrows should be synthesized for scrollbars... Just pageup/pagedown? Even for horizontal scrollbars?

[cookiecrook]

Considering whether contextmenu should be triggered by "perform long press" (which defaults to 1-finger triple-tap) or "secondary activate" (which defaults to 1-finger quadruple tap). The platform long press behavior is commonly associated with a contextual menu on iOS, but the apps and frameworks handle AX's synthesized "long press" touch and determine what to do.

[cookiecrook]

@mcking65 mentioned progressbar should be cut. A media playback slider is still a slider, even if it progresses. I agree.

He also mentioned some interactive elements using the separator role may be relevant, like the separators that divide resizable panels in an app window.

[cookiecrook]

This sentence is unclear. "The DOM event target for click and contextmenu DOM events is lowest leaf node DOM element in the assistive technology's cursor or point-of-regard"

[cookiecrook]

Probably need to mention auxclick in contextmenu sequence?

[cookiecrook]

One more thing I missed during the call is that @sinabahram thought the contextmenu actions could be triggered as custom rotor actions, but I can't think how that would work today... Custom actions in native work because the app declares them, but in web the app just shows some new UI after intercepting and cancelling a contextmenu event. There isn't a Web API I know of to register something that could be used like a rotor action.

[kbabbitt]

RE: events associated with contextmenu, I did some testing on Windows. https://jsbin.com/zamodul/edit?html,output Same results in Edge and in Chrome with --enable-experimental-ui-automation.

• Right-click generates mousedown, mouseup, auxclick, contextmenu
• After tabbing to the button, pressing the "context menu" keyboard key generates keydown, keyup, contextmenu
  • But Shift+F10 generates keydown for the shift key, keydown for F10, then contextmenu (but no keyup)
• Using the Inspect tool to call UI Automation ShowContextMenu (which is what an AT would do) generates contextmenu only

[kbabbitt]

This sentence is unclear. "The DOM event target for click and contextmenu DOM events is lowest leaf node DOM element in the assistive technology's cursor or point-of-regard"

Thoughts on this: On Windows, when an AT wants to generate a click or contextmenu event, they do so by calling an interface method on an object representing the element. This is what the above sentence refers to as "cursor or point-of-regard" but it doesn't necessarily have to be e.g. what Narrator's blue box is around.

So to wordsmith a bit, maybe...

For click and contextmenu DOM events, the DOM event target is the lowest leaf node DOM element which is either the element on which the assistive technology requested the event, or a descendant of that element.

...modulo the discussion we had on the call around hit testing?

[sinabahram]

@cookiecrook I wasn't expecting this to be push, but rather pull. That is to say that I would expect the context menu option to always be available in the rotor, and when switched to, followed by a swipe down/up, then it is invoked. You could even put other things in that menu, much like you already do with edit and video transport and other similar menus that have sub-menu-options. Either way, though, I agree the rotor wouldn't be only populated upon availability, unless if Safari/VO were being quite clever. Hope that clarifies.

[cookiecrook]

I think I've addressed all the relevant, concrete feedback in the last commit. Unless someone spots a major problem, I'll merge this in soon and we can address additional feedback in new issues.