The default bug view has changed. See this FAQ.

Mozilla exposes incomplete MSAA Name when multiple HTML labels are associated with a form control

RESOLVED FIXED in mozilla2.0

Status

()

Core
Disability Access APIs
RESOLVED FIXED
10 years ago
6 years ago

People

(Reporter: Tom Brunet, Unassigned)

Tracking

(Blocks: 2 bugs, {access})

Trunk
mozilla2.0
access
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 (CK-IBM) Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 (CK-IBM) Firefox/2.0.0.1

From http://www.w3.org/TR/html4/interact/forms.html#h-17.9:
"More than one LABEL may be associated with the same control by creating multiple references via the for attribute."

Firefox is only exposing the first label found to MSAA.  

Reproducible: Always

Steps to Reproduce:
1.Create a page with the following HTML:
<LABEL for="foo">Label one</LABEL> <LABEL for="foo">Label two</LABEL><INPUT id="foo">
2.Use Inspect32 to investigate the MSAA name exposed for the input control
Actual Results:  
"Label one" is returned.  In general, it appears to find the first label and ignore the rest.

Expected Results:  
MSAA:Name = "Label one Label two"

Updated

10 years ago
Keywords: access

Comment 1

10 years ago
Workaround: note that aaa:labelledby accepts a list of ID's separated by a space, and can be used by HTML or XUL to have multiple label targets.

Not a very good workaround for HTML since it's not supported bye other browsers right now, and we should just get <label> correct.

Implemenation-wise, we won't want to walk the entire tree of objects. This means that whenever a label element is created, we should cache what it points to in a hash table so we can retrieve the relationship in reverse with an O(1) algorithm. However, we'll have to be careful to keep the cache updated as elements get removed and attributes change. That's a lot of work to do for this. I'm surprised IE 7 gets that right -- pretty impressive.
(Reporter)

Comment 2

10 years ago
Sorry, I had Pete check that by phone since I didn't have an IE7 install, and I think he looked at the wrong field.  I've since installed Vista to verify and it only displays the content of the second label - unless there's a difference between IE7 on XP and Vista.

Therefore, support for this is broken in at least IE6, IE7 and Firefox 2.  The only browser I'm aware of that supports this is Home Page Reader.  I haven't tested Opera.

Comment 3

10 years ago
It's the kind of thing that's really hard to implement in a way that doesn't affect performance. It isn't common enough for anyone to care enough to do it the right way. There are so many other bigger issues. Ideally I'd like to see it fixed. In the mean time I'd use aaa:labelledby.
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody

Updated

7 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

7 years ago
Blocks: 559750

Updated

6 years ago
Blocks: 459353

Comment 5

6 years ago
fixed by bug 381599 (firefox 4 timeframe), tests in name/test_general.html ("btn_label_multi").
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0

Updated

6 years ago
Flags: in-testsuite+
OS: Windows XP → All
Hardware: x86 → All
You need to log in before you can comment on or make changes to this bug.