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

On 25/02/2019 08:25, Taliesin Smith wrote:
> 1. Is there a reason why buttons are operable via both the Space key and 
> Enter key?

That's how browsers have treated native <button>s forever. Admit that 
I'm not quite sure about the reasoning for it.

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

If you're dealing with regular native <button> elements, it's sufficient 
to just use the "click" event listener. The browser will fire the event 
when appropriate, regardless of whether Space or Enter are used.

By default it's true that the actual behavior in browsers is: Enter 
fires the click event on the "down", while Space fires the click event 
on the "up".

But if you use <button> and just register a "click" event handler, this 
is all sorted out for you transparently.

IF, however, you're making a button out of a custom element (e.g. a 
link, or a focusable <span tabindex="0">, or whatever), you can't just 
rely on registering the "click" event. For links, it would only fire for 
Enter. For normally static/non-interactive elements, it wouldn't fire at 
all. That's when you may need to register keyboard events specifically 
(in addition to click handlers to make them mouse operable, of course). 
And THEN, if you want to replicate the same behaviour as native 
<button>s, you will likely want to differentiate keydown and keyup, so 
really mimic the native behaviour.

> 3. Is there a reason why when screen reader software is in use, the only 
> events available for buttons is the click event?

Desktop screen readers are controlled using the keyboard (and/or swipes, 
on a desktop/laptop with touchscreen). Keyboard interactions are 
therefore intercepted first by the screen reader (with minor differences 
here between Windows and macOS), and then "translated" into relevant 
interactions on the actual page. When you're on a button (be it a real 
<button> or a faked one) and you press Enter or Space, the keyup/keydown 
events aren't fired (they're swallowed by the screen reader), and 
instead the click handler on the button is activated. As your control is 
likely to have a "click" handler as well (to make it work with a 
mouse?), this is usually not a problem.

[...]

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

Note first of all that this is a non-standard behaviour for web 
content/form controls.

With that said, yes this is where you likely want to use a keydown 
listener, and carry on "squeezing the eyedropper" until the related 
keyup event is fired. But note that this may not be the best 
approach/feasible to do for certain users.

Related to the above about screen readers "swallowing" keyup/keydown 
events, on Windows anyway, you're likely - if you want to replicate the 
same behaviour for screen reader users - wanting to put a 
role="application" around this non-standard button. This generally 
disables most of the AT's keyboard "swallowing", meaning that 
keyup/keydown/etc will transparently pass through to the page's 
JavaScript the same way as when no screen reader is running. Of course, 
you'd still need to provide some kind of non-visual feedback that 
keeping the button pressed is having some kind of effect...

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

Also noting again that as this is a non-standard type of control (which 
doesn't have an equivalent in standard native desktop apps either), 
there's no relevant ARIA pattern for the sort of thing you're doing.

P
-- 
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Monday, 25 February 2019 15:50:29 UTC