User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050607 Firefox/1.0.4 Build Identifier: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.8.0.2) Gecko/20060502 Firefox/1.5.0.2 Orca could report the button name in toolbar, Back and Forward have no proper name, orca will report only push button while other buttons can be reported as Reload, Stop,Home and etc. Reproducible: Always Steps to Reproduce: 1. Launch orca and firefox. 2. Turn on numpad and press 7 and 9 to read the current frame. 3. Read the toolbar items. Actual Results: Back and Forward are reported as push button. Expected Results: These two button should have proper names. This bug can be found on vermillion_40/snv_39 with both Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.8.0.2) Gecko/20060502 Firefox/1.5.0.2 and Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9a1) Gecko/20060426 Minefield/3.0a1.

I'd like to explore this a little further and perhaps write a test case for you. Is there a way to get to these buttons via keyboard navigation alone?

No, but see https://bugzilla.mozilla.org/show_bug.cgi?id=287743#c9

Tim, please make sure you mark the Hardware/OS as Sun only if it's really a bug only on Sun/Solaris. Otherwise it's confusing for us and we don't know if it's really a bug only there.

This one is hard to test on Windows, because the toolbar buttons never get focus so Inspect32 (and MSAA in general) can never get to them. (Hovering over the back button shows "Cannot get object from point" in Inspect32.) However, if I use the -moz-user-focus:normal hack to force the toolbar buttons into the tab order, all of the main toolbar buttons are showing proper accessible names. But I'm not sure that's really a fair test. At any rate, I can't reproduce the stated problem -- that the Back and Forward buttons are exposed differently and worse than they other main toolbar buttons -- on Windows.

Mark, I use Acceessible Explorer and can get the objects there. Anyway, the small dropmarker buttons don't have accessible names. I suspect the bug is about that.

Ah, I see it now. Easy fix. Verify in Accessible Explorer before and after.

Comment on attachment 227662 [details] [diff] [review] make dropmarker inherit label What about other dropmarkers (e.g. the one in autocomplete.xml)?

(In reply to comment #7) > (From update of attachment 227662 [details] [diff] [review] [edit]) > What about other dropmarkers (e.g. the one in autocomplete.xml)? They do have an accessible name which is the same as the textfield next to them.

Comment on attachment 227662 [details] [diff] [review] make dropmarker inherit label per comments on irc.

This patch adds the label to the dropmarker in autocomplete, button.xml#menu, button.xml#menu-button, as well as the original toolbarbutton bindings.

Comment on attachment 228989 [details] [diff] [review] patch other controls that have dropmarkers Aaron/Mark: I was wondering whether we should use something like the control attribute (that is, take the label from another element in the a11y code). For example, does the current patch really make sense in the automcomplete case?

Mano, I'm not as concerned about accessible name for the dropmarker in autocomplete, because the screen reader works differently when you're in an autocomplete an the dropmarker name is not an issue there. It's an issue in the toolbar because those items never get focused. You can only access them if the screen reader can give you a list of the items there.

removing autocomplete support at mano's request.

Comment on attachment 230444 [details] [diff] [review] patch w/o autocomplete support r=mano

mozilla/toolkit/content/widgets/button.xml 1.19