- From: David MacDonald <david100@sympatico.ca>
- Date: Tue, 26 Nov 2013 05:37:43 -0500
- To: "'Steve Faulkner'" <faulkner.steve@gmail.com>, "'Adrian Roselli'" <Roselli@algonquinstudios.com>
- CC: "'Janina Sajka'" <janina@rednote.net>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>, "'WCAG WG'" <w3c-wai-gl@w3.org>, <public-comments-wcag20@w3.org>, "'Gregg Vanderheiden'" <gv@trace.wisc.edu>, <kirsten@can-adapt.com>, <kirsten@can-adapt.com>
- Message-ID: <BLU0-SMTP7470C640E583DD1C898040FEEC0@phx.gbl>
A few responses to Jared's comments, although I personally agree with his position of little or no change to F65, I would not agree with the general comments about WCAG which I think are characteristically are overly harsh: > Why has nobody considered the implications and harmonization of years-old W3C specifications (two of which are accessibility-specific) that prescribed techniques that directly resulted in a WCAG failure until now? This statement actually demonstrates a lack of distinction between a validation error and a WCAG error, which concerns me because if an accessibility expert misses this distinction, which James Craig pointed out in the first post on this issue, what can we expect from Johnny lunch box developers? The 2009 statement was actually not a "specification" and its recommendations were towards HTML5 which doesn't appear to have been adopted. > it seems that recent updates to WCAG techniques documents simply reflect the current state of AT support, rather than best practice and requirements for optimal accessibility. WCAG is simply becoming a codification of "what works today" versus "recommendations for making Web content more accessible" (sentence one of the WCAG 2.0 document). The two are not mutually exclusive, if it doesn't work today, then we cannot make a technique to advocate for it. WCAG techniques are all about what works today rather than what should work... and it's always been that way, because if the technique is not accessibility supported today ... it will not work... the place for experimentation, and innovation is not in WCAG techniques... WCAG is about what works today for accessibility and this how we make "web content more accessible" so naturally we will follow trends in our techniques. Further, I suggest Jared join our group and help write them so there can be a quicker turn around ... we *are* a volunteer group like every other Spec... Cheers, David MacDonald CanAdapt Solutions Inc. Tel: 613.235.4902 <http://ca.linkedin.com/in/davidmacdonald100> http://ca.linkedin.com/in/davidmacdonald100 <http://www.can-adapt.com/> www.Can-Adapt.com Adapting the web to all users Including those with disabilities From: Steve Faulkner [mailto:faulkner.steve@gmail.com] Sent: November 26, 2013 4:43 AM To: Adrian Roselli Cc: Janina Sajka; David MacDonald; HTML Accessibility Task Force; WCAG WG; public-comments-wcag20@w3.org; Gregg Vanderheiden; kirsten@can-adapt.com Subject: Re: UNS: Re: WCAG considering amending F65 to NOT fail missing ALT text if title or aria-label is present Hi Adrian, Thanks for writing the post, I see the Jared Smith from WebAIM has commented, and I consider he has provided some useful feedback that we should consider: Jared Smith <http://webaim.org/> November 26, 2013 at 2:24 AM <http://blog.adrianroselli.com/2013/11/image-alt-exception-change-re-re-re.h tml?showComment=1385450686463#c8964124963439827855> First, I'm curious how we got to this point. Why has nobody considered the implications and harmonization of years-old W3C specifications (two of which are accessibility-specific) that prescribed techniques that directly resulted in a WCAG failure until now? That the working group is seemingly caught off guard and in argument over this is a bit alarming. Second, to partially answer that question, it seems that recent updates to WCAG techniques documents simply reflect the current state of AT support, rather than best practice and requirements for optimal accessibility. WCAG is simply becoming a codification of "what works today" versus "recommendations for making Web content more accessible" (sentence one of the WCAG 2.0 document). This leaves innovators of ARIA, HTML5, and tomorrow's technologies in a state of confusion regarding WCAG conformance until the working group deems that we've crossed some nebulous threshold of support and thus modifies failures to reflect this. But this doesn't happen until AFTER it's widely in use and, by definition, already supporting accessibility. This means a site that has zero accessibility issues due to modern (or not so modern) technology can fail WCAG today, then pass tomorrow based on a failure/techniques definition change. If WCAG is truly about recommendations and guidelines, it needs to be more forward looking than this. In short, WCAG is increasingly skating to where the puck is, not to where it will or should be. And this bring me to my third point, the working group needs to at last determine whether a failure as defined in techniques documents absolutely results in a failure at the normative WCAG level. I've asked several working group members this question and received varying responses ranging from "A page can have many failures, yet still be conformant if it meets the normative success criteria in other ways." to (as expressed just today by a former WCAG editor) "FAILUREs are things that are ALWAYs failures." So, which is it? Until this question is resolved, one cannot know the implications of modifying (or not) any failure language. And finally, regarding the F65 change itself... at this point, it's mostly irrelevant. My preference would be no or little change. But this is just one of many places in which ARIA and HTML5 techniques conflict with WCAG techniques and failures. Modern, dynamic web accessibility, I believe, can no longer be defined in such simplistic ways - by drawing a techniques/failures line in the sand, so to speak. End user accessibility just doesn't work that way. WebAIM's recommendations will not change - "Make things accessible to your users in the technologies they use, using HTML first, then ARIA, etc. to enhance and support that accessibility when necessary." If followed, and if the page meets the normative WCAG success criteria, whether the page matches increasingly complex and conflated WCAG techniques and failures doesn't really matter. -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> On 25 November 2013 16:22, Adrian Roselli <Roselli@algonquinstudios.com> wrote: > -----Original Message----- > From: Janina Sajka [mailto:janina@rednote.net] [...] > Frankly, I'm unclear why you even took this discussion to Twitter. What did > you expect to gain and how are we to understand the value of any results? > What good does this do? What value does it add? I'd like to note that I wrote an overview on my blog yesterday [1] and also solicited feedback from the community. I don't consider this to be random voting, nor do I expect the respondents have all the context. I also know that my followers (all 2 of them) hold a similar view as I do, so I don't expect to hear a viewpoint different from my own. I do, however, hope to discover some nuggets (for either viewpoint) that maybe I had not considered that I can bring back here for discussion. I don't think lack of membership here precludes having a voice, though I do see the value in having somebody collecting that information to present back here. And for the record, I am against loosening alt attribute restrictions, as I was against it the last time it came around for discussion. 1. http://blog.adrianroselli.com/2013/11/image-alt-exception-change-re-re-re.ht ml
Received on Tuesday, 26 November 2013 10:38:21 UTC