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)
Core
Disability Access APIs
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?
Assignee | ||
Comment 1•16 years ago
|
||
since i'm around here, I'll take this one
Assignee: nobody → surkov.alexander
Assignee | ||
Comment 2•16 years ago
|
||
MarcoZ, looking at the code it sounds we append value. Could you please put small stand-alone example here?
Reporter | ||
Comment 3•16 years ago
|
||
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.
Assignee | ||
Comment 4•16 years ago
|
||
MarcoZ, mochitest doesn't fail, what's wrong?
Reporter | ||
Comment 5•16 years ago
|
||
It fails here! A difference in platforms? I'm on Windows.
Assignee | ||
Comment 6•16 years ago
|
||
(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.
Assignee | ||
Comment 7•16 years ago
|
||
MarcoZ, it seems what you are asking does interferes with bug 347219. Could you check won't we broke something?
Assignee | ||
Comment 8•16 years ago
|
||
Attachment #330696 -
Flags: review?(aaronleventhal)
Assignee | ||
Updated•16 years ago
|
Attachment #330696 -
Flags: review?(marco.zehe)
Assignee | ||
Updated•16 years ago
|
Status: NEW → ASSIGNED
Reporter | ||
Comment 9•16 years ago
|
||
Comment on attachment 330696 [details] [diff] [review]
patch
r=me. Thanks!
Attachment #330696 -
Flags: review?(marco.zehe) → review+
Comment 10•16 years ago
|
||
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?
Comment 11•16 years ago
|
||
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.
Updated•16 years ago
|
Attachment #330696 -
Flags: review?(aaronleventhal) → review-
Assignee | ||
Comment 12•16 years ago
|
||
(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.
Reporter | ||
Comment 13•16 years ago
|
||
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.
Updated•16 years ago
|
Flags: wanted1.9.0.x? → wanted1.9.1?
Assignee | ||
Comment 14•16 years ago
|
||
Wontfix or invalid? since it doesn't go with ARIA implementation guide (http://www.w3.org/WAI/PF/aria-implementation/).
Reporter | ||
Comment 15•16 years ago
|
||
See comment #14.
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.
Description
•