This bug tracks work to be done on top of the Downloads Panel in bug 726444. * Allow cycling through the "show download history" entry using the arrows. * Focus usually returns to where one was before download manager when pressing Escape. However, if nothing was focused when DM was invoked, focus should be set explicitly to the document, so that it doesn't get into a limbo state. * The option to open the file in focus, available using the ENTER key, is not announced. Understand how to address this when using screen readers.

One thing I've noticed on the keyboard interaction side, if I open the download panel (from clicking the download button or using Ctrl-J), the "Show all downloads" part of the panel has the "S" underlined for a keyboard shortcut. But it won't do anything until you click somewhere inside the panel to give the panel content focus. (To do this without accidentally activating the link in the panel, click-and-hold over the "Show all downloads" part and drag up past the upper edge of the panel, then release the mouse button. This works for me on Windows, not sure about other platforms.)

Shouldn't this have been a "tracked" bug way back in February? It's rather unfortunate to ship with an accessibility regression like this.

(In reply to Henri Sivonen (:hsivonen) from comment #2) > Shouldn't this have been a "tracked" bug way back in February? It's rather > unfortunate to ship with an accessibility regression like this. The feature is disabled by default in all channels except Nightly, thus for now we're only using track flags to ensure the feature is actually disabled and we have no regressions while disabled. To track things we need to fix before shipping, we're using bug 747422, and not the tracking flags, because we don't know in which release the panel will be ready to be enabled for everyone.

Should the issues in comment 0 be broken down into individual bugs blocking bug 747422?

(In reply to Mike Conley (:mconley) from comment #4) > Should the issues in comment 0 be broken down into individual bugs blocking > bug 747422? yes that'd be good, likely once those are fixed we also need sort of a review from accessibility on the interaction.

Actually, considered we changed Downloads to open the DM and not the panel, exactly to help blind users accessibility, could make the latter issue not even a blocker. The panel is mostly considered a mouse target at this point, even if common keyboard access would still be welcome as it is for any other widget in the toolbar.

* Focus usually returns to where one was before download manager when pressing Escape. However, if nothing was focused when DM was invoked, focus should be set explicitly to the document, so that it doesn't get into a limbo state. What does limbo state mean? which part of the code this affects? If nothing was focused what's wrong to go back to the same state? How do we open the panel without focusing? I basically filed all the other bugs reported here but this one, Paolo could you please do that?

(In reply to Marco Bonardo [:mak] from comment #7) > * Focus usually returns to where one was before download manager when > pressing Escape. However, if nothing was focused when DM was invoked, focus > should be set explicitly to the document, so that it doesn't get into a > limbo state. This was in turn copied from bug 564934 comment 366, I'm redirecting the information request to Marco Zehe. Marco, do you know if the "limbo state" you mention still affects the version of the panel that is currently in Nightly? And I quote Marco's comments: What does limbo state mean? which part of the code this affects? If nothing was focused what's wrong to go back to the same state? How do we open the panel without focusing?

I believe the eefault is to focus the document now if there's no previously focused item. The mechanism should be that, if there's a previously focused item, after the panel closes, focus should return to it. The user should not be put into a state where the item after leaving the panel is different from the one she was on before opening it. I believe that's what I meant with my original quoted comment.

Re my last comment: Restoring focus to the previously focused item is already working fine in nightly, both if the focus is on a page element or on the document itself.

Thanks for the clarification Marco. So our task is basically to verify we don't steal focus when closing the panel.