Re: Not hearing grouping labels for checkboxes, radio buttons and link lists.

On 02/05/2016 03:11, ALAN SMITH wrote:
> David, et all,
>
> I’ve questioned the lack of the group label for checkboxes and radio
> buttons when fieldsets and legends are not used (today, most
> designers/developers do not use them). Then a very similar item are link
> lists which are grouped under different headings – often found in
> footers. These groupings of links are specific to the heading above them
> and blind users do not see the grouping that visual users do.

Arguably the heading should be programmatically determinable as being 
part of the "context" (with regards to 2.4.4 Link Purpose (In Context)).

> The lack of the grouping label – often a checkbox or radio button
> leading question – are not flagged by automatic checking tools.

Because it's not possible for automated tools to unambiguously determine 
whether a checkbox/radio button's label is not sufficient. Not all 
checkboxes/radio buttons *need* a grouping label, if their label is 
explicit enough (or if any of the other possible ways of providing 
naming/labelling, like additional aria-label, aria-labelledby, 
aria-describedby, etc are being used).

[...]

> To me it is a violation of 1.3.1 ( Info and Relationships) not to
> announce the checkbox/radio button groups leading
> question/statement/instructions and the link list headings that identify
> the grouping of these links.
>
> The technique “H71: Providing a description for groups of form controls
> using fieldset and legend elements” and
>
> It goes on to say: “Grouping controls is most important for related
> radio buttons and checkboxes. A set of radio buttons or checkboxes is
> related when they all submit values for a single named field. They work
> in the same way as selection lists, allowing the user to choose from a
> set of options, except selection lists are single controls while radio
> buttons and checkboxes are multiple controls.”
>
> Yet it makes no mention of grouping methods other than fieldset and
> legends and it also does not state anything about link lists which are
> also single controls like select lists.

For link lists, I'd say 2.4.4. provides some initial guidance at least. 
For other form controls, if the label/name of the control itself is not 
sufficient, then you're looking at a failure of 4.1.2 Name, Role, Value

There's a danger of lumping all sorts of things under 1.3.1 here. 
Sometimes a simple HTML heading is/should be sufficient, without 
requiring explicit association of all following links/form controls with 
that particular bit of heading text - though again this comes down to 
the individual situation.

P

p.s.: a small request to reduce duplicate/triplicate emails being fired 
at people on the list - when replying to a thread, would it be possible 
for people to edit the list of recipients so that, if it's a reply to 
the mailing list, it's just sent to the mailing list, rather than "Reply 
all" which then sends emails to both the list AND the person on the list 
you're responding to (and then, as the conversation continues and 
everybody else does a "Reply all", ends up with emails sent to half a 
dozen individuals on top of being sent to the list)?
-- 
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Monday, 2 May 2016 09:10:00 UTC