Pressing the "Information" button in the new Download Manager yields no information and traps keyboard focus. Once this happens the only way to restore keyboard access is to escape out of the Download Manager entirely. Actual Results: Window-eyes: {Context menu, menu expanded} Expected Results: Unknown, perhaps a read-only edit a la the Page Info screen.

Please dupe to bug 393188 if appropriate.

In that case, this bug has only to do with the lack of accessible info spoken when the Information button is pressed, at least on Windows. Maybe someone can try this in Linux?

With JAWS, the result is about the same, only that JAWS remains completely silent. Only the braille display shows that a menu just got activated.

In Linux it's the same. Menu pops up which is unreadable.

It seems like this is a case of a non-traditional menu. :-) When you press the Information button, a menu does indeed appear, but the children of that menu are not the expected menu items. Apparently* they are push buttons. So you can tab to the first one and then arrow among them. But it's far from intuitive. And if you change your mind and press Escape, the entire dialog closes rather than just the menu which is confusing/unexpected. *As an aside, visually it's not especially clear how to interact with this thing either. I wouldn't have known that the items in question were buttons (and hence clickable) had I not seen this bug and wondered what was up.

Just a note that the symptom seems to be similar to bug 393398, but this behaviour was introduced at an earlier stage than bug 393398.

Why isn't blocking status requested on this? Is it not an important bug? Is it sec508 or not?

I requested blocking and set a priority and a target milestone. Hope it's appropriate this way!

(In reply to comment #7) > Why isn't blocking status requested on this? Is it not an important bug? Is it > sec508 or not? Feel free to just do it, we're all busy, and mistakes/oversights can be made...

(In reply to comment #8) > I requested blocking and set a priority and a target milestone. Hope it's > appropriate this way! Unless you plan on fixing this bug yourself, please do not change the priority and target milestone fields. Requesting blocking is something anybody with 'editbugs' permissions in Bugzilla can and should do if they feel the issue is important enough.

i'm going to propose that we get rid of the info button and just display this information inline on the selected item. I'm pretty sure the accesibility issue is being addressed either way due to it also impacting the new bookmarking ui.

This blocks, but might end up being resolved INVALID if we go with Alex's suggestion, which I must admit is appealing!

So, I'm not very good at this, but as far as I can tell this is caused because the panel claims it's a menupopup as far as a11y is concerned: http://mxr.mozilla.org/seamonkey/source/toolkit/content/widgets/popup.xml#14 (and further lines) And then in the accessibility code, we assume that the menu must have the "menuactive" or "open" attribute set in order to be active http://mxr.mozilla.org/seamonkey/source/accessible/src/xul/nsXULMenuAccessible.cpp#596 (line 606, 615) and as far as I can tell from the popup.xml implementation, that doesn't happen, so the accessibility state turns into invisible, collapsed and offscreen (618-620). Which would explain why nothing happens afterwards. Aaron, others: does this seem reasonable, or did I miss something?

What I am wondering is...What does this thing look like visually? Is this something that even remotely resembles a menu? If not, and my feeling that this is not the case, then for all intents and purposes this is not a menu, but more a group box, panel, or even dialog kind of thing. The Add Bookmark "popup" described in bug 393398, for example, also does not feel like a menu to me. So we should seriously rethink how we want to call this on the accessible side. And to my feeling, menupopup is the worst choice of all, since it does not resemble the interactions I can have with this control. What do others think?

(In reply to comment #14) > What I am wondering is...What does this thing look like visually? Is this > something that even remotely resembles a menu? If not, and my feeling that this > is not the case, then for all intents and purposes this is not a menu, but more > a group box, panel, or even dialog kind of thing. The Add Bookmark "popup" > described in bug 393398, for example, also does not feel like a menu to me. > So we should seriously rethink how we want to call this on the accessible side. > And to my feeling, menupopup is the worst choice of all, since it does not > resemble the interactions I can have with this control. What do others think? I agree. I had assumed that this was some sort of litle alert-type popup that displayed some stats re the selected file. If that's all it is, then we'd be find with a Xul Alert, like the one that's currently used for the Remember Password prompt. If it requires interaction, we'd still be fine with an alert like that as long as it grabs focus when it's activated.

I was told this whole thing was being redesigned, though, so this may be invalid once the new UI lands, probably very shortly now.

(In reply to comment #13) > Aaron, others: does this seem reasonable, or did I miss something? > If panel acts like you described then it should be a problem actually. Btw, iirc recent evan's fix should be related with this. Another issue info button and panel are not related, it's cause haspopup states is not exposed. But we shouldn't care about AT until UI is not changed I guess.

Bug 405888 will remove the info button.

This bug is now INVALID since Bug 405888 landed.