Re: Buttons: Why Space and Enter? Why different event listeners?

Hi Steve,
Apologies I didn’t respond to your questions.

We are using our custom architecture, a custom scene graph called Scenery (on GitHub here https://github.com/phetsims/scenery <https://github.com/phetsims/scenery>) which has a bunch h of its own buttons.

We are doing a lot of research and design on how to make our components (including all our special buttons) accessibility. We are finding issues/conflicts sometimes with the broader system when we make a component accessible. We want things to be accessible, and also elegant.

As for “dispatching” of events, I am not sure what exactly is dispatched, I am just referring to the default behavior of buttons. With Space key, activation happens on key up and with Enter it happens on keydown.

Interesting that the autorepeat behavior is a standard feature, but it seems to only be a standard feature for the Enter key, not the Space key. And our team has not found any documentation in the HTML or ARIA standard that explains the reason for the behavior, though you have explained an interesting difference for form submission in your point #1.

For working example of this difference between Space and Enter, please see the Mute button in aria practices example
here: https://www.w3.org/TR/wai-aria-practices/examples/button/button.html <https://www.w3.org/TR/wai-aria-practices/examples/button/button.html>

A developer I work with found that the Mute button was fixed after this bug report:
https://github.com/w3c/aria-practices/issues/610 <https://github.com/w3c/aria-practices/issues/610>

Taliesin  

> On Feb 25, 2019, at 11:55 AM, Steve Lee <stevelee@w3.org> wrote:
> 
> Taliesin
> 
> I'm can offer some hints.
> 
> 1) For buttons in a form context then Enter and Space do different things. Enter is the same as clicking on the form's Default button - normally Send. Thus it 'accepts' the form (also Esc acts as a cancel operation). Space effectively 'clicks' the control with focus, which is likely to be different. Try tabbing around the keys in a well coded form and using Enter and Space to see the difference. These are the usual key behaviours for accessibility but I think may be up to the User agent to assign.
> 
> I thought Space and Enter dispatch a click event on Keydown so I'm not sure why you see activation on Keyup. Are you using a framework that might change things?
> 
> 3) The autorepeat on key held down is a standard feature across all programs. In a browser, when any key is held down you get a sequence of Keydown Keypress events
> 
> I hope that helps
> 
> Steve
> 
> 1:
> 
> On 25/02/2019 08:25, Taliesin Smith wrote:
>> Hi Folks,
>> I work at PhET Interactive Simulations (PhET) at the University of Colorado Boulder. PhET makes highly interactive simulations for learning math and science. Our part of the team designs and implements the accessibility features for the simulations to make them accessible to more diverse students including students with vision impairments.
>> I have a couple of general question about making accessible buttons for interactive objects that are somewhat different from typical buttons one finds on web form.
>> 1. Is there a reason why buttons are operable via both the Space key and Enter key?
>> 2. Is there a reason why the event listeners are different for each key. For example, I think the Space key fires on keyup and the Enter key fires on key down and keeps firing if you keep holding it down.
>> 3. Is there a reason why when screen reader software is in use, the only events available for buttons is the click event?
>> I have read two informative articles: one on accessible buttons <https://www.deque.com/blog/accessible-aria-buttons/ <https://www.deque.com/blog/accessible-aria-buttons/>> by Paul J. Adams and one on the event listeners <https://unobfuscated.blogspot.com/2013/05/event-handlers-and-screen-readers.html?view=flipcard <https://unobfuscated.blogspot.com/2013/05/event-handlers-and-screen-readers.html?view=flipcard>> at the unobfuscated blog.
>> We need a few different types of buttons including a button that fires on hold. For example, a fire-on-hold button could simulate the squeezing of an eyedropper. As long as the button is held down it puts liquid into a beaker.
>> We want to use the native HTML5 button element whenever possible within our accessible sim architecture, and it would be good for our team to understand a bit more about why buttons operate they way they do, see questions 1, 2 and 3 above.
>> We are very familiar with the ARAI Authoring Practices, and we would like to understand a bit more about the history of the button interaction if anyone has time to share.
>> Taliesin
>> ~.~.~
>> Taliesin.Smith@colorado.edu <mailto:Taliesin.Smith@colorado.edu> <mailto:Taliesin.Smith@colorado.edu <mailto:Taliesin.Smith@colorado.edu>>
>> Inclusive Design Researcher
>> PhET Interactive Simulations
>> https://phet.colorado.edu/en/accessibility <https://phet.colorado.edu/en/accessibility>
>> Physics Department
>> University of Colorado, Boulder