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

Refer: Using the group role to identify related form controls
WG call of Nov 5, 2013 discussions

16:48:13 <AWK> Kathy raises issue about role=group on td element
16:48:25 <AWK> BB; also a little concerned about this
16:48:29 <AWK> JO:
16:48:44 <AWK> JO: What's the problem?  The table has role=presentation
16:49:02 <AWK> JN: This would be a bad idea without the role=presentation
16:50:26 <AWK> JN: Suggests making example 2 a handful of divs instead of a layout table.
16:50:42 <AWK> JO: good idea, no good reason to have the table.
16:52:05 <AWK> JO: We would need to ask Sailesh to change the example for the live example to match

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!

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).
Using DIVs will need CSS to maintain presentation format  which is the illustrative constraint here.
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. 
Regards,
Sailesh Panchang

Received on Thursday, 7 November 2013 03:51:37 UTC