Subject: Re: [office] Re: [office-accessibility] Re: [office] Re: [office-accessibility] radiobuttons wrap-up
Distinguished Engineer, SWG Accessibility Architect/Strategist
Michael.Brauer@Sun.COM wrote on 12/05/2008 01:52:12 AM:
> Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>
> Sent by: Michael.Brauer@Sun.COM
> 12/05/2008 01:52 AM
> Richard Schwerdtfeger/Austin/IBM@IBMUS
> Jonathan Pryor <email@example.com>, office TC <firstname.lastname@example.org-
> open.org>, email@example.com, Robert Weir/
> Re: [office] Re: [office-accessibility] Re: [office] Re: [office-
> accessibility] radio buttons wrap-up
> Hi Rich,
> On 12/05/08 00:28, Richard Schwerdtfeger wrote:
> > We are ignoring another problem here which has to do with actually
> > labelling the group. Today,
> > ODF allows you to express labels for individual controls as it takes a
> > form id. So potentially,
> > you can ODF markup which labels members of a group or not. So, it is
> > insufficient to just mark
> > each radio button with the group they belong to. For accessibility you
> > want to be able to group elements
> > and label the group. It seems to easy to fall into the weeds of
> > labelling controls that are part of a group and those that are not.
> Isn't <form:frame> what we have for this purpose?
> Actually, I think we have to differ between grouping controls logically,
> and something that allows us to specify the "1 out of n" relation of
> radio buttons. Both a different topics, and I would not want to mix them.
> > Also, why would there not be a group concept for other things like radio
> > buttons. I can imagine a form where a set of
> > checkboxes are related to an operation and could be grouped semantically.
> > <form:form form:name="Standard" >
> > <form:fixed-text form:name="LabelField1" form:for="foo"
> > form:label="LABEL 1" />
> > <xform:group id="foo">
> > <form:checkbox>
> > ...
> > </xform:group>
> > You could then make statements on radio buttons as members of the group
> > where they can only be single select radios.
> To be honest, I don't understand this example. Can you please provide
> some more details.
Michael, this is a rough example of a label labelling a group of check boxes without the visual restrictions of using <form:frame>. We actually have two
The problem we run into is that label can label multiple ids. So, the same label can take a radio button as well as a checkbox, etc. So, if ODF 1.2
supplies an attribute on a radio button that indicates it is a member of a group and a label labels it you can then assign another id to the label (say
for a checkbox). There is nothing in the ODF specification indicating that a label can only take one id (if you could you could assign it to the radio button). There
is nothing in the ODF specification that says that if you label a radio button it labels the associated group. So, at this point you can have the same label label a radio button, a checkbox, etc. This makes no sense.
I agree with your point that we could use <form:frame> for the group of checkboxes but that requires all the checkboxes to be visibly part of the same frame. One
of the featurs of xforms is that form elements may appear anywhere on the page and be semantically grouped. With the radio button proposal you have on the 1.2
wiki you are suggesting something very similar.
What I would like to see is a way for ODF 1.2 to label a single group without getting into a trouble by allowing multiple ids on the form:for attribute that of which not all
ids may be a member of the group and may in fact not include all members of the group. The label should just be to the group.
I would also like the TC to consider the fact by adding a grouping attribute to radio buttons you have introduced a grouping concept similar to xforms which deviates from
the <form:frame> implicit grouping. You might consider a more flexible grouping concept.
My suggestion for introducing <xforms:group> was to allow ODF to allow form controls anywhere on the page to be semantically group together and then use text with labelling properties to label the group.
> Best regards
> Michael Brauer, Technical Architect Software Engineering
> Sun Microsystems GmbH Nagelsweg 55
> D-20097 Hamburg, Germany firstname.lastname@example.org
> http://sun.com/staroffice +49 40 23646 500
> Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
> D-85551 Kirchheim-Heimstetten
> Amtsgericht Muenchen: HRB 161028
> Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
> Vorsitzender des Aufsichtsrates: Martin Haering
> 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: