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

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/> 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
> 
>

Received on Monday, 25 February 2019 10:55:34 UTC