Accessible name for location bar is inconsistent or misbehaving

VERIFIED FIXED in seamonkey2.1a1

Status

VERIFIED FIXED
10 years ago
8 years ago

People

(Reporter: MarcoZ, Assigned: MarcoZ)

Tracking

({access})

Trunk
seamonkey2.1a1
access

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

10 years ago
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?
(Assignee)

Comment 2

10 years ago
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.
(Assignee)

Comment 3

10 years ago
Created attachment 386109 [details] [diff] [review]
Patch

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)
(Assignee)

Updated

10 years ago
Attachment #386109 - Flags: review?(bolterbugz)

Updated

10 years ago
Attachment #386109 - Flags: superreview?(neil)
Attachment #386109 - Flags: superreview+
Attachment #386109 - Flags: review?(neil)
Attachment #386109 - Flags: review+
Comment on attachment 386109 [details] [diff] [review]
Patch

r=me
Attachment #386109 - Flags: review?(bolterbugz) → review+
(Assignee)

Updated

10 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 10 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.
(Assignee)

Comment 7

10 years ago
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.
(Assignee)

Comment 9

10 years ago
(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
(Assignee)

Comment 11

10 years ago
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

Comment 12

8 years ago
> 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.