1789875 - Recently closed tabs behave oddly when navigated with arrow keys rather than tab keys

Status: RESOLVED FIXED

(Firefox :: Firefox View, defect, P2)

Description

[Tim Giles [:tgiles]]

I'm sure there's context I'm missing here, but it appears we have some incorrect semantics for the markup of the recent closed tabs in the "recently-closed-tabs-list".
Feel free to call out any incorrect assumptions or gaps!

1. The "closed-tab-li" list items should have role="link" instead of role="button" since we are navigating the user away from the current location when one of the recently closed tab items is activated.
2. The whole item should probably be an <a> instead of a focusable <li>, which is why we needed custom styles for its focus state to get rid of the blue-on-white outline (Bug 1786397). I think I get why an <li> was chosen though, trying to get the entire item to be highlighted on hover

• If not the whole item, the link part should be an <a>, but that will change how the item gets focused and all that.

The current semantics are a bit confusing when using NVDA as well. Using tab to navigate each item works as expected but if you navigate via arrow keys, it's a bit odd (in my opinion). For example, if you recently closed wikipedia.org and went to your recently closed tabs list and focused the first item via tab, NVDA will announce the following:
"Recently closed region clickable list with 1 items Wikipedia, the free encyclopedia en.wikipedia.org Just now button Open https://en.wikipedia.org/wiki/Main_Page in a new tab" which is good.

However, if I have a list with more than one item, I should be able to use the arrow keys to navigate this list. What happens instead is this from NVDA:

• I press the down arrow, NVDA announces "button Wikipedia, the free encyclopedia"
• I press the down arrow again, NVDA announces "button en.wikipedia.org"
• I press the down arrow a third time, NVDA announces "button 4 min. ago"

This behavior doesn't seem correct to me. I'm guessing because the <li> has role button, that this is being inherited by the child elements of each <li> in this recently closed list and causing each child element to be read independently from each other and also as buttons. Fixing the role="button would remedy part of this issue, but maybe reading each child element independently is expected with elements that are nested in a <li>

Maybe this should be split into multiple bugs, but it seems like we can make this list a bit more clear with some modifications and reduce some tech debt at the same time. Again, feel free to call out any incorrect assumptions or gaps in my knowledge!

Comment 1

[:Gijs (he/him)]

Re: link vs button semantics: We had an extensive discussion about this already, several times. These don't really behave like links - they disappear from the list when clicked. They also correspond to more state than a URL (the restored tab has back/fwd history and so it's not just the URL that is being opened - see also e.g. bug 1789664). It doesn't really make sense to do some link-like things with them given that that is how they behave (if you right click and open in a new private window, does the item... stay in the list? Maybe not? How would the back/fwd history work? If you do this with something with sign-in state, it won't be signed in anymore, and might clobber history. Etc. etc.).

For now, we are content to have them be buttons in lists. The button does the "reopen this tab" action. It so happens that we show an icon, title and domain (!) for them, but that in itself doesn't make it a link. We can revisit in future but that depends on UX defining how the list should behave when doing other link-y things with them (and why it should be different from all the other recently closed tabs surfaces).

