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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-accessibility message

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


Subject: radio buttons wrap-up


OK,

here is my wrap-up of radio buttons, and the relation to the proposal
for introducing <form:group-name>:

http://wiki.oasis-open.org/office/Grouping_for_Radio_Elements

The proposal states that ODF would not provide a way to group radio
buttons, which is not true.

Grouping radio buttons via the <form:name> attribute works well, like in
HTML.

In our previous discussions we very often mixed up 2 things:

1) The button group
2) The label/frame/relation

The button group:
The grouping is done via form:name, and it works independently from any
any other (visual) elements.

The label/frame/relation:
The radio buttons as well as other form controls can be contained in
some <form:frame>. The <form_frame> can have some <form:for> to list all
elements included, but: It can also contain multiple radio button groups
as well as other elements.

So for me the frame is only something for visualizing the group, and for
having relations which can be expose via AT or be used by other
processing tools.

I think <form:name> on the radio button is the only way to define groups.

For the implementor guide lines I would recommend apps to automatically
use the same form:name for all radio buttons in a frame when created by
the author, but allow the author to overwrite.

Only the fact that multiple radio buttons are contained in a frame
doesn't necessarily mean that they have to be treated as a group.

My answer on the <form:radio-group> proposal:
If we would do ODF from scratch, I would use <form:group-name> instead
of <form:name> to allow authors to give elements unique names, which can
be use for identifying the radio buttons in forms and XML processing.
But ODF handles it like HTML now, so for this historical reason the
<form:name> is used for that purpose.

I wouldn't introduce an other attribute <form:group-name> now.
It would be redundant to <form:name>.
For compatibility, people would be forced to put the same value in both
attributes then.

To comment on Rich's suggestion that it should be possible to label a
group instead of individual IDs, because people could mess up IDs:
For a label, it doesn't make a difference whether you can reference all
elements with same <form:group-name> or with same <form:name>.

Conclusion:
a) <form:name> does the job, <form:group-name> is redundant so
   don't introduce it.
b) allow <label-for> to contain elements names instead of IDs, if you
   fear people could mess up IDs
   But: Messing up IDs can happen on many different places, so I think
   it's not reasonable to address this special case

Rob's mail from Aug 4 2008 also states:
> 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.

=> issue with "alternative way" and "different use".

And to answer his concrete questions from Aug 5 2008:

> 1) Do we have a problem with radio button accessibility in ODF 1.1? 

No

> 2) If so, does this proposal address that problem?

Does not apply, see 1

> 3) If not, is this proposal allow implementations to express something
> that cannot already be expressed by the existing grouping mechanism?

No

> 4) If so, what new does it allow implementations to express?

Does not apply, see 3


Attached are my old sample documents.

Only radiogroups1.odt was made with OOo. The other documents are hand
crafted, because OOo UI doesn't allow me to author the ODF document this
way.
Please notice (in OOo) that grouping logic only uses the <form:names>,
not the <form:for>.
PDF Export via OOo and then using Adobe Reader to view the documents
shows exactly the same grouping behaviour in both applications. (But I
don't know how the PDF Tags look like...)

PS: One thing which is not clear to me, but I am sure it's possible and
Michael or somebody else might be able to explain:
When all buttons in the same group have the same name, how to I address
the different elements? (xml:id?)
I guess there is some standard way, otherwise forms wouldn't work in OOo...

radiogroups1.odt

radiogroups2.odt

radiogroups2b.odt

radiogroups3.odt



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