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

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.

The lack of the grouping label – often a checkbox or radio button leading question – are not flagged by automatic checking tools. So, for “What is your favorite ice cream? Chocolate or vanilla, as long as the radio button or checkbox announces chocolate and vanilla, it passes. But the user never hears the question that they use to hear when fieldsets and legends were used.
Same with multiple groups of links as seen on google.com/services
The groupings of the links are Get on Google, Advertise, Work Smarter, Earn Money and Measure & Learn.
As the blind user tabs through this section they only hear the links below these headings.

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.

Any thoughts?

Alan



Sent from Mail for Windows 10

From: David MacDonald
Sent: Friday, April 29, 2016 9:19 PM
To: Gregg Vanderheiden RTF
Cc: Katie Haritos-Shea; IG - WAI Interest Group List list; GLWAI Guidelines WG org; Laura Carlson; John Foliot; Andrew Kirkpatrick; Joshue O Connor; Denis Boudreau (gmail); Kevin White
Subject: Re: Let's add an approved date field to Failures and Techniques

The legacy aspect in this particular situation is this...

When we wrote WCAG no evaluator failed a page under 1.3.1 for not informing a user programmatically that they were entering a header, footer, navigation region or Main content. 

But in hind site we *should* have. It was an information and relationship that was visual but not perceivable to blind people except by exploring around and guessing. Soon after, Landmarks came out and solved the problem. They took minutes to add to entire sites in most cases and allowed the blind user to know when they entered that section or not and also allowed them to easily jump to that region 2.4.1

The issue was brought up by Paul Adam who felt there should be a failure. After originally arguing against the failure, I thought it through and felt there was a basis for a proposal. 
technologies relied upon on most sites include HTML 5.
Hence, the proposal for a failure of 1.3.1 filed as issue 1.3.1
 Legacy sites could do this with text or headings... however, there is the problem that none of use failed these sites back in 2008 so why would we fail them now.

And that is what torpedoed the failure... some argued it was too hard to do... some argued that old sites would suddenly fail...

My thought is:
- In hindsight we should have failed pages for not informing users that they were entering a section of the page that visually set apart. It is an information and relationships issue
- There are hardly any old sites around from 2008
- This is easy to fix now
- It has a high impact on end users.

Hence I wrote https://github.com/w3c/wcag/issues/173


Cheers,
David MacDonald
 
CanAdapt Solutions Inc.
Tel:  613.235.4902
LinkedIn 

twitter.com/davidmacd
GitHub
www.Can-Adapt.com
  
  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy

On Fri, Apr 29, 2016 at 6:57 PM, Gregg Vanderheiden RTF <gregg@raisingthefloor.org> wrote:
 but voting a failure through is almost impossible especially in the light of legacy sites..

I am confused.

Failures should only be documentation of things that WCAG required but are not met by some condition….. hence a failure.

If we document a failure today based on WCAG — it was always a failure.   And legacy sites failed it or not back in 2008 whether we documented it or not.    
And legacy sites that didn’t fail WCAG in the past — won’t fail any failure we document today.   
We cannot create any new failure conditions - we can only document what was always a failure under WCAG.

The only exceptions I can think of  (e.g. it fails today because new technologies now…. ) would only mean that a failure would have to be defined and scoped properly. 


Now I agree that creating Failures ( and creating techniques)  is a LOT of work.    Ive done many and there is no getting around the fact that it is a lot of work.  
but I miss the legacy content aspect.  

gregg 

On Apr 29, 2016, at 4:39 PM, David MacDonald <david100@sympatico.ca> wrote:

I spent 10 hours on Issue 173 trying to those 3 things ...
https://github.com/w3c/wcag/issues/173
I rewrote it numerous times addressing concerns... changing scope trying to accommodate the legacy question...

Yes, it's a lot of work, and I think that work was reasonably well done, but voting a failure through is almost impossible especially in the light of legacy sites...I trust the group conscience, and am not going to push it, except to hope that we can provide add some common failures in 2.1... 


Cheers,
David MacDonald
 
CanAdapt Solutions Inc.
Tel:  613.235.4902
LinkedIn 

twitter.com/davidmacd
GitHub
www.Can-Adapt.com
  
  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy

On Fri, Apr 29, 2016 at 4:09 PM, Gregg Vanderheiden RTF <gregg@raisingthefloor.org> wrote:
the biggest thing holding back documenting failures — is that it is a lot of work.

1. have to explore it
2. have to find out if there are ways to succeed while doing this
3. have to qualify it properly ( If xxxxxx is used ….) 
then you have to write it up 

lot of work. 


gregg 

On Apr 29, 2016, at 1:53 PM, David MacDonald <david100@sympatico.ca> wrote:


I think 4 failures in 8 years is fewer than the common failures that we as a11y evaluators have seen show up on many of our reports since that time.