- From: ALAN SMITH <alands289@gmail.com>
- Date: Mon, 2 May 2016 10:21:53 -0400
- To: Detlev Fischer <detlev.fischer@testkreis.de>, "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>, "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>, "jon.avila@ssbbartgroup.com" <jon.avila@ssbbartgroup.com>
- Message-ID: <5727627c.84c00d0a.a5ac4.ffff92f8@mx.google.com>
Detlev, I appreciate you comment. I might add that H81 is not much help either. Especially with the user agent note: https://www.w3.org/WAI/WCAG20/Techniques/ua-notes/html#H81 H81: Identifying the purpose of a link in a nested list using link text combined with the parent list item under which the list is nested Although the context information is programmatically associated with the link, assistive technology lacks commands for reading the parent list item without moving focus away from the link. Regards, Alan Sent from Mail for Windows 10 From: Detlev Fischer Sent: Monday, May 2, 2016 10:02 AM To: w3c-wai-gl@w3.org; w3c-wai-ig@w3.org; jon.avila@ssbbartgroup.com Subject: Re: Not hearing grouping labels for checkboxes, radio buttons and link lists. Just note that H80 is no longer listed as Sufficient Technique, just as Advisory. For those scratching their heads, "Understanding Techniques" ( https://www.w3.org/TR/2014/NOTE-UNDERSTANDING-WCAG20-20140916/understanding-techniques.html ) says about Advisory Techniques "they may not be sufficient to meet the full requirements of the success criteria" which implies that they may well be, given the right circumstances. It is now probably down to the judgment of any specific case to determine if the use of H80 alone can count as sufficient to meet SC 2.4.4 Link Purpose. Or put differently, the use of H80 cannot automatically considered insufficient for meeting the SC - at least that is my interpretation of the fog of disclaimers that has grown around the Techniques in the last couple of years. Detlev -- Detlev Fischer testkreis c/o feld.wald.wiese Thedestr. 2, 22767 Hamburg Mobil +49 (0)157 57 57 57 45 Fax +49 (0)40 439 10 68-5 http://www.testkreis.de Beratung, Tests und Schulungen für barrierefreie Websites Jonathan Avila schrieb am 02.05.2016 13:10: > > Ø 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. > > > > Alan, sufficient technique H80: Identifying the purpose of a link using link text combined with the preceding heading element <https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20160317/H80> allows link purpose SC 2.4.4 to be met (when accessibility supported) with preceding headings because some screen readers support the announcement of the current heading with commands that don’t move your location such as insert+t to announce the page title (and heading). > > > > Jonathan > > > > > Jonathan Avila > > Chief Accessibility Officer > > SSB BART Group > > jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com> > > 703.637.8957 (Office) > > > > Visit us online: Website <http://www.ssbbartgroup.com/> | Twitter <https://twitter.com/SSBBARTGroup> | Facebook <https://www.facebook.com/ssbbartgroup> | Linkedin <https://www.linkedin.com/company/355266?trk=tyah> | Blog <http://www.ssbbartgroup.com/blog/> > > Check out our Digital Accessibility Webinars! <http://www.ssbbartgroup.com/webinars/> > > > > > > From: ALAN SMITH [mailto:alands289@gmail.com] > Sent: Sunday, May 01, 2016 10:11 PM > To: David MacDonald; 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: 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 <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 > > > > > From: David MacDonald <mailto:david100@sympatico.ca> > Sent: Friday, April 29, 2016 9:19 PM > To: Gregg Vanderheiden RTF <mailto:gregg@raisingthefloor.org> > Cc: Katie Haritos-Shea <mailto:ryladog@gmail.com> ; IG - WAI Interest Group List list <mailto:w3c-wai-ig@w3.org> ; GLWAI Guidelines WG org <mailto:w3c-wai-gl@w3.org> ; Laura Carlson <mailto:laura.lee.carlson@gmail.com> ; John Foliot <mailto:john.foliot@deque.com> ; Andrew Kirkpatrick <mailto:akirkpat@adobe.com> ; Joshue O Connor <mailto:josh@interaccess.ie> ; Denis Boudreau (gmail) <mailto:dboudreau01@gmail.com> ; Kevin White <mailto:kevin@dewoollery.co.uk> > 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 <https://github.com/w3c/wcag/issues/173> > > > Cheers, > David MacDonald > > > > CanAdapt Solutions Inc. > > Tel: 613.235.4902 > > LinkedIn <http://www.linkedin.com/in/davidmacdonald100> > > > twitter.com/davidmacd <http://twitter.com/davidmacd> > > GitHub <https://github.com/DavidMacDonald> > > www.Can-Adapt.com <http://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 <http://www.davidmacd.com/disclaimer.html> > > > > > > On Fri, Apr 29, 2016 at 6:57 PM, Gregg Vanderheiden RTF <gregg@raisingthefloor.org <mailto: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 <mailto:david100@sympatico.ca> > wrote: >>> >>> >>> >>> >>> >>> I spent 10 hours on Issue 173 trying to those 3 things ... >>> >>> >>> https://github.com/w3c/wcag/issues/173 <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 <tel:613.235.4902> >>> >>> >>> LinkedIn <http://www.linkedin.com/in/davidmacdonald100> >>> >>> >>> twitter.com/davidmacd <http://twitter.com/davidmacd> >>> >>> >>> GitHub <https://github.com/DavidMacDonald> >>> >>> >>> www.Can-Adapt.com <http://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 <http://www.davidmacd.com/disclaimer.html> >>> >>> >>> >>> >>> >>> On Fri, Apr 29, 2016 at 4:09 PM, Gregg Vanderheiden RTF <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org> > wrote: >>> >>> >>>> the biggest thing holding back documenting failures — is that it is a lot of work. >>>> >>>> >>>> >>>> >>>> >>>> have to explore it >>>> have to find out if there are ways to succeed while doing this >>>> 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 <mailto: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. >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > >
Received on Monday, 2 May 2016 14:22:22 UTC