337532 - Back and Forward dropmarker history buttons should have proper names.

Status: RESOLVED FIXED

(Firefox :: Disability Access, defect)

Description

[Tim Miao]

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.

Comment 1

[Willie Walker]

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?

Comment 2

[Mark Pilgrim (inactive)]

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

Comment 3

[Aaron Leventhal]

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.

Comment 4

[Mark Pilgrim (inactive)]

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.

Comment 5

[Aaron Leventhal]

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.

Comment 6

[Mark Pilgrim (inactive)]

Attachment: make dropmarker inherit label

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

Comment 7

[Asaf Romano (gone)]

Comment on attachment 227662 [details] [diff] [review]
make dropmarker inherit label

What about other dropmarkers (e.g. the one in autocomplete.xml)?

Comment 8

[Aaron Leventhal]

(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 9

[Asaf Romano (gone)]

Comment on attachment 227662 [details] [diff] [review]
make dropmarker inherit label

per comments on irc.

Comment 10

[Mark Pilgrim (inactive)]

Attachment: patch other controls that have dropmarkers

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 11

[Asaf Romano (gone)]

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?

Comment 12

[Aaron Leventhal]

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.

Comment 13

[Mark Pilgrim (inactive)]

Attachment: patch w/o autocomplete support

removing autocomplete support at mano's request.

Comment 14

[Asaf Romano (gone)]

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

r=mano

Comment 15

[:Gavin Sharp [email: [e-mail]]]

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