914208 - expose keypress registered event handler to AT

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[alexander :surkov (:asurkov)]

it's part of bug 423409. I've got a request from AT vendor to expose this info. The example was dojo menu button ( http://download.dojotoolkit.org/release-1.9.1/dojo-release-1.9.1/dijit/tests/form/test_Button.html) which have registered click event handler (it opens menu) and key press event handler (it opens menu and selects the first item). They want to announce to the user that there's a key action so the user can guess what key should be pressed for the action and press it himself.

Since these are not real action (we don't have any idea how to invoke it, also see Jamie's bug 423409 comment #6) then the suggestion is expose 'onkeypress:true' object attribute on the accessible.

Sounds good?

Comment 1

[James Teh [:Jamie]]

I have no real problem with this implementation. That said, as I noted in bug 423409 comment 6:
> the fact that an object has a key listener probably isn't "visible" to most users anyway,
From what I've heard, actions related to mouse clicks are often visually (but usually inaccessibly) indicated somehow. However, I don't think the presence of a key press is ever visually indicated besides the type of the control. The example you give here is particularly weird for me because the control probably has a correct role, so the fact that it has a key press should be inherent in that.

Comment 2

[Bill Keese]

I think the wires are getting crossed here a bit.

My issue with http://download.dojotoolkit.org/release-1.9.1/dojo-release-1.9.1/dijit/tests/form/test_Button.html dealt with differentiating between when the user clicked the mouse, or pressed the SPACE key.   It sounds easy, but the problem is that JAWS intercepts keyboard events like SPACE/ENTER and sends "accessible click" events to the browser, simulating a mouse click.

Comment 3

[James Teh [:Jamie]]

(In reply to Bill Keese from comment #2)
> My issue... dealt with differentiating between when the user
> clicked the mouse, or pressed the SPACE key.   It sounds easy, but the
> problem is that JAWS intercepts keyboard events like SPACE/ENTER and sends
> "accessible click" events to the browser, simulating a mouse click.
Ah. Got it. The problem here is that users do need to understand their screen reader to some extent. For example, they understand that if they press quick navigation keys, they won't be passed through to the underlying control. The same should be true for space and enter. Allowing the screen reader to detect a key press event sounds like it might solve the problem, but it doesn't because:
1. The screen reader doesn't know which key, so in order for this to work in all cases, it must then pass *all* keys through to the control. If you do that, virtual cursor commands would stop working altogether, so the user would be "trapped" on that control.
2. Even if you could communicate which key, it creates inconsistency. The user expects certain keys to perform certain actions. If a control could override any key it liked, the user's expectation of what that key does (e.g. moving the virtual cursor) would be broken.

Space and enter are somewhat of a special case because these are known to be activation commands. One solution, then, could be to have an attribute which indicates that the control implements its own activation key presses. This way, ATs would know to pass space and enter (activation commands) straight to the control, rather than clicking. Perhaps aria-hasActivationKeys? :)

Comment 4

[Bill Keese]

> Space and enter are somewhat of a special case because these are known to be activation commands. One solution, then, could be to have an attribute which indicates that the control implements its own activation key presses.

Thanks, yes, that would definitely solve the problem, assuming you could get the JAWS guys to obey that attribute.

Alternately, on the Mozilla side, you could add a flag to the event object generated by the accessible click action, for example "evt._accessibleClickEvent".   I haven't looked at Mozilla's code though to see if that's even feasible.

For now I was able to differentiate between real mouse clicks and fake mouse clicks from keyboard events by checking if there was a mouseover event first.   I guess that's not a 100% reliable workaround, but better than nothing.

Comment 5

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #3)

> Space and enter are somewhat of a special case because these are known to be
> activation commands. One solution, then, could be to have an attribute which
> indicates that the control implements its own activation key presses. This
> way, ATs would know to pass space and enter (activation commands) straight
> to the control, rather than clicking. Perhaps aria-hasActivationKeys? :)

that probably nicer workaround than onkeypress object attribute and what's more appeal it doesn't need a fix on Firefox side.

(In reply to Bill Keese from comment #4)

> For now I was able to differentiate between real mouse clicks and fake mouse
> clicks from keyboard events by checking if there was a mouseover event
> first.   I guess that's not a 100% reliable workaround, but better than
> nothing.

as a pure Mozilla workaround you detect if click event is MOZ_SOURCE_UNKNOWN (http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/events/nsIDOMMouseEvent.idl#65)