W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2016

Re: Let's add an approved date field to Failures and Techniques

From: Denis Boudreau (gmail) <dboudreau01@gmail.com>
Date: Thu, 28 Apr 2016 18:28:54 -0500
Cc: Laura Carlson <laura.lee.carlson@gmail.com>, John Foliot <john.foliot@deque.com>, Katie Haritos-Shea GMAIL <ryladog@gmail.com>, David MacDonald <david100@sympatico.ca>, Gregg Vanderheiden <gregg@raisingthefloor.org>, Andrew Kirkpatrick <akirkpat@adobe.com>, Joshue O Connor <josh@interaccess.ie>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>, IG - WAI Interest Group List list <w3c-wai-ig@w3.org>
Message-Id: <968B4D2F-371C-4DD9-8528-05FF07148D6E@gmail.com>
To: Kevin White <kevin@dewoollery.co.uk>
Please allow me to jump in. :)

> On Apr 28, 2016, at 15:04, Kevin White <kevin@dewoollery.co.uk> wrote:
>> On 28 Apr 2016, at 19:50, Laura Carlson <laura.lee.carlson@gmail.com <mailto:laura.lee.carlson@gmail.com>> wrote:
>> In my experience a developer is more likely to address an issue if I
>> can point him to the related W3C failure document.
> +1
> I have had a number of instances where I have evaluated websites where the development team were an agency separate from the actual client. The client would push for doing everything they could to be accessible and the agency would push back unless I could categorically identify the documented instance of the failure. I recall a couple of times when agencies stated that things I had marked as failures were simply my opinion.

-1.  Does that cancel out Kevin’s +1? ;p

While I understand what Laura and Kevin are saying, I think it would be a huge mistake to try and document every possible failure in web content and assign each of those failures to a certain SC. As the web evolves, as new technologies emerge, as assistive technologies catch up, and as content constantly changes, it would be impossible to keep up with such a list. There are far more ways to screw something up, than there are ways to build it right in the first place. I think it’s great that we have some failures examples to help us understand what the goals of the success criteria are, but these examples of failures should remain as such… examples of failures. A non-exhaustive list.

Developers might be more likely to address an issue if we can point them to a related W3C failure document, but what these same developers need to understand is that the guidance they seek lies in the techniques documents, not the failures documents. If these same devs are pushing back because these issues don’t directly map to failures, then these failure documents are creating a problem that was not expected in the first place. It’s either a matter of a) bad faith on the developers’ part, or b) complete lack of understanding about how the W3C documentation is supposed to help them. Either way, I believe it falls back on our shoulders to take another deep breath, and try to educate them, yet, one more time. The solution is not to document every single possible way through which devs could come up with unaccessible ways to implement WCAG.

We probably will never be able to completely break away from the divisions that ensue from conflicting interpretations. We see differences of opinion amongst ourselves all the time, when we’re aiming for the same goals. We definitely see it internally at Deque, and we often seat on discussion lists as well. It’s totally to be expected that people who don’t share our passion for accessibility would look at all of this, all of what they would need to do differently, and just push back and disagree. When an agency pushes back on interpretations and just call out the “it’s your opinion" card, or ask you to show them "proof" that something is really an issue by linking to a specific failure page, what they’re really saying is “I don’t want to hear about this, and I’ll do everything I can to discredit you”. 

It’s much easier to do that, than to actually accept that they may be clueless about what they need to do. Or that they may have made a mistake building that thing in the first place - whatever that thing may be.

If failures somehow became the way to measure how we find issues in pages, or what constitutes issues according to the different SC, we would quickly run into a situation where that list would not keep up with reality. Providing counter-examples has value, sure, but I think it would be a very slippery slope to try and document all of those potential “fails”. As a matter of fact, hearing how people are misinterpreting the use and value of the failures, and considering that we know the list is far form being exhaustive, I would actually campaign for entirely removing failures and any references to them from the W3C servers.

My $0.05 CDN - because we ditched the penny a while back in Canada.



Received on Thursday, 28 April 2016 23:29:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:36:57 UTC