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


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

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

Hi Jonathan,

thanks for looking at this so quickly :)

BTW - before I start:
We talk about ODF here, so please avoid phrases like "You can say
that you are like HTML, but you're not".
This sounds like "you/ODF is this way, but we/OOXML would like...".


In the end we both agree, it must be possible to have different
identifiers for defining the group and for accessing the individual element.

So we might introduce an additional attribute for the group, or for the ID.

You would like to add something for group, because it's more like in OOXML.

I suggest to add something for ID - for compatibility reasons, and maybe
it would also be/stay more similar to HTML.

My concerns with compatibility:

Grouping support shouldn't break in existing applications.
Of course you can provide patches like suggested below for different
apps, but this doesn't help older apps loading newer documents.
And you can't know how many apps/tools out there already rely on the
existing mechanism.

I must admit that my suggestion is mainly based on technical/practical

From an aesthetic point of view I would more like the group-name ;)


PS: I think we all agree that this is not an Accessibility issue, so the
main ODF list is probably the better place to discuss this...

Jonathan Pryor wrote, On 12/ 4/08 06:23 AM:
> 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
> ---------------------------------------------------------------------
> 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 

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