Handling Enter key presses on Buttons in JavaFX
peter.brunet at oracle.com
Wed Jun 8 19:44:46 UTC 2016
On 6/8/16 11:27 AM, Paul Furbacher wrote:
> On June 7, 2016 at 6:41:37 PM EDT, Tomas Mikula <tomas.mikula at gmail.com> wrote:
>> This would be very confusing if you had two TextFields and after entering
>> text into the first one the user hits Enter and the form gets submitted
>> with empty second field.
> Apple’s HIG documentation clarifies how such a situation should be handled: see https://goo.gl/AwhKiW.
> Quoting the relevant paragraph: "Don’t use a default button if you use the Return key in the dialog’s text fields. Having two behaviors for one key can confuse users and make the interface less predictable. Also, users might press Return one too many times and dismiss the dialog (and activate the default button) without meaning to.”
> Beyond that and in reference to the entire discussion, I would suggest that JavaFX follow the platform behavior as closely as possible. But in complex dialogs in which the user is presented with controls which respond to the “Enter/Return” key, it is probably up to the programmer to be aware of the guidelines, and make the necessary adjustment by making sure that none of the buttons in the button bar are set to “default button”.
> As noted, OS X configures the key press triggers for actions of the default (“Return”) and focused button (space) differently. Whether *all* users are aware of, or understand, this is probably not the point. For those who do know how Apple prescribes how dialog buttons should work, it has become ingrained behavior to hit the spacebar to fire the focused button. However, note that the ability to have a focused button other than the default depends on the user having activated “Full Keyboard Access — All controls” in the Accessibility preferences.
That's actually in the Keyboard preferences. You can get there from the
System Preferences or from the Accessibility preferences. I point that
out only to indicate that not only accessibility users use keyboard
navigation but also a certain set of visually enabled users, those who
find the UI faster to use with the keyboard only rather than the
keyboard and mouse.
I use this option because that's the what I am used to from Windows
where screen readers follow keyboard focus but on Mac even though that
mode is an option blind users typically use the VO Cursor, i.e. navigate
from control to control with control+option+arrow keys and that gets you
to a control no matter how the Full Keyboard Access option is set. (If
you want to experiment VO is enabled with command+F5.)
I also noticed today that when VO is activated the ““Full Keyboard
Access — Text boxes and lists only” setting is ignored and the user can
tab from control to control (and the focus box moves), so the Full
Keyboard Access setting is apparently for the sighted "power keyboard
user". In this scenario the Cancel (non-default) button can have focus
while the OK (default) button is still indicated (blue background) as
the default button.
> Only then can one can navigate through the dialog controls to focus a non-default button, such as “Don’t Save” in TextWrangler. My guess is that few Mac users, other than programmers, have enabled this functionality. (It may be too much to ask — or impossible — to have JavaFX respect the accessibility settings: that is, not allow tabbed navigation across the buttons if the “All controls” setting is not in force.)
> [I haven’t used Windows in a very long time, so I cannot comment on how it, across its many versions, prescribes how dialog buttons should work.]
More information about the openjfx-dev