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

Thanks Patrick, Jon and Steve,
Your comments are all helpful and Patrick has given me an idea.
Jon, you asked for more examples. All our published accessible sims (about 5 or 6) and several of our works in progress can be accessed in the research section of the PhET website on the Accessible Simulations <https://phet.colorado.edu/en/accessibility/prototypes> page.

We have successfully implemented a grab, drag and release interaction in 2 simulations, Friction <https://phet.colorado.edu/en/simulation/friction> and Balloons and Static Electricity <https://phet.colorado.edu/en/simulation/balloons-and-static-electricity>  In these sims the native grab button launches a custom drag interaction that requires the role application. We found that screen reader users in particular had a lot of trouble deciphering a custom grab & drag interaction right on focus. The aria-roledescription attribute, though helpful, is still confusing for most users when provided right on focus. Splitting the interaction into a two-step process, a native grab button and then a custom drag interaction has proved to be much more accessible to screen reader users. We then made visual design additions to support the interaction for visual keyboard users. 

I am familiar with toggle buttons and pop-up buttons. These seem quite straight forward to me, and are indeed very handy. Both these types of buttons are actually used in all our accessible sims already because in the bottom navigation bar of each simulation there is almost always a global Mute Sound button that toggles sound on and off and small pop-up menu that leads to other PhET resources.

I am quite interested in the actual differences between a basic button that makes one thing happen, like our Reset All button that resets the sim to its original state and a button that continues to do something when held down, like the button that allows a user to squeeze liquid from an eye dropper.

Fom an accessibility perspective, I see the Reset All button as basic button element, different from the eye-dropper button, which I agree is a custom interaction requiring custom guidance.

I think we may just need to elegantly clarify our simple button category so that it doesn’t fire on hold.

Our accessibility team is not yet working on a sim that actually contains a fire-on-hold eye-dropper button, but thanks Patrick for your comments. You have given me an interesting code idea to run by our software developers. I had never thought of nesting a real button inside a div with role application. That will be interesting to try out as a potential solution for the eye-dropper scenario.

In terms of interaction challenges, we have many, especially in the categories of drag and drop, and buttons and switches. For example, for switches, the ARIA role=“switch” is nice, but not yet well-supported, and it would be nice to have both an On-Off switch and an A-B switch. Sure we could use radio buttons for an A-B switch, but I’m wondering if we can make something better.

I recently, saw that NVDA now supports aria-roledescription and this is very exciting for us.

Again, thanks for the feedback, 
Taliesin

I can also be contacted off-list at 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


  




> On Feb 25, 2019, at 4:49 PM, Patrick H. Lauke <redux@splintered.co.uk> wrote:
> 
> 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
>