OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-accessibility] Re: [office] Proposal for Radio Button grouping


Backing up a little bit. 

This feature proposal came up on Monday's call:   
http://wiki.oasis-open.org/office/Grouping_for_Radio_Elements

Since the proposer claimed that it had an accessibility impact: "Grouping 
adds additional structure and helps accessibility" I wanted to evaluate 
this specific claim.  In particular, I was not aware that we had a 
accessibility defect with the way radio buttons are defined in ODF 1.1. 

Do we?

The proposer also claims "Currently ODF provides not way to group radio 
buttons. The new attribute will add grouping support. "

If grouping means "to associate the radio buttons into a group of 
mutually-exclusive controls" then I think we already have grouping support 
in ODF 1.1, via the common name mechanism borrowed from HTML.  If the 
proposer is intending some other grouping semantics, then this needs 
clarification.

As Duane points out, the issue of contradicting group definitions could be 
resolved by defining a resolution mechanism.  But before we go down that 
road, I'd like to see whether this new way of defining radio button groups 
in fact adds any expressivity to ODF, or is it merely an equivalent method 
of defining groups.  I'm not a big fan of adding features twice.  It is 
hard enough adding them once.

So my questions are:

1) Do we have a problem with radio button accessibility in ODF 1.1? 
2) If so, does this proposal address that problem?
3) If not, is this proposal allow implementations to express something 
that cannot already be expressed by the existing grouping mechanism?
4) If so, what new does it allow implementations to express?

-Rob

Malte.Timmermann@Sun.COM wrote on 08/05/2008 01:28:12 PM:

> I also didn't understand the need for group names when the existing name
> can do the same. The name even doesn't have to be anything reasonable,
> since it's IMHO internally used only, nothing the user or AT must
> see/read. (A sighted user also won't see it when just using the form).
> 
> If the user should see anything, it's then up to the author to provide a
> group box or something else, which then can have a name and description.
> 
> Which leads me to the question: Very often you don't have group boxes
> anymore, but simply a label, maybe with some line.
> 
> How can I specify that the label belongs to the group?
> 
> Make the XML elements children of that element?
> 
> Malte.
> 
> Bob Jolliffe wrote, On 05.08.08 18:24:
> > Thinking some more about grouping, I still don't see thast there is 
any
> > need to have a group-name for radio buttons.  They are already 
logically
> > grouped by the name.  I imagine a screenreader, for example, would 
treat
> > the set in the same way as a select control and read "select w,x,y or 
z"
> > for the named radio buttons.
> > 
> > Checkboxes (and other controls) on the other hand may indeed benefit
> > from grouping in order to render the semantics of  "select all of the
> > following which apply".  Perhaps this grouping could be reasonably
> > achieved through a <form:frame> element which already does support
> > <form:name>, <form:label> and <form:title> attributes.  As a
> > recommendation one could then specify that all input controls which 
form
> > a coherent group should be contained within a <form:frame> with a
> > name/label/title which could be exposed to the accessibility API
> > (regardless of whether this frame is a visible element or not).  This
> > seems to be the closest equivalent of a html frameset.
> > 
> > Alternatively these, and perhaps all, elements should have a
> > form:group-name attribute, but I prefer the approach above.
> > 
> > Regards
> > Bob
> > 
> > 2008/8/5 Richard Schwerdtfeger <schwer@us.ibm.com
> > <mailto:schwer@us.ibm.com>>
> > 
> >     Rob,
> > 
> >     We will need to ensure there is a name we can expose to the
> >     accessibility API. Is form:group-name or name="string" the name of
> >     the group that will be rendered? If not we will need to add
> >     <svg:title> somewhere in there for the short name.
> > 
> >     Rich
> > 
> > 
> >     Rich Schwerdtfeger
> >     Distinguished Engineer, SWG Accessibility Architect/Strategist
> >     Chair, IBM Accessibility Architecture Review Board
> >     blog: http://www.ibm.com/developerworks/blogs/page/schwer
> >     Inactive hide details for Robert Weir/Cambridge/IBM@LotusRobert
> >     Weir/Cambridge/IBM@Lotus
> > 
> > 
> >                             *Robert Weir/Cambridge/IBM@Lotus*
> > 
> >                             08/04/08 10:29 AM
> > 
> > 
> > 
> >     To
> > 
> >     office-accessibility@lists.oasis-open.org
> >     <mailto:office-accessibility@lists.oasis-open.org>
> > 
> >     cc
> > 
> >     office@lists.oasis-open.org <mailto:office@lists.oasis-open.org>
> > 
> >     Subject
> > 
> >     [office] Proposal for Radio Button grouping
> > 
> > 
> > 
> > 
> >     As you probably know, ODF currently defines the exclusive 
selection
> >     semantics of radio controls based on radio controls with the same 
name,
> >     similar to how this is done in HTML:
> > 
> >     ODF 1.1, section 11.3.14:    "The <form:radio> element describes
> >     controls
> >     which act like check boxes except that when several radio buttons 
share
> >     the same control name they are mutually exclusive. When one button
> >     is on,
> >     all of the other buttons with the same name are off. If no radio
> >     button is
> >     initially on, the way in which the application chooses which 
button to
> >     turn on initially is undefined."
> > 
> >     On today's ODF TC call the following ODF 1.2 proposal was 
discussed: 
> >     http://wiki.oasis-open.org/office/Grouping_for_Radio_Elements
> > 
> >     This proposal would add a form:group-name attribute to the 
form:radio
> >     element in section 11.3.14, as an alternative way to specify 
grouped
> >     radio
> >     buttons.  It is not stated how to resolve situations where both
> >     grouping
> >     methods are in simultaneous, possibly contradictory use.
> > 
> >     The Proposer has requested a vote on this proposal for next 
Monday.  If
> >     the Accessibility SC has any comments, please send them to the TC 
by
> >     Friday.
> > 
> >     Thanks,
> > 
> >     -Rob
> > 
> > 
> > ---------------------------------------------------------------------
> >     To unsubscribe from this mail list, you must leave the OASIS TC 
that
> >     generates this mail.  Follow this link to all your TCs in OASIS 
at:
> >     
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> > 
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]