747978 - Inconsistent behavior in the Browser ID account manager when using the keyboard

Status: RESOLVED FIXED

(Mozilla Labs :: Identity, defect)

Description

[Marco Zehe (:MarcoZ)]

Prerequisite if you're on a Mac: Go to System Preferences, Keyboard, and check that "Tab key moves to" is set to "all focusable controls". Firefox honors this setting, and it is important for the following STR. Windows and Linux do this right by default.

STR:
1. Go to http://browserid.org and sign in.
2. Put your mouse away.
3. Press the tab key to move through the account manager page. Stop when you reach the "Edit" button next to "Your e-mail addresses".
4. Press Tab once more.

Expected: Focus should move to the next "edit" button, since prior to that, no other visual element is focusable.
Actual: The "Remove" button next to the first registered e-mail address pops out of nowhere.

5. Press tab again.

Result: The same happens to any further "Remove" button.

Note that all the while, the "Edit" button above has never been pressed, it is always on "Edit", its caption did not change to "Done".

We now have the situation where you can interact with any "Remove" button you have made visible by tabbing, without having to press the "Edit" button first.
A mouse user MUST press the "Edit" button first to make the buttons for removal visible.

6. The same is true for the fields to change the password. They become visible and stay visible without the "Edit" button being pressed once you tab to them once.

The problem here is the difference in workflows, and the confusing fact that the "Edit" and subsequent "Done" buttons don't seem to actually do anything useful.

The same visibility happens once I navigate through the page using the NVDA virtual cursor. It focuses the buttons, since they are in the DOM, just moved outside the view port, and if I traverse over them backwards, they magically disappear again. But I can interact with them without having ever pressed the "Edit" button. So for me, it looks like the "Edit" button actually doesn't do anything, but is rather a confusing UI element.

Suggestion: To be absolutely consistent, the elements should be hidden via styling them as display: none; or visibility: hidden; not by moving them to some negative position. display: none; and visibility: hidden; actually cause these elements to not show up in the tab order and for screen readers. So one has to press the "edit" button in every case tomake these elements visible.

Alternatively, do away with that Edit button alltogether and just display all the options by default. But please make it a consistent user experience for everyone!

Comment 1

[Austin King [:ozten]]

Filed at https://github.com/mozilla/browserid/issues/3992 which will get more attention.

Comment 2

[François Marier [:francois]]

Closing the bugzilla bug in favour of the one that Austin opened on our main tracker.