Aria-practices: Button Example: activation on key up

[ZoeBijl]

The button example has some code that only activates the controls on the keyup event.

A few issues with this:

• While this is common on Windows it’s not how it works on either macOS or Linux
• You can’t cancel the action by pressing another key
• This behaviour isn’t documented anywhere

Possible solutions:

• Document this behaviour
• Activate on keyDown and remove the additional code

What are your thoughts @smhigley @mcking65 @a11ydoer ?

[patrickhlauke]

You can’t cancel the action by pressing another key

You can't do that with native button elements either. (and just in case this is about SC 2.5.2 Pointer Cancellation, note that keyboard is not a pointer so this SC doesn't apply)

[JAWS-test]

I think that is correct in this way because it is only so conform with https://www.w3.org/TR/WCAG21/#pointer-cancellation Sorry, that was an imprudent and therefore wrong comment.

[patrickhlauke]

I think that is correct in this way because it is only so conform with https://www.w3.org/TR/WCAG21/#pointer-cancellation

2.5.2 does not apply to keyboard, as keyboard is not a pointer (mouse, touch, stylus, ...)

[patrickhlauke]

• While this is common on Windows it’s not how it works on either macOS or Linux

not tested linux, but on macOS, a real <button> fires on the keyup/when the key is released when using SPACE. and it fires on the keydown/when the key is pressed when using RETURN/ENTER. same is also true for windows. so this point is also contentious/wrong I think?

[patrickhlauke]

so, in all, i'd say the code should:

• fire for keyup when it's SPACE
• fire for keydown when it's RETURN/ENTER
• this should be documented, to say that this is best practice to match current common browser behavior

[ZoeBijl]

The difference between space and enter is already in the code. My pre coffee brain was testing native UI buttons rather than the button element. My post coffee brain has just verified Pat’s test results in latest Safari/Chrome on macOS 10.14.6.

So I think this issue is now about not having this behaviour documented.

---

Would be interested to know why this behaviour is implemented. As mentioned, native UI buttons don’t show this distinction on macOS.

[patrickhlauke]

Ah, good point re native UI vs web content. Incidentally, seems even on Windows some native UI buttons in the new-look Windows 10 dialogs trigger on the down as well, so even there it's not always the case.

Also confirmed that in Linux (well, Ubuntu/Firefox at least) <button> behaves as above with the difference between SPACE and ENTER/RETURN.

It might still be good to document somewhere that this is just to match how <button> behaves in most browsers/OSs though, just to avoid any future puzzlement...

[ZoeBijl]

Someone mentioned that you can, with space held, use the tab key to move away from the button. Effectively preventing the action you tried to trigger with space.

[sh0ji]

Related: #610

My rationale for including this was that HTML <button> elements include an affordance that allows the user to cancel their click, as you noted @ZoeBijl. This isn't something I've ever seen someone include in the wild on ARIA buttons (<div role="button" tabindex="0">) because it's more work than you'd expect.

I've yet to find where it's properly documented in HTML but it does seem to be consistent across browsers. Here are some clues in the specs:

• HTML Activation clearly separates click from activation behavior since different elements are activated through different means (e.g., links activate on Enter only, but not Space)
• UI Events click says that it should be dispatched "when the user presses down and releases the primary pointer button" and in a note further down says that "it can be considered a device-independent event type for element activation," meaning implementers shouldn't take the "pointer" part too strictly.

I'd be happy to write something up about this.

[ZoeBijl]

From UI Events §3.5. Activation triggers and behavior:

Relevant activation triggers for an <a> element are a click event on the text or image content of the <a> element, or a keydown event with a key attribute value of "Enter" key when the <a> element has focus.

---

And as far as WCAG §2.5.2 is concerned:

TL;DR: if space were considered a pointer and WCAG §2.5.2 did apply to it the example would still pass.

While I found it confusing that both WCAG and UI Events¹ seemingly have different definition of what a “pointer” is. WCAG’s definition points to the “pointer” definition found in the Pointer Events specification which reads:

pointer
A hardware agnostic representation of input devices that can target a specific coordinate (or set of coordinates) on a screen, such as a mouse, pen, or touch contact.

That does at least confirm that the spacebar on its own is not a pointer. I can’t click a specific coordinate with just my spacebar (without using something like Switch Control in macOS).

It’s worth noting though that the space key is identified as a primary pointer in UI Events. Namely, when you focus a button element and activate it with the space key the fired click event has a button value of 0. The button value as defined in UI Events §4.3.1.1. MouseEvent:

During mouse events caused by the depression or release of a mouse button, button MUST be used to indicate which pointer device button changed state.

The value of the button attribute MUST be as follows:

0 MUST indicate the primary button of the device (in general, the left button or the only button on single-button devices, used to activate a user interface control or select text) or the un-initialized value.

Not making this any easier to understand.

Anyhoo, the reason for activation on the up event is so we can cancel the action. That seems pretty straight forward. WCAG gives a way out in the form of an undo function (emphasis mine):

Abort or Undo
Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;

To apply that to the button code example: the mute button can be unmuted and the print dialog can be closed. Meaning that even if space were considered a pointer and WCAG §2.5.2 did apply to it the example would still pass.

1. There’s no definition for “pointer” in UI Events’ glossary.