Re: [office-accessibility] radio button groups

[Pete Brunet <brunet@us.ibm.com>]

Hi Jon, I suspect you'll have better
luck getting help with this issue through the office list (office@lists.oasis-open.org).
 -Pete

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

Jonathan Pryor <jpryor@novell.com>

11/17/2008 01:16 PM

To	Pete Brunet/Austin/IBM@IBMUS
cc	Florian Reuter <freuter@novell.com>, office-accessibility <office-accessibility@lists.oasis-open.org>
Subject	Re: [office-accessibility] radio button groups

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