GNOME Bugzilla – Bug 472377
Need to fix braille for radio buttons and checkboxes in HTML content
Last modified: 2008-05-27 20:01:25 UTC
As indicated on bug #471955, we should have a Gecko-specific generator for radio buttons similar to what we have for checkboxes. In addition, the current braille generator for checkboxes needs to be modified so that the label comes before the role.
I think the Meg Ryan patch from bug 471955 is good for gnome-2-20 and should be checked into trunk and gnome-2-20. I realize it doesn't address the indicator/role/label ordering issue, but it does eliminate much redundancy in the label presentation for braille and represents a significant step towards improving usability in this area. Given that {check,radio}buttons indicators and their labels are separate objects in HTML, but atomic objects in GTK+, I think the indicator/role/label ordering problem for braille might be a tougher nut to crack. I'm wondering if the ultimate resolution may be to just merely eliminate the rolename.
Created attachment 94767 [details] [review] The Meg Ryan patch Doesn't repeat the labels over and over again. Radio buttons are now like checkboxes. Both still need the role and label reversed (or the role removed as Will suggested).
Meg's been checked in to both trunk and the 2.20 branch. (Yes! Yes! Yes!)
> Radio buttons are now like > checkboxes. Both still need the role and label reversed (or the role removed > as Will suggested). Mike - what do you think of removing the rolename? The user will still get the status indicator (e.g., "< >" and "<x>"), allowing them to infer what kind of component this is.
Even though the indicators are different I think removing the role would confuse new users. I would not be in favor of this change.
As agreed in today's team meeting: Moving this to FUTURE as it's looking like a lot of work for a relatively isolated issue.
First coarse pass at GNOME 2.24 planning.
As per team meeting, we want to present the labels for radio buttons and checkboxes based on where they appear on the page rather than force them to be consistent with their XUL equivalents. Therefore, this bug is being closed as FIXED.