Closed Bug 376032 Opened 14 years ago Closed 14 years ago

posinset and setsize incorrect for radio button groups

Categories

(Core :: Disability Access APIs, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: scott, Assigned: surkov)

References

(Blocks 3 open bugs)

Details

Attachments

(5 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a4pre) Gecko/20070329 Minefield/3.0a4pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a4pre) Gecko/20070329 Minefield/3.0a4pre

posinset and setsize are attributes of radio buttons that give information about the position of a radio button within a group and the size of the group.  I will attach a test page which shows that these attributes have been incorrectly set.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Surkov is working on posinset/setsize in general.
Assignee: aaronleventhal → surkov.alexander
Blocks: ia2, htmla11y, atk
Attached file testcase
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attached patch patchSplinter Review
patch handles the case html:raion[type="radio"][name] like it shown in testcases.
Attachment #260345 - Flags: review?(ginn.chen)
OS: Linux → All
Hardware: PC → All
(In reply to comment #4)
> Created an attachment (id=260345) [details]
> patch
> 
> patch handles the case html:raion[type="radio"][name] like it shown in
> testcases.
> 

sorry, should be html:input[type="radio"][name]
Attachment #260345 - Flags: review?(ginn.chen) → review+
checked in
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Attached file More complex testcase
We need to make sure this still handles case where you have a textfield, combo box, file input etc. as part of a radio button field, e.g.

( ) Delete all emails from server immediately
(o) Keep emails on server for last ____ days
( ) Keep emails on server forever

This is a group of 3 radio buttons, and as long as the name is the same for all 3 the setsize should be 3.
(In reply to comment #7)
> Created an attachment (id=260776) [details]
> More complex testcase
> 
> We need to make sure this still handles case where you have a textfield, combo
> box, file input etc. as part of a radio button field, e.g.
> 
> ( ) Delete all emails from server immediately
> (o) Keep emails on server for last ____ days
> ( ) Keep emails on server forever
> 
> This is a group of 3 radio buttons, and as long as the name is the same for all
> 3 the setsize should be 3.
> 

Do you mean if there is no html:form element that contains them then we should expose those ARIA attrs in any way? If so then where we should search related elements? This is either through document entirely or by methods we use for related content searching.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The old logic for our get_accDescription() hack just used the name. When there is no form the document is used. This is the same as the layout code's logic for up/down arrow key -- it uses name to group.

The new logic requires that the input type is the same.

+    if (item &&
+        item->AttrValueIs(kNameSpaceID_None, nsAccessibilityAtoms::type,
+                          type, eCaseMatters) &&
+        item->AttrValueIs(kNameSpaceID_None, nsAccessibilityAtoms::name,
+                          name, eCaseMatters)) {
+


Basically, if there is a name, then that's all you need to compare, otherwise use type, but only when there is no name. I think that would fix all the important cases.
Attached patch patch (no form)Splinter Review
Attachment #260821 - Flags: review?(aaronleventhal)
Attachment #260821 - Flags: review?(aaronleventhal) → review+
(In reply to comment #10)
> Created an attachment (id=260821) [details]
> patch (no form)
> 

checked in
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Blocks: groupa11y
You need to log in before you can comment on or make changes to this bug.