- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Thu, 7 Nov 2013 09:29:32 -0500
- 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