Closed Bug 501445 Opened 15 years ago Closed 15 years ago

Accessible name for location bar is inconsistent or misbehaving

Categories

(SeaMonkey :: Location Bar, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
seamonkey2.1a1

People

(Reporter: MarcoZ, Assigned: MarcoZ)

Details

(Keywords: access)

Attachments

(1 file)

When typing in the location bar, the accessible name changes to reflect the typed letters or misbehaves in some other inconsistent manner with screen readers. The reason is the inaccessible hidden label that's linked to the textbox.
Oh not good. Do you have a regression range?
No I don't, but I've seen this for quite a while. I suspect it's some weirdness in the XUL of suite/browser/navigator.xul or the bindings it uses. Am investigating, since my original idea to do an aria-labelledby on the textbox pointing to the toolbaritem does not work. Looks like we're not properly creating accessibles for xul:toolbaritem.
Attached patch PatchSplinter Review
1. Get rid of the hidden xul:label element. 2. Use aria-label pointing to the same entity instead.
Assignee: nobody → marco.zehe
Status: NEW → ASSIGNED
Attachment #386109 - Flags: superreview?(neil)
Attachment #386109 - Flags: review?(neil)
Attachment #386109 - Flags: review?(bolterbugz)
Attachment #386109 - Flags: superreview?(neil)
Attachment #386109 - Flags: superreview+
Attachment #386109 - Flags: review?(neil)
Attachment #386109 - Flags: review+
Attachment #386109 - Flags: review?(bolterbugz) → review+
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Marco and David, what is expected behaviour of hidden label for control? I know we generate name from hidden element when it referred from aria-labelledby. Should we do the same for HTML/XUL labels with @for/@control attributes? Note, this hidden label was introduced in bug 237249. Also see comment there: "Need hidden label on textbox for accessibility, because what receives focus needs a text name". I could suppose it might be regression from accessible name code reorganization. However we should decide if we should follow aria-labelledby approach for XUL/HTML labels, i.e. if we should grab the name from their subtree.
We should be consistent with XUL and HTML. And IIRC a hidden element pointed to by aria-labelledby should havea proper accessible created. This is not happening here. But for this particular scenario, aria-label or a hidden label element is really not that much different except that there is one less element now.
(In reply to comment #7) > We should be consistent with XUL and HTML. Do you mean if XUL or HTML label with @control/@for attribute is hidden then ignore it in a11y? > And IIRC a hidden element pointed to > by aria-labelledby should havea proper accessible created. Sorry, didn't catch you. > This is not > happening here. But for this particular scenario, aria-label or a hidden label > element is really not that much different except that there is one less element > now. I don't criticize your approach. It's worth to replace hidden label on @aria-label attribute. I think Aaron introduced it because we haven't aria-label that times. But also since he introduced then it worked previously and I wonder what behaviour is right.
(In reply to comment #8) > (In reply to comment #7) > > We should be consistent with XUL and HTML. > > Do you mean if XUL or HTML label with @control/@for attribute is hidden then > ignore it in a11y? Don't know if we should ignore the label, or create an accessible for it. But we should definitely put its name on the referenced accessible as that accessible's accName. > > And IIRC a hidden element pointed to > > by aria-labelledby should have a proper accessible created. > Sorry, didn't catch you. Wasn't there some talk about that if a n element is originally hidden, but being pointed to by aria-labelledby or aria-describedby, that it should be created nevertheless? > I don't criticize your approach. It's worth to replace hidden label on > @aria-label attribute. I think Aaron introduced it because we haven't > aria-label that times. But also since he introduced then it worked previously > and I wonder what behaviour is right. I think we can discuss that in a separate bug. It's a more general problem, not just SeaMonkey's. :)
(In reply to comment #9) > I think we can discuss that in a separate bug. It's a more general problem, not > just SeaMonkey's. :) done, bug 501580
Verified fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.1pre) Gecko/20090706 SeaMonkey/2.0b1pre
Status: RESOLVED → VERIFIED
> Verified fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.1pre) > Gecko/20090706 SeaMonkey/2.0b1pre Does not appear to have made it to the comm-1.9.1 branch (SeaMonkey 2.0.x)!
Target Milestone: --- → seamonkey2.1a1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: