Improve accessibility and keyboard interaction

NEW
Unassigned

Status

()

Firefox
Downloads Panel
6 years ago
3 months ago

People

(Reporter: Paolo, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {access, meta})

Trunk
access, meta
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

6 years ago
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.)
(Reporter)

Updated

6 years ago
Keywords: access
(Reporter)

Updated

6 years ago
Blocks: 564934, 747422
Depends on: 774127
Shouldn't this have been a "tracked" bug way back in February? It's rather unfortunate to ship with an accessibility regression like this.
tracking-firefox17: --- → ?
(Reporter)

Comment 3

6 years ago
(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.
tracking-firefox17: ? → ---
Should the issues in comment 0 be broken down into individual bugs blocking bug 747422?
Flags: needinfo?(mak77)
(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.
Flags: needinfo?(mak77)
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.

Updated

5 years ago
Depends on: 809852

Updated

5 years ago
Depends on: 809854
* 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?
No longer blocks: 747422
Flags: needinfo?(paolo.mozmail)
(Reporter)

Comment 8

5 years ago
(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?
Flags: needinfo?(paolo.mozmail) → needinfo?(marco.zehe)

Comment 9

5 years ago
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.
Flags: needinfo?(marco.zehe)
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.

Updated

5 years ago
Component: General → Downloads Panel

Updated

5 years ago
No longer blocks: 564934

Updated

5 years ago
Depends on: 829495, 829130

Updated

5 years ago
Keywords: meta
Summary: [Downloads Panel] Improve accessibility and keyboard interaction → Improve accessibility and keyboard interaction

Updated

3 months ago
Blocks: 1418973
You need to log in before you can comment on or make changes to this bug.