501445 - Accessible name for location bar is inconsistent or misbehaving

Status: VERIFIED FIXED

(SeaMonkey :: Location Bar, defect)

Description

[Marco Zehe (:MarcoZ)]

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.

Comment 1

[David Bolter [:davidb] (NeedInfo me for attention)]

Oh not good. Do you have a regression range?

Comment 2

[Marco Zehe (:MarcoZ)]

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.

Comment 3

[Marco Zehe (:MarcoZ)]

Attachment: Patch

1. Get rid of the hidden xul:label element.
2. Use aria-label pointing to the same entity instead.

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 386109 [details] [diff] [review]
Patch

r=me

Comment 5

[Marco Zehe (:MarcoZ)]

Pushed:
http://hg.mozilla.org/comm-central/rev/b9287cd02d2e

Comment 6

[alexander :surkov (:asurkov)]

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.

Comment 7

[Marco Zehe (:MarcoZ)]

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.

Comment 8

[alexander :surkov (:asurkov)]

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

Comment 9

[Marco Zehe (:MarcoZ)]

(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. :)

Comment 10

[alexander :surkov (:asurkov)]

(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

Comment 11

[Marco Zehe (:MarcoZ)]

Verified fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.1pre) Gecko/20090706 SeaMonkey/2.0b1pre

Comment 12

[Philip Chee]

> 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)!