Button state should change with keyboard interaction

[jessegreenberg]

It would be great if button hover state changed with keyboard interaction. When focused, the button should look like it does when the mouse is over it. When the button is pressed it should look down.

This has been lower priority for a11y, but would be good to start investigating. Ideally, this will work when the screen reader is active.

Our limitation with screen readers is that while active, keydown and keyup events (which would be great to listen to for updating appearance and triggering buttons) never reach the browser. When user presses enter or spacebar to activate a button, screen reader will send a single click event to the button.

@zepumph and @mbarlow12 it would be great to brainstorm how this might work sometime soon, and how it could be integrated into the current sun implementation.

[jessegreenberg]

Our limitation with screen readers is that while active, keydown and keyup...never reach the browser.

Lets verify this and make sure we understand screen reader cases first.

[zepumph]

I ran into this today when implementing the home screen. It would be nice to have hover to that the small screen buttons light up even before click.

[jessegreenberg]

The current approach is problematic because buttons will fire continuously for as long as 'enter' key is held down (default click event behavior), which can be far too often. A solution for this issue could potentially fix this problem.

EDIT: noticed in phetsims/plinko-probability#104

[zepumph]

unassigning myself, let's hit this hard at a dev meeting discussion.

[jessegreenberg]

Also removing assignments, this is on our radar during dev-a11y meetings and we will revisit once we discuss there.

[jessegreenberg]

Assigning to myself and bumping priority because this needs to be addressed before publication of keyboard navigable rutherford-scattering and plinko-probability.

[jessegreenberg]

I added this in the above commit, and went with something similar to what @zepumph suggested in phetsims/scenery-phet#341 (comment) because of the a11y limitations mentioned in #323 (comment). @zepumph could you please review this commit? 8b6250c

[zepumph]

@jessegreenberg this looks really nice for click. I think it is a nice solution, but I am noticing that the approach is completely orthogonal to the PushButtonInteractionStateProperty type that seems to control this for clicking. Is this because we need more flexibility in some way?

I also want to note that this approach doesn't support hover. Although I don't think that there are problems with this approach in master right now (for plinko and rutherford), we should discuss this further. Marking for a11y meeting.

[zepumph]

@jessegreenberg @mbarlow12 and I added hover functionality to buttons today in the above commits. Closing

[jessegreenberg]

Reopening. The hover styling goes away after clicking a button with the keyboard. Also, if a button is focused with keyboard and then a mouse hovers over it, the "over" styling goes away until the button is clicked with a keyboard. @emily-phet is this a case we care about?

[jessegreenberg]

We discussed this in a11y meeting 7/3/18. We will want to consider these cases in the future, but this case is very low priority now. We will work on these cases when we consider mouse+keyboard interactions in general. Closing.