Re: [office-accessibility] radio button groups

[Jonathan Pryor <jpryor@novell.com>]

The OOXML interop issue has nothing to do with frames, but it originally seemed to me that frames might provide a solution to my OOXML interop issue, so I thought I'd interject. :-)

(And if I'm really lucky maybe a solution to the OOXML interop & frame issues will have a common solution.)

The OOXML interop issue: radio button group names.

Within OOXML, OLE radio buttons have two values that I'm particularly concerned about:

1. The control id (The /worksheet/controls/control/@name value within worksheet XML).
2. The group name (the /ax:ocx/ax:ocxPr[ax:name="GroupName"]/@ax:value value within e.g. xl/activeX/activeX1.xml).

This is akin to the HTML <input/> control, where //input/@id is the control id (i.e. a control identifier, unique to the page, which can be used with scripting) and where //input/@name is the group name (i.e. specifies which radio buttons belong to the same group).

My problem is that ODF doesn't have these as separate entities, they are merged as the //form:radio/@form:name value, which is used for both scripting access and for radio button grouping.  (This also complicates scripting access, as Radio buttons can't be accessed "by name," like other controls, as multiple radio buttons share the same name.)

The end result being that when Calc imports a .xls file containing radio/option buttons, Calc ignores the group name information, thus losing all groups present in the input document.  (This is about the only sensible thing to do, anyway, as the .xls radio buttons also contain a Name property which is imported as ODF's //form:radio/@form:name value.)

Thus, the question: how to properly handle importing existing .xls documents containing radio buttons?  OOXML import/export will need to deal with the same issues as well.

A prior attempt (http://www.openoffice.org/issues/show_bug.cgi?id=30823) was to add an ODF //form:radio/@form:group-name attribute, so that the control name and radio button group could be separate, making things closer to what .xls/OOXML expect.

Sadly, this proposal was rejected, and I've since been at a loss for how to solve this within ODF in a manner that won't break backward compatibility (which was one of the supposed issues with the //form:radio/@form:group-name approach, as I understand it).

So it occurs to me that frames may provide a solution for my group-name issue, though on further thought that might not be the case.  As I understand it, //form:radio/@form:name can't be changed to contain something other than the group name, as that may break existing apps, but at the same time it can't be changed to contain something other than a control Id, as it may break existing apps, but I need a way to store the control Id and group name separately.  Perhaps frames could be used, but for frames to be used we'd still need to change the semantics of //form:radio/@form:name, which as far as I know isn't acceptable at this time.

Apologies for the rambling...

- Jon

On Mon, 2008-11-17 at 08:50 -0600, Pete Brunet wrote:

Hi Florian and Jon, I am not understanding the OOXML interop issue.  Please tell us more.  No matter how the button group is expressed (ODF or OOXML) a best practice would be for each button group to be labelled in some manner either via individual labels or individual groups.  In case 1) a single frame around two unlabelled button groups would be confusing.  In case 2) I suppose there are cases where the surrounding context would be enough to compensate for a lack of a label/group, but having a label/group wouldn't be a detriment.  

1) Problem:  A frame around two radio button groups.  
Solutions:  Add labels for each group and/or use two groups

2) Problem: A button group with no group and no label
Solutions:  Add a label and/or a group

Pete Brunet
                                                                         
IBM Accessibility Architecture and Development
11501 Burnet Road, MS 9022E004, Austin, TX 78758
Voice: (512) 838-4594, Cell: (512) 689-4155
Ionosphere: WS4G

"Florian Reuter" <freuter@novell.com>

11/17/2008 08:29 AM

To	<office-accessibility@lists.oasis-open.org>, Pete Brunet/Austin/IBM@IBMUS
cc	"Jon Pryor" <JPryor.AMERICAS5.AMERICAS@novell.com>
Subject	Re: [office-accessibility] radio button groups

Hi Pete,

Jon is the original proposal writer which was written with OOXML interop in mind. He just joined the SC and he hopefully has some insights.


Maybe we can find a way to ensure accessibility and also preserve the original interop goal.


Thanks for the review,


~Florian

>>> Pete Brunet <brunet@us.ibm.com> 11/12/2008 11:08 PM >>>

I think authors need the flexibility to use frames an labels in the manner that best fits from the perspective of the UI designer.  I thought of eight scenarios.  Three of them are problematic and should be addressed as indicated below:

1) Problem:  A frame around two radio button groups.  
Solutions:  Add labels for each group and/or use two groups

2) Problem: A button group with no group and no label
Solutions:  Add a label and/or a group

3) Problem:  A label must label controls in the same radio button group.  Although it doesn't make sense, ODF allows this.

An example follows where the first label is labeling controls 3 and 4 but controls 3 and 5 are in the first button group.  This is a contrived but apparently legal example that was submitted by Malte.

<form:form form:name="Standard">
 <form:fixed-textform:name="LabelField1"form:for="control3,control4"form:id="control1"form:label="LABEL 1" />
 <form:fixed-textform:name="LabelField2"form:for="control5,control6"form:id="control2"form:label="LABEL 2" />
 <form:radio form:name="RadioGroup1"form:id="control3"form:label="Grp1-1"></form:radio>
 <form:radio form:name="RadioGroup2"form:id="control4"form:label="Grp1-2"></form:radio>
 <form:radio form:name="RadioGroup1"form:id="control5"form:label="Grp2-A"></form:radio>
 <form:radio form:name="RadioGroup2"form:id="control6"form:label="Grp2-B"></form:radio>
</form:form>

Malte,

Are 1) and 2) detectable by the UA?  If so our guideline can target the UA developer.  Otherwise we need to cover this in a guideline aimed at the content author.

Can the situation in 3) be eliminated via the schema so that it would be illegal markup?

If it's helpful here are the other five non-problematic scenarios:

1) group with a frame
2) group with a label
3) group with a frame and label
4) two groups in one frame but each group having a label
5) two groups with no outer frame and each group having a label  (it's really the same as case two)

Pete Brunet
                                                                       
IBM Accessibility Architecture and Development
11501 Burnet Road, MS 9022E004, Austin, TX 78758
Voice: (512) 838-4594, Cell: (512) 689-4155
Ionosphere: WS4G