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

[Jonathan Pryor <jpryor@novell.com>]

And to step in a little here...

On Wed, 2008-12-03 at 19:29 +0100, Malte Timmermann wrote:
> 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
> 
> Grouping radio buttons via the <form:name> attribute works well, like in
> HTML.

For some stuff I've tried to support, it does NOT work well, and it does
NOT work "like in HTML."  It works similar to HTML, but has an aliasing
problem which hampers interoperability efforts.

The problem, in a nutshell: scripting.

In HTML, controls are given a name for use with scripting with the id
attribute.  Radio buttons are grouped using the name attribute.
Consequently, HTML uses two different attributes for these two separate
purposes (giving scripting names to objects and grouping radio buttons).

In ODF, the //*/@form:name attribute is used for *both* providing an
identifier for scripting purposes AND for grouping radio buttons.

This is the fundamental problem with the current approach.  You can say
that you're "like HTML," but you're not, and you won't be until you
separate out the scripting name from the group name.

(For slightly more background, .xls files *do* follow HTML closer here,
and have the concept of Names (HTML id attribute) and GroupNames (HTML
group attribute).  However, due to the "aliasing" issue in ODF, Calc
only imports Name and completely ignores GroupName, thus leading to all
kinds of interoperability grief when the radio buttons rely on
GroupName...)

> In our previous discussions we very often mixed up 2 things:
> 
> 1) The button group
> 2) The label/frame/relation

And I'll add a 3rd thing: the name used for scripting purposes.

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

Which is fine (except for the aforementioned scripting "alias" problem).

> 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.

Which is also fine.

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

And I'd love to agree with you here.

However, if <form:name> is the only way to define groups (which it
currently is), what should be used to control scripting names?
Introduce a new attribute?  "Encode" the scripting name and the group
name into the same attribute, e.g. by separating them with a colon?
(Please, do NOT do this, it's just an example.)

Or, perhaps, use the form:name attribute for the scripting name and use
form:group-name for the group name. ;-)  </shameless-plug>

> 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.

Again, the way ODF currently handles it is most certainly NOT like how
HTML does it, precisely because of this issue.  HTML separates unique
names from radio grouping (id vs. name attributes), while ODF uses the
same attribute for both (form:name).

In my opinion, this is broken, and needs to be fixed.  I'm not entirely
sure _how_ to fix it -- my one proposal has been rejected -- but I'm
open to any alternative that would allow disambiguating control names
from radio group names.

> I wouldn't introduce an other attribute <form:group-name> now.
> It would be redundant to <form:name>.

It wouldn't, as stated above.

> For compatibility, people would be forced to put the same value in both
> attributes then.

Not necessarily; it's feasible to make form:group-name optional and have
apps "fallback" to using form:name of form:group-name isn't present.
This way, if they're both actually the same, only form:name needs to be
present.

> 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.

I disagree.

> 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.

Here's a statement of how to resolve it, as is implemented in an patch
at http://www.openoffice.org/issues/show_bug.cgi?id=30823:

If form:group-name is present, it's value takes precedence over the
form:name value.  If they're identical, it doesn't matter --
form:group-name still takes precedence.  If form:group-name isn't
present, form:name is used as the radio button group name.

> => 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

Yes, it disambiguates scripting names from group names, in accordance
with what HTML does and what is required for interoperability. 

> 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?)

Good question; iirc, you don't, as the xml:id isn't used by the
scripting infrastructure, and the form:id attribute is "transient" in
nature and can't be relied upon.

 - Jon