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

Patrick and Jonathan,

I appreciate both of your replies and feedback.

1) Patrick, I like your association of the main grouping term/label/heading of link lists to 2.4.4 Link Purpose. I have always assumed it was a relationship and similar to the grouping requirement for radio buttons and checkboxes.

2) To your statement that “Not all checkboxes/radio buttons *need* a grouping label”  I would say that of the hundreds of  radio button and checkbox sets/groups that I have seen they all “did need” this grouping label to understand what is being asked of the user. Whether the there is a lack of legend/fieldset or aria-describedby, or other means, if some relationship is not there so that it is announced upon focus to the items the automated tools should find and flag it. Or at least flag it as something to manually checked.

3) I intentionally sent this to all on the chain as David had used the words so eloquently “It was an information and relationship that was visual but not perceivable to blind people except by exploring around and guessing.” I wanted as much feedback as possible as this is an important item that I see a gap in WCAG 2.0.

4) Jonathan, the fact that the link list I referenced did have the groupings/labels/headings tagged as html headings would help me understand your reply. However, most often they are not coded as html headings and in actual footer of the page https://www.google.com/services you can seen a good example where they code these lists as definition lists without html headings. 

5) The problem I find is that if there were coded headings, technically a blind person could use the jump to heading method as you mentioned. However, in real life, as they tab, they are just tabbing and listening to a series of links with no way of perceiving that there are even things that are on the screen for visual users to group and thus there is information and relationships that they are missing. They would not think that there would be h tags mixed in with these.

Best Regards,

Alan

Sent from Mail for Windows 10

From: Patrick H. Lauke
Sent: Monday, May 2, 2016 5:12 AM
To: w3c-wai-gl@w3.org
Cc: IG - WAI Interest Group List list; GLWAI Guidelines WG org
Subject: 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