Re: [office] Re: [office-accessibility] Re: [office] Re: [office-accessibility]radio buttons wrap-up

[Richard Schwerdtfeger <schwer@us.ibm.com>]

response below


Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
blog: http://www.ibm.com/developerworks/blogs/page/schwer

Jonathan Pryor <jpryor@novell.com> wrote on 12/04/2008 11:14:37 AM:

> Jonathan Pryor <jpryor@novell.com>
> 12/04/2008 11:14 AM
>
> To
>
> Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>
>
> cc
>
> office TC <office@lists.oasis-open.org>, office-
> accessibility@lists.oasis-open.org, Robert Weir/Cambridge/IBM@Lotus
>
> Subject
>
> [office] Re: [office-accessibility] Re: [office] Re: [office-
> accessibility] radio buttons wrap-up
>
> On Thu, 2008-12-04 at 11:41 +0100, Michael Brauer - Sun Germany - ham02
> - Hamburg wrote:
> > If I recall it correctly, then the way it works in HTML is as follows:
> >
> > - Radio buttons are indeed grouped by their name.
> > - For Javascript, all radio buttons that have the same name are combined
> > into an array, so that the access to the individual button is possible.
> > - There is further the possibility to access radio buttons like any
> > other HTML element by their ID attribute.
>
> That is correct.
>
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.

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.

Seems like we are being too limiting here with the use of groups.
 
> > ODF like HTML uses the name for grouping.
> > In ODF 1.0/1.1 we had a form:id attribute for all controls, including
> > radio buttons. We have consolidated that for ODF 1.2, so that these now
> > have an xml:id.
> >
> > That means: It is possible to identify controls by their ID, or by their
> > name (which is also used for grouping). And it is in particular possible
> > to assign an ID to a radio button in addition to a name. I'm therefore
> > not sure if I do understand what is missing here, or why we should
> > require a third name or ID, which in any case does not make things easier.
>
> What's missing is that I didn't know about the addition of xml:id, nor
> did anyone else I conferred with.  xml:id should be a workable answer,
> and I'll work on supporting this.
>
> > Well, it is true that the script engine of OpenOffice.org does use the
> > name of controls to access them rather then their ID and that there
> > currently is no UI support for xml:id. But these are details of the
> > implementation. The script engine may also search for the ID of controls
> > if this is more appropriate.
>
> A related question is one of naming: is it acceptable within the script
> engine to have two different names for the same control?  If not, then
> xml:id could pose problematic.  I don't know if the ODF standard says
> anything about this scenario.
>
> Thanks,
>  - Jon
>
>
>
> ---------------------------------------------------------------------
> 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
>
>