GNOME Bugzilla – Bug 658522
Bad tabbing order for Change Password in user accounts panel
Last modified: 2012-05-23 14:46:15 UTC
The user accounts panel has a password changing dialog. Pressing Tab from the New password field, after typing in that field, brings focus to a button for generating a random password. Users will expect the Confirm password field to be focused instead because it is naturally the next step after typing in the first password field. Adding to this issue, the dropdown is not particularly understandable when accessed through the keyboard; the only thing that really says what it does is a tooltip. A user could easily choose one of the options out of confusion, changing the new password he just entered.
Oops, two other notes. First, that other issue I mentioned is bug #633601, for reference. (https://bugzilla.gnome.org/show_bug.cgi?id=633601). Also, this was originally filed downstream at https://bugs.launchpad.net/gnome-control-center/+bug/821761.
commit 1ed6f51d8ef4081c7c463661357f4d5c8a9b10b3 Author: Bastien Nocera <hadess@hadess.net> Date: Fri Sep 9 09:57:35 2011 +0100 user-accounts: Correct initial focus in password dialogue The password dialogue needs to have the "Current password" field focused by default if we're changing the password.
Wrong bug. What do you think the ordering of the tab focus should be then? Where does the button fit in in the loop?
The button probably fits best before the first New password field, since that way it affects the field immediately after it in the tab order. Probably worth bringing up with the usability folks; I could easily be imagining this problem, and really I shouldn't have put it in the same bug report :) Thanks for the fix!
Right, I ran into that today, it seems to make little sense to have it between the password and confirmation because that matches no standard workflow (i.e you use the generator or type password but there is no case where you need the generator after having typed a manual password) - if it was before it would probably mean it's the recommended option (i.e that would get suggested before typing one manually) - if it's after it means that people who want to reach hit would need to skip the 2 password fields, which is easy enough
I've hit this too. I agree that the confirm should follow the initial in the tab order.
The button has been turned into an icon in the entry, so no longer a separate focus location. Problem solved. The generate password functionality is still keyboard accessible via the context menu.