RE: Buttons: Why Space and Enter? Why different event listeners? (ARIA Authoring Practices)

Taliesin,

I suggest that you become more familiar with the ARIA authoring practices.
https://www.w3.org/TR/wai-aria-practices-1.1/

There is a section with examples on buttons:
https://www.w3.org/TR/wai-aria-practices-1.1/#button

The ARIA Authoring practices would also be very interested in learn the design issues you face for creating STEM content.
Can you send me some links to some of your online simulations?

Jon


From: Taliesin Smith <talilief@gmail.com>
Sent: Monday, February 25, 2019 2:26 AM
To: w3c WAI List <w3c-wai-ig@w3.org>
Subject: Buttons: Why Space and Enter? Why different event listeners?

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/> by Paul J. Adams and one on the event listeners<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>
Inclusive Design Researcher
PhET Interactive Simulations
https://phet.colorado.edu/en/accessibility
Physics Department
University of Colorado, Boulder