WICG
Ambiguity of which key events to synthesize
(Jury is still out for me on whether synthesizing key events is okay at all, but if this ends up the path forward…)
Which keys to synthesize may be ambiguous.
For example, the slider case. The recommendation for ARIA sliders de facto keyboard handling is for authors to capture both orientations: Left or Down for decrement, Right or Up for increment. Whichever the user thinks to use just works.
If its a vertical slider explicitly (e.g. aria-orientation attr) or implicitly (90° transform, etc.). Does that change the keypress events the user agent is supposed to sprinkle in along with the increment/decrement input events? Might an LTR layout (Arabic, Hebrew, etc.) also change the key events that were sent?
A sighted keyboard user will infer the "correct" orientation. A blind screenreader+keyboard user may also infer the correct orientation (if the control uses aria-orientation) and press the keys intuitively (L/R for horizontal; Up/Down for vertical). However, to an AT synthesizing these keys, it may not be clear which to send, and it does not make sense to send both.
I think it could also be confusing if the wrong set of keys was captured/canceled unexpectedly. If a user used up/down arrows to scroll the page, then tabbed to a slider, are the up/down arrows now implicitly captured, canceled, and sent as key/increment events? It could stop the page from scrolling even when the user would expect only left/right would be applicable to the horizontal slider.
What is the logic for determining when to send an increment or decrement event when/if the page author has not registered for key events on the element? They recommended way to do this now is to:
- capture the keydown event
- cancel it if the event target is the slider or a descendant of the slider (so Safari does not scroll)
- capture the keyup to perform the desired action.
If an author registered for an input or beforeinput event (in order to capture increment or some other input event), but has not registered for keydown/keyup/keypress events, is there a scenario where the physical arrow key events would not bubble up through the page to the browser? Presumably cancelling increment input would prevent the subsequent keyup event from firing, but that would not prevent keydown from scrolling the page in Safari. Does this mean that Safari's native down-arrow-key scrolling functionality would break if an author registered for any input event?
If so, it'd have to be limited to very explicit cases like:
- element is both focusable and currently focused
- author registered for input event on the focused node or a delegate ancestor (how would this work with delegation? I tried to solve that problem in the now-defunct IndieUI with the
uiactionsattr) - per role, the keys may be limited to even more specific cases.
- only Left/Right keys are captured on horizontal range widgets
- only Up/Down keys are captured on vertical range widgets
For scroll views, the explainer lists PageUp/PageDown as triggers for scrollPageUp and scrollPageDown event types, but what about horizontal scrolling? Is there a standard key equivalent for horizontal scrolling? We could re-use PageUp/PageDown for single axis horizontal scroll views, but what about views that support both vertical and horizontal scrolling?
James and I had a brief discussion about this now. Here are some responses based on what we talked about.
Which keys to synthesize may be ambiguous.
For example, the slider case. The recommendation for ARIA sliders de facto keyboard handling is for authors to capture both orientations: Left or Down for decrement, Right or Up for increment. Whichever the user thinks to use just works.
If its a vertical slider explicitly (e.g. aria-orientation attr) or implicitly (90° transform, etc.). Does that change the keypress events the user agent is supposed to sprinkle in along with the increment/decrement input events? Might an LTR layout (Arabic, Hebrew, etc.) also change the key events that were sent?
I think if the orientation is vertical, we should send up/down, and we should make that required in the spec. I also think that the author recommendations should be to accept both left/up for decement and right/down for increment.
RTL support sounds like a gap in ARIA. There should be a way to specify when a slider is inverted and the minimum value is on the right and the maximum is on the left. Still, this doesn't seem like a huge issue because worst case it just moves the wrong direction and the user quickly adapts.
A sighted keyboard user will infer the "correct" orientation. A blind screenreader+keyboard user may also infer the correct orientation (if the control uses aria-orientation) and press the keys intuitively (L/R for horizontal; Up/Down for vertical). However, to an AT synthesizing these keys, it may not be clear which to send, and it does not make sense to send both.
I think the spec should be clear - probably based on the computed orientation - but it seems relatively harmless if it gets it wrong.
I think it could also be confusing if the wrong set of keys was captured/canceled unexpectedly. If a user used up/down arrows to scroll the page, then tabbed to a slider, are the up/down arrows now implicitly captured, canceled, and sent as key/increment events? It could stop the page from scrolling even when the user would expect only left/right would be applicable to the horizontal slider.
It's not clear to me how this spec changes anything.
If the web author handled keyboard events before, they already needed to deal with this issue.
If somebody's using AT, the AT often knows the intent and can distinguish between increment vs scroll down - and in the case the user wants scroll down it could choose a different event target.
What is the logic for determining when to send an increment or decrement event when/if the page author has not registered for key events on the element? They recommended way to do this now is to:
capture the keydown event cancel it if the event target is the slider or a descendant of the slider (so Safari does not scroll) capture the keyup to perform the desired action. If an author registered for an input or beforeinput event (in order to capture increment or some other input event), but has not registered for keydown/keyup/keypress events, is there a scenario where the physical arrow key events would not bubble up through the page to the browser? Presumably cancelling increment input would prevent the subsequent keyup event from firing, but that would not prevent keydown from scrolling the page in Safari. Does this mean that Safari's native down-arrow-key scrolling functionality would break if an author registered for any input event?
I agree it could break while you're focused on a slider, but wouldn't the app have had similar challenges with keyboard accessibility either way? We're not proposing anything different, it's still up to the web app what to do.
Also, as I mentioned above, the AT always has the option of targeting a different element with its scroll event.
If so, it'd have to be limited to very explicit cases like:
element is both focusable and currently focused author registered for input event on the focused node or a delegate ancestor (how would this work with delegation? I tried to solve that problem in the now-defunct IndieUI with the uiactions attr) per role, the keys may be limited to even more specific cases. only Left/Right keys are captured on horizontal range widgets only Up/Down keys are captured on vertical range widgets For scroll views, the explainer lists PageUp/PageDown as triggers for scrollPageUp and scrollPageDown event types, but what about horizontal scrolling? Is there a standard key equivalent for horizontal scrolling? We could re-use PageUp/PageDown for single axis horizontal scroll views, but what about views that support both vertical and horizontal scrolling?
I don't think we'd be able to support scrolling by page when a view has both vertical and horizontal scrolling, unfortunately.
Not sure how often that matters. Does Excel or Numbers have a way to scroll to the right by one page?
Maps usually have custom scroll views that allow panning/paging in multiple orientations.
PR #162 to the explainer outlines the key presses from APG that are associated with equivalent AT actions... It's a limited set now (increment., decrement, dismiss) because the others are either more ambiguous (no de facto keyboard shortcut) or have no equivalent DOM event (scrollToVisible, Pan, setValue, etc.).