Focus should remain on the selected login in the list until some other action (click or tab), which would then put focus on the Edit button in login-item.

This is actually a little more significant than just Edit getting focus. You can't see anything in the login-item without selecting it from the list -- but when the list has focus, it's not entirely clear visually.

The question is whether someone is selecting the list item to see it or to interact with it in more detail. That tabbing back to the list isn't readily apparent makes this, to me, worse.

(In reply to David Durst [:ddurst] from comment #1)

This is actually a little more significant than just Edit getting focus. You can't see anything in the login-item without selecting it from the list -- but when the list has focus, it's not entirely clear visually.

The question is whether someone is selecting the list item to see it or to interact with it in more detail. That tabbing back to the list isn't readily apparent makes this, to me, worse.

We are focusing the Edit button per the feedback in https://bugzilla.mozilla.org/show_bug.cgi?id=1560359#c0. We focused the Edit button instead of the Title since the title is non-interactive and focusing non-interactive elements isn't normal (https://phabricator.services.mozilla.com/D35828#1085745).

This is hard to argue with.

I think we have to punt on this for now and see if there are issues with it. Not normal could end up being more useful, but I'm curious if there will be a11y reports about it.

Mass removing [skyline] and [passwords:management] from about:logins bugs which are no longer useful.

UX recommendation (+based on conversation with accessibility team member) confirms original bug and expected results.
When selecting a login from this list with a keyboard or mouse we should not shift keyboard focus. Keep focus on the login in list itself.

(In reply to katieC from comment #5)

UX recommendation (+based on conversation with accessibility team member) confirms original bug and expected results.
When selecting a login from this list with a keyboard or mouse we should not shift keyboard focus. Keep focus on the login in list itself.

Jamie, I think this contradicts what you told Jared in Whistler… what do you think about this?

When you're using the arrow keys to choose a login, obviously we shouldn't move focus (and we don't). When you press enter, I still think it makes sense to focus something within the details area (as we do now), since otherwise, a screen reader user has no idea that anything actually happened. A user's attention should be drawn to the area of interest (the login details), since that's what they're interested in.

The conversation in the original patch (https://phabricator.services.mozilla.com/D35828#1085745) recommended putting the focus on something other than the Edit button, but Jaws' response indicates that this might not be possible. So we're left with one of two things:

1. focus on the the first focusable element, as it is now (the Edit button)
2. don't place focus in the <login-item>

The ideal resolution here to accommodate a11y is what's described in the original patch review. So unless someone knows how to resolve the issue described at https://phabricator.services.mozilla.com/D35828#1089220, this will be resolved WONTFIX.

OK, so what's the actual problem now? If focusing the edit button, after pressing Enter or clicking an item to select it, visually this should be clear that the focus is now in the login item that just appeared. From a screen reader perspective, the only thing above the login item (prior DOM element) is the heading that repeats the title of the login item I just selected. Everything else follows the Edit button in the DOM order, like the URL, user name and concealed password plus checkbox to reveal it. A keyboard user would also be focused on the Edit button for the login item. And the fields below are read-only, but focusable, which means they can be tabbed to and the text selected and copied.

I fail to see what the actual problem is with the current implementation.

(In reply to Marco Zehe (:MarcoZ) from comment #9)

OK, so what's the actual problem now? If focusing the edit button, after pressing Enter or clicking an item to select it, visually this should be clear that the focus is now in the login item that just appeared.

I believe UX doesn't like seeing the visual focus outline on the edit button when a mouse user clicks an item to select it. I'm not sure if that is the extent of the problem though.

Bug 1579739 (missing multi-selection/-deletion) is an example why focusing another element on click is a bad idea.

There are well-established patterns for user interaction with lists.
One is quick browsing via the keyboard. This is very cumbersome right now.
Scenario:

1. type "faceb" in the search field
2. press Enter key -> focus stays in search field
3. press Tab four times -> finally, the list gets keyboard focus, although that very hard to see
4. press Down Arrow -> next list item gets selected, but information on the right does not get updated
5. press Space or Enter -> finally, the info area gets updated, but focus gets stolen (this bug)
6. press Shift+Tab twice to get back to the list

Expected:
@2. focus should go to list
@3. <eliminated>
@4. right pane should always show the list item that has keyboard focus (mostly eliminates need for 5. and 6.)
@5. it's acceptable that Space and Enter put focus on the edit button. However, putting focus on the "Show Password" button would probably better cover the 90% use case

Comment 11 sounds like a good UX to me, both from a keyboard perspective and a screen reader perspective. However, I don't think it solves bug 1579739 from a mouse perspective.

One possibility is that enter focuses something inside the login area, but clicking does not. That does make the UX different for mouse and keyboard users, but the focus shift is more important for keyboard users anyway; mouse users are going to end up having to click to activate regardless.

Agree with Jamie on all counts, including the distinction whether something got selected with the mouse rather than the keyboard. Besides, the UX will be similar in that selecting will already bring up the login details, only the extra pressof Space/Enter on the list item will shift focus. So that's an action a mouse user won't perform normally anyway. These sound like actionable items to me. :)

The behavior should not differ between mouse clicks and selection via keyboard:

• For users who exclusively use the mouse, putting the focus on an other button is irrelevant.
• For users who use all available input methods, putting the focus on an other element on click violates basic UX expectations.

Whenever you start thinking about inventing new UI metaphors, take a step back and check if the problem at hand is really a completely new situation that needs a design from scratch. A list of entries + a details view for a selected entry is definitely not something new.

BTW: An even simpler solution would be a table with direct edit functionality ... didn't I see that somewhere, recently? 😏

I think we have to punt on this for now and see if there are issues with it. Not normal could end up being more useful, but I'm curious if there will be a11y reports about it.

Hi everyone

Errors 404