W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2013

Re: WG discussion: Nov 5, 2013: role=group technique

From: Sailesh Panchang <sailesh.panchang@deque.com>
Date: Thu, 7 Nov 2013 09:29:32 -0500
Message-ID: <CAJi9CqoQwvGR6EGFu6ZnTFwDe06UM1sSw2CvFaVJ+VHXmpF=Nw@mail.gmail.com>
To: Joshue O Connor <joshue.oconnor@cfit.ie>
Cc: Sailesh Panchang <spanchang02@yahoo.com>, WCAG <w3c-wai-gl@w3.org>
Hello Joshue,
>> I think Kathys comment is a fair observation, unless it is a common pattern. Maybe >>we need a third example which uses the neutral <div> elements also. This would also >>help to highlight the use of the ARIA grouping roles without any potential confusion >>over whether 'this element is valid on a table or not'.
I do not see where you see potential confusion. This example also
demonstrates correct use of role=presentation and the dtechnique
documentation does state the role=group technique is suitable when
fieldset-legend method cannot be used due to some UI design
constraints.   This is valid code so it is not fair for one to wonder
if  role=group is valid in a table. In fact it is valid even without
role=presentation. This is again a case of one reading  something into
the specs when the specs do not say so at all.
If someone has a personal preference in the matter i.e. whether to use
role=group in a table or not, it is a different matter.
I have seen multiple situations where developers cannot change the
design  where a form is in a table and are unable to use
fieldset-legend to group  related controls. The technique that was
first submitted correctly reflected this in its title:
"Marking logical group of fields using role=group / role=radiogroup
when using fieldset-legend is not practical"
Maybe that should be reinstated?

Sure one can use  role=group/radiogroup if one codes custom form
controls that cannot be labeled without ARIA or grouped with
fieldset-legend are still in a table-less container. Perhaps someone
might take an action item to create 'Example 3' for that situation.
 Regards,
Sailesh Panchang




On 11/7/13, Joshue O Connor <joshue.oconnor@cfit.ie> wrote:
> Sailesh Panchang wrote:
>> Refer: Using the group role to identify related form controls
>> WG call of Nov 5, 2013 discussions
> [...]
>> Sailesh response: I changed the role=group to role=radiogroup.
>> The reason I had used role=group  was because the validator gave a weird
>> error from the time I first used this technique in Spring 2012  till
>> recently:
>> - radiogroup must only have radio element in it.
>> I discovered this was because of the span element for the aria-labelledby
>> text.
>> Looks that validator bug is now fixed!
>
> Great stuff, thanks Sailesh.
>
>> The technique as documented suggests its use for standard HTML controls
>> when there are constraints on use of fieldset-legend.
>> That's why it is in a layout table (as you did note the use of
>> role=presentation).
>
> Ok, thanks. If this is the case, then there needs to be a brief summary
> of the use case in the "Example 2" overview - as this isn't currently
> clear.
>
>> Using DIVs will need CSS to maintain presentation format  which is the
>> illustrative constraint here.
>
> Thats fine.
>
>> Also see the text above the example  in section 7 of
>> http://mars.dequecloud.com/demo/form-markup.htm
> [...]
>> So it is not appropriate to replace the table with DIVs in this example .
>> Stating 'I do not like the use of group in a TD'  is a weak argument when
>> the code is valid, properly uses role=presentation, the method is AT
>> supported and the reason for the markup is documented.
>
> I think Kathys comment is a fair observation, unless it is a common
> pattern. Maybe we need a third example which uses the neutral <div>
> elements also. This would also help to highlight the use of the ARIA
> grouping roles without any potential confusion over whether 'this
> element is valid on a table or not'.
>
> Thanks
>
> Josh
>
>
Received on Thursday, 7 November 2013 14:30:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:32:54 UTC