We'd like to get an accessibility check on the feature, possibly soon-ish since we are plannin to leave it enabled for Firefox 20. Some changes are currently in inbound and not yet merged to central, so if possible, I'd suggest to use an opt build from inbound, or an opt build from central after the _next_ merge (I expect it to happen soon, basically when Bug 828247 weill be marked fixed). There are a couple things I must point out though: 1. We are planning to make the panel (opened by the downloads button) a mouse-only target for version 20. Currently it supports some keyboard interaction but it's bogus and we are not sure we can come up with the right handling for this release, so we plan to remove all keyboard interaction (focus and focusring) in bug 819428. (see also https://bugzilla.mozilla.org/show_bug.cgi?id=819428#c53). Keyboard interaction would be reintroduces in next version, once we have a final decision on the design part. How bad would be that? 2. Our main target for accessibility and screen readers is the Library Downloads view, not the panel. Indeed CTRL+J and Downloads open that view. We'd like to get an overview of that view and know if there's any showstopper we should absolutely fix now. 3. it will always be possible to disable the feature setting browser.download.useToolkitUI that reverts to the old manager.

(In reply to Marco Bonardo [:mak] from comment #0) > since we are planning to leave it enabled for Firefox 20. > Some changes are currently in inbound and not yet merged to central I figured this may be confusing, basically we are left with a few bugs, those are being merged to central (21) and then uplifted in batch to Aurora (20) where we plan to release the feature.

For completeness the bug to implement proper keyboard interaction in the panel is bug 829130.

update: we are working on a patch that may keep keyboard navigation in the panel. more news coming.

bug 827293 fixed (on inbound so far) a problem in the Library view where the right pane was not focused on opening.

I gave the Library downloads view, opened with CTRL+J, in the 2013-01-14 nightly build. 1. Tab moves from the list of downloads to the search field to the tree view of libarary views to the list again. If there are other targets that should be focused in theory, they're not. :) There used to be a "clear all downloads" button in the older downloads window, for example, that I no longer see. 2. I cannot visually verify if the focus ring is always visible. 3. When opening the downloads view, focus is not always placed in the list. Sometimes, one has to press DownArrow to get focus to anything. Before that, it appears as if the keyboard focus is on the frame/window. If possible, it should always be in the list of downloads.

thank you very much for you checks > There used to be a "clear all > downloads" button in the older downloads window, for example, that I no > longer see. There is Clear Downloads button in the Library toolbar, but we don't tab focus to the toolbar buttons though... I will file this bug to evaluate a solution. The right click context menu has a Clear Downloads option, is that accessible to you? > 2. I cannot visually verify if the focus ring is always visible. Sure, we can take care of checking that. > 3. When opening the downloads view, focus is not always placed in the list. We should have fixed that in bug 827293, that as far as I know is in 2013-01-14 nightly... The only special thing we do there is setting the selection in an async way so the pane is populated and then we enqueue the selection on main-thread. I'm not sure if also enforcing focus would fix the problem.

1. The context menu items are accessible. 2. Please set focus explicitly here, too, in addition to the selection.

(In reply to Marco Zehe (:MarcoZ) from comment #7) > 1. The context menu items are accessible. Ok, so on windows and Linux we are retaining the context menu for accessible Clear Downloads. on Mac I'm going to file a bug to make it tabbable so that it acts like the other toolbarbuttons in the toolbar. > 2. Please set focus explicitly here, too, in addition to the selection. what we do it setting focus and just later selecting the first item... Maybe this confuses the screen reader.

It seems Marco answered feedback request. If you need me to look at anything specific please let me know. Cc'ing Jamie since he might be interested as well.

(In reply to alexander :surkov from comment #9) > It seems Marco answered feedback request. If you need me to look at anything > specific please let me know. If you could help us understanding bug 830407 that'd be awesome, I'm not sure how to reproduce the problem, we set the focus to the view and then set the selection, though I'm not sure why the screen reader doesn't see that.

(In reply to Marco Bonardo [:mak] from comment #10) > (In reply to alexander :surkov from comment #9) > > It seems Marco answered feedback request. If you need me to look at anything > > specific please let me know. > > If you could help us understanding bug 830407 that'd be awesome, I'm not > sure how to reproduce the problem, we set the focus to the view and then set > the selection, though I'm not sure why the screen reader doesn't see that. Ok, we need to debug. Trev, perhaps you can do that faster than me.

Removing this from the list of blockers since we got a check, though dependencies (for now just bug 830407) still block. If in the next days, you find accessibility bugs in the toolbar button (provided you can access it) or in the manager (CTRL+J), be sure to cc-me so I can triage them faster. Both Nightly or Aurora are fine for this testing, the differences are minimal so far.

All dependencies fixed, thanks for the help. Any new bugs should just be filed into Firefox / Downloads Panel component.