User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060110 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060110 Firefox/1.6a1 When you examine checkboxes in forms using AT-POKE, they have no accessible name associated with them. Reproducible: Always Steps to Reproduce: 1. Run Firefox. Point it to the attached HTML file 2. Run at-poke and poke Firefox 3. Expand the HTML container in at-poke and look for the checkboxes 4. Look for the accessible names and/or accessible text specialization of the checkboxes Actual Results: 1. There's no name or text specialization for the checkbox 2. The text for a set of checkboxes shows up as a single text object (e.g., the sample HTML file has three checkboxes: "Red," "Green," and "Blue." The accesssible hierarchy shows one text object as "Red Green Blue.") Expected Results: 1. Each checkbox should have a the associated text as the accessible name or at least in an accessible text specialization.
Created attachment 209019 [details] Sample HTML demonstrating the problem. Observe accessible hierarchy using at-poke
All kinds of inline element can be in a block frame. When an element such as input element in a block frame, to create a nsHTMLBlockAccessible is invalid. Nodes for text element and input element should be created seperatedly.
Created attachment 209336 [details] [diff] [review] patch this patch fixes actural result item 2. for item one, that is another bug.
Created attachment 209340 [details] [diff] [review] patch v2 patch to fix both error described in actural result item 1&2
Created attachment 209341 [details] [diff] [review] patch v2.1 remove debug info in v2
Comment on attachment 209341 [details] [diff] [review] patch v2.1 Please remove the whitespace changes from the patch. It takes longer to review and it will confuse the CVS history when you check in. It also increases CVS conflicts, making code more difficult to merge. More importantly, I'm not convinced that this is a correct HTML way to wrap a form label. I believe that is normally done with the <label> element. Can you find the right place in the spec to show me this is a correct/normal practice?
Attachment #209341 - Flags: review?(aaronleventhal) → review-
In fact, I'm 95% sure that HTML is wrong. When you click on the label it should check the checkbox. That's how you know you're doing it right. Either of these 2 are correct HTML: <label><input type="checbkox"/>Red</label> or <input id="cb1" type="checkbox"/><label for="cb1">Red</label> This is bad HTML: <input type="checkbox">Red</input> I move to mark this bug as INVALID
Created attachment 209544 [details] test case I use Aaro, pls. see test case I use. This is a valid html and bring same issues.
Created attachment 209545 [details] [diff] [review] patchv2.2 remove extra space
Comment on attachment 209545 [details] [diff] [review] patchv2.2 Nian, There's no clear indication that the label in your testcase is for that checkbox. You could just as easily have: Red [ ] Green [ ] Blue [ ] <html> <form> Red<input name="red" type="checkbox"> Green<input name="green" type="checkbox"> Blue<input name="blue" type="checkbox"> </form> </html> What windows screen readers do is use a heuristic to guess. By not providing the guess in Firefox we allow the screen readers to know they should be using the heuristic and write it themselves. Otherwise we're putting the guessing in Firefox and that's not the right place to put it.
Attachment #209545 - Flags: review?(aaronleventhal) → review-
Aaron, there is two different bugs. One is that checkbox with name attribute shows name is "none" in at-poke The other is that if a block frame contains several text, atk tries to group them into one node, which is wrong when text is sepetated by input element. I'll file another bug to trace and discuss it.
bug 32475 is filed
Created attachment 209668 [details] [diff] [review] patch to fix chechbox shows no name in at-oke
The name attribute is an internal name to the field for identity. We should not use it as the accessible name. I votes INVALID.
(In reply to comment #15) > The name attribute is an internal name to the field for identity. > We should not use it as the accessible name. > > I votes INVALID. > agree w/ ginn at this point.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.