GNOME Bugzilla – Bug 533660
Orca does not display labels for unlabeled XUL entries
Last modified: 2010-09-20 10:52:49 UTC
This is a spin-off bug from bug 533125. Firefox and Thunderbird employ the use of entries whose "label" is some very low contrasting text which disappears when that entry is given focus. (e.g. Search entry/autocomplete in Firefox and Thunderbird; the search entry in the Firefox Download Manager). We have special handling for XUL entries which are children of autocompletes that causes braille to be displayed in the absence of a proper label. For other XUL entries -- and entries/text objects in general -- the default braille generator expects there to be a label to display. At Mike's suggestion on bug 533125, I have filed an enhancement request asking for the Download Manager's search entry to be given a proper label, and am blocking this bug against it: https://bugzilla.mozilla.org/show_bug.cgi?id=434249 If the FF guys just won't give us a label, we can special case this entry as well. But I'm hoping for a proper label. :-)
I do not believe a proper label will happen. This is a special Search widget, not a simply entry, whose purpose is to provide a search label as long as there's no text in it. They added a special property that is designed to give the accessible a proper name which should be used for both braille and speech by screen readers. See Mozilla bug <https://bugzilla.mozilla.org/show_bug.cgi?id=392890> for the Download Manager's case, and <https://bugzilla.mozilla.org/show_bug.cgi?id=406095> for the general handling of these textboxes. The only part that really is not as-designed is the fact that the colors are hard to read.
Given that this will not be fixed in Firefox, we should special-case it for braille. Unblocking.
Turned out to be a one-line fix (not counting the comment explaining why on earth we needed to do what we were doing). http://git.gnome.org/browse/orca/commit/?id=498a145537bc8b368cfcc78b197b6d13e905adc4