(In reply to Tim Giles [:tgiles] from comment #0)

Using tab to navigate each item works as expected but if you navigate via arrow keys, it's a bit odd (in my opinion). For example, if you recently closed wikipedia.org and went to your recently closed tabs list and focused the first item via tab, NVDA will announce the following:
"Recently closed region clickable list with 1 items Wikipedia, the free encyclopedia en.wikipedia.org Just now button Open https://en.wikipedia.org/wiki/Main_Page in a new tab" which is good.

However, if I have a list with more than one item, I should be able to use the arrow keys to navigate this list. What happens instead is this from NVDA:

• I press the down arrow, NVDA announces "button Wikipedia, the free encyclopedia"
• I press the down arrow again, NVDA announces "button en.wikipedia.org"
• I press the down arrow a third time, NVDA announces "button 4 min. ago"

This behavior doesn't seem correct to me. I'm guessing because the <li> has role button, that this is being inherited by the child elements of each <li> in this recently closed list and causing each child element to be read independently from each other and also as buttons. Fixing the role="button would remedy part of this issue, but maybe reading each child element independently is expected with elements that are nested in a <li>

This seems like an issue with how arrow key navigation was implemented, if it doesn't do the same as tab key navigation (which is what this is implying). I'll morph this bug for that purpose.

Comment 2

[Tim Giles [:tgiles]]

Thank you for the additional clarification Gijs! I knew I was missing something and I'm glad to hear there have been extensive conversations on the links vs button topic already. Morphing this bug into "fix the arrow key navigation on the recently closed tabs" seems like a good result to me.

Comment 3

[James Teh [:Jamie]]

As far as I can tell, Firefox View itself doesn't implement arrow key navigation at all. It is marked as a document, though, so NVDA uses its document browse mode for this page. That means that the arrow keys will move by line, and since the individual parts of the links/buttons are block elements, they are treated as separate lines. This isn't abnormal when browsing web documents and thus it's not a bug as such. It's also not new in Firefox: our New Tab page doesn't have proper keyboard navigation either.

That said, it's definitely not a particularly efficient experience neither for screen reader users nor sighted keyboard users, especially for something you want to be able to access quickly like tab pickup or recently closed. As a screen reader user, I probably wouldn't use this often for that reason. For sighted keyboard users, it's even worse because you'd have to tab through all the items in one section in order to get to the next section. To be a delightful, efficient experience, we'd ideally:

1. Provide a quick way to access Firefox View with the keyboard. Right now, I can only access it by pressing alt+d, shift+tabbing 5 times and pressing enter.
2. Implement proper list style keyboard navigation, where tab moves between lists and up/down arrows move between items.
3. Give it role="application" so that screen readers don't treat it as a web document and override the arrow keys, etc. It's important to note that this should not be done until we're certain the keyboard navigation experience is sufficient to access all content.

It's likely we can't realistically manage any of this in the time remaining for this release.

Comment 4

[James Teh [:Jamie]]

(In reply to James Teh [:Jamie] from comment #3)

1. Provide a quick way to access Firefox View with the keyboard. Right now, I can only access it by pressing alt+d, shift+tabbing 5 times and pressing enter.

My bad. Asa pointed out that it's in the Tools menu. I checked the View menu, but not the Tools menu. So, I can shorten this to alt+t f. I think it'd still be useful to have a direct keyboard shortcut for a convenience feature like this, but this is definitely a lot better than I thought.

Comment 5

[Tim Giles [:tgiles]]

Implement proper list style keyboard navigation, where tab moves between lists and up/down arrows move between items.

I'm looking into this and I'm already running into some issues. So controlling where the focus should go seems to be trickier than I expected, at least when dealing tab navigation. Currently I'm able to move focus from the tabs pickup container when Tab or Shift+Tab are used and move it to the next or previous "landmark" respectively. However, the focus is moving by itself after I have moved it in JS, I think due to this section in the FocusManager where MoveFocus determines the next element to move focus to. I believe this MoveFocus function is being called after I have called element.focus in JS, but I'm not 100% certain. So I'm not sure how to prevent the double movement of focus when using the Tab key to navigate in this situation. Do we have any examples of this styles of navigation implemented somewhere?

@Neil is there anyway to temporarily halt the FocusManager from processing Tab keypresses? I don't know if this is even a good idea or not, but I'd figured I'd ask. I don't know if there's an "easy" way to make a particular page behave like a desktop application, going back to the role=application bit that Jamie mentioned, again, figure I would ask.

Comment 6

[James Teh [:Jamie]]

I'd suggest using the roving tabindex pattern. Everything gets tabindex="-1" except the things you want to be tabbable at any particular point in time. For a first pass, you could make the first item in each list tabbable and everything else not. That would mean you'd lose your "spot" if you tab and then shift+tab, but I don't think that's a real problem given that we aren't really dealing with selection in multiple lists here.

Comment 7

[Neil Deakin]

I don't think you want to be adding any workarounds related to the focus manager.

Going from the behaviour I'm seeing, it looks like you're trying to reimplement what in our UI would be called a <richlistbox>, as the download manager uses. I think the currently implemented behaviour assumes that all the items in the list are focusable. Instead, the focus should stay on the list itself, and the individual items would not be focusable and are instead selectable via mouse and key navigation.

Comment 8

[Tim Giles [:tgiles]]

Attachment: Bug 1789875 - Add list style keyboard navigation to the recently closed list. r=sclements,ayeddi

Comment 9

[Tim Giles [:tgiles]]

Attachment: Bug 1789875 - Add list style keyboard navigation for synced tabs list. r=sclements,ayeddi

Depends on D158151

Comment 10

[Ray Fambro]

When a user selects a recently closed tab, we should move Firefox View's focus to the recently closed section title before the recently closed tab is restored. Per Jamie's call out, if there is an issue getting the screen reader to report the name of the region in this scenario, we may need to create a group.

I'm fine with just going with the first item in the list if this creates too much complication.

Comment 11

[James Teh [:Jamie]]

(In reply to Ray Fambro from comment #10)

When a user selects a recently closed tab, we should move Firefox View's focus to the recently closed section title before the recently closed tab is restored. Per Jamie's call out, if there is an issue getting the screen reader to report the name of the region in this scenario, we may need to create a group.

To clarify, what I meant was this:

1. Focusing the section title means a screen reader user has to tab once to get to the list.
2. If we instead focus the first item, the user won't have to press tab.
3. I think Josh's concern was that focusing the first item would mean that a screen reader wouldn't report the "Tab Pickup" title, hence the suggestion to focus the section title. However, Josh, please correct me if I misunderstood. Was there some other reason we felt it was better to focus the section title instead of the first item?
4. Because the section is a labelled region, NVDA at least will report the section title along with the first item when the first item gets focus.
5. I'm not sure about VoiceOver. It may need to be a group instead of a region to get VO to read the section title.

Comment 12

[Josh Berman]

My recommendation was like a 51 to 49 recommendation. I feel either solution is probably ok and would defer to you. My thought was because when you open a recently closed tab it gets removed from the list, it might be confusing if they select the first link in the list for example and come back to the page and land on what was before the second link but now the first. It would be good for the user to know that they are starting at the top of the list, and starting from the section header accomplishes that. I hear you're saying we can actually accomplish the same thing with NVDA starting at the top of the list and potentially with VO as well. I'm ok designing for NVDA also, as it's more commonly used on desktop than VO.

Comment 13

[Ray Fambro]

Downgrading priority. This issue isn't a must fix for 107.

Comment 14

[Ray Fambro]

Shifting back to a P2 so we can track this now for Fx108. Would like to address most a11y related bugs within this timeframe.

Comment 15

[Tim Giles [:tgiles]]

Attachment: Bug 1789875 - Allow restoring recently closed tabs with Space bar. r=sclements,ayeddi

Depends on D158152

Comment 16

[Tim Giles [:tgiles]]

Attachment: Bug 1789875 - Move recently closed keyboard test to separate file. r=sclements

Depends on D160538

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/76dd18a1f238
Add list style keyboard navigation to the recently closed list. r=sclements,ayeddi
https://hg.mozilla.org/integration/autoland/rev/2cd504af0ee3
Add list style keyboard navigation for synced tabs list. r=sclements,ayeddi
https://hg.mozilla.org/integration/autoland/rev/a108f88420ad
Allow restoring recently closed tabs with Space bar. r=sclements,ayeddi
https://hg.mozilla.org/integration/autoland/rev/49f0fd10685c
Move recently closed keyboard test to separate file. r=sclements

Comment 18

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/76dd18a1f238
https://hg.mozilla.org/mozilla-central/rev/2cd504af0ee3
https://hg.mozilla.org/mozilla-central/rev/a108f88420ad
https://hg.mozilla.org/mozilla-central/rev/49f0fd10685c