Closed Bug 433895 Opened 17 years ago Closed 16 years ago

When using aria-labelledby to make up an accessible name, if an ID points to an accessible with both a name and a value, only use the value.

Categories

(Core :: Disability Access APIs, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: MarcoZ, Assigned: surkov)

References

(Blocks 2 open bugs)

Details

(Keywords: access)

Attachments

(2 files)

An example where this fails is the Thunderbird Accounts Manager, Server Settings page, the textbox that says "Check for new messages every x minutes". http://mxr.mozilla.org/seamonkey/source/mailnews/base/prefs/resources/content/am-server.xul#161 The name for the textbox should be "Check for new messages every 5 minutes". However, because there is also a control attribute on the label with id "biffEnd", we currently also take the name into account, making this "Check for new messages every minutes 5 minutes" as the accessible name. According to the ARIA implementation guidelines, in section 11.3.6: http://developer.mozilla.org/en/docs/ARIA_User_Agent_Implementors_Guide#11.3.6_Name under "Definition of depth first name computation (used in rule 1 and 2) : Iterate through the elements of the given content subtree in depth first order. For each element," it is specified that "2. If a control, append the current value text for the control" Value Text, not name. We are currently also using the name for textboxes.
Flags: wanted1.9.0.x?
since i'm around here, I'll take this one
Assignee: nobody → surkov.alexander
MarcoZ, looking at the code it sounds we append value. Could you please put small stand-alone example here?
Attached file Mochitest (deleted) —
Mochitest with expected output. Currently fails and gives expected and actual names. There is an extra word "minutes" before the number "5" in the name that shouldn't be there.
MarcoZ, mochitest doesn't fail, what's wrong?
It fails here! A difference in platforms? I'm on Windows.
(In reply to comment #5) > It fails here! A difference in platforms? I'm on Windows. > you're right, it fails on windows but it didn't on mac. Quite strange thing.
MarcoZ, it seems what you are asking does interferes with bug 347219. Could you check won't we broke something?
Attached patch patch (deleted) — Splinter Review
Attachment #330696 - Flags: review?(aaronleventhal)
Attachment #330696 - Flags: review?(marco.zehe)
Status: NEW → ASSIGNED
Comment on attachment 330696 [details] [diff] [review] patch r=me. Thanks!
Attachment #330696 - Flags: review?(marco.zehe) → review+
So basically, if there's a value we won't use the name. If the value is empty we also won't use the name, so for something like a textbox it would now be inconsistent now whether we use the name or not, depending on whether the textfield was currently empty?
Another possibility is that we: 1. Change the XUL not to associate the label twice 2. Fix our Implementors guide to say use the name of embedded controls as well. That's what I originally intended, actually, IIRC :) There are probably other possibilities, but we need to do some more thinking here, probably. There are several cases of these XUL labels: 1) the label for a control has its own element, that might be associated with a widget using the control attribute 2) The label for a control has its own element but is associated using labelledby 3) The label is part of control, and is created just by using the label="sometext" attribute.
Attachment #330696 - Flags: review?(aaronleventhal) → review-
(In reply to comment #11) > Another possibility is that we: > 1. Change the XUL not to associate the label twice I don't like that. We should get the name from label so much how the author specified this. > 2. Fix our Implementors guide to say use the name of embedded controls as well. > That's what I originally intended, actually, IIRC :) If that's was originally intended then I think it doesn't make sense to broke this if there is no good reason. So if we want to use label and value both then let's fix the documentation and add mochitests for this.
Just some thoughts: 1. Without any aria-labelledby, my original example, taken from Thunderbird's account wizuard, would read: Checkbox: "Check for new messages every" textbox: "minutes", plus the value that is read by the screen reader when focusing the control. 2. With aria-labelledby: on the checkbox: "Check new messages every minutes 5 minutes". The "minutes" is doubled. This is in accordance with the proposed change to use both label and value of a control when referencing it via aria-labelledby. 2. On the textbox: The same: "Check for new messages every minutes 5 minutes". If the label ID is left out, the label would change to "Check for new messages every minutes 5". This is grammatically incorrect. The only alternative to get this right currently is remove the control attribute from the label and only label the textbox via aria-labelledby. That would, however, take away the ability to click on "Minutes" and get the textbox focused, which might confuse some sighted users.
Blocks: namea11y
Flags: wanted1.9.0.x? → wanted1.9.1?
Wontfix or invalid? since it doesn't go with ARIA implementation guide (http://www.w3.org/WAI/PF/aria-implementation/).
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: