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

With my WG and IG participant hat on…..I think the balance WCAG (whatever version) has had; normative spec, understanding doc, all 3 types of techniques (which includes failures) has actually been a good balance. Including, the wonderful new and improved resources from EOWG; tutorials, updated Quick Ref, etc.

 

But the changes that are needed for WCAG now are:

*         Publication in some official W3C manner of the content for extensions – from the 3 we have now and possibly more coming down the pike – in some manner (WCAG.next, extension only, whatever)

*         Best Practices that turn into new SC on each/the next WCAG iteration

*         Continued regular updates to Understanding and Techniques, which includes….

o   Documentation of a few additional failure techniques that take into account the new extension(s) content, new technologies and new interaction models – we have added hundreds of sufficient and advisory techniques to address new technologies and interaction models – and there is zero guidance on when you just get it wrong. Which is valuable information. In particular, I am thinking some ARIA failures would be useful. And, all of this may call for dating to address backward compatibility concerns.

​​​​​

And, in fact, I think that is what is going to happen and what *is* happening…..:-)

 

I, for one, am really excited to see the revitalization in these efforts!

 

 

* katie *

 

Katie Haritos-Shea 
Chair, WAI Interest Group
W3C Web Accessibility Initiative

 

JOIN US: Subscribe to the WAI IG list, send an email to  <mailto:w3c-wai-ig-request@w3.org?Subject=RE%3A%20Regulatory%20%2F%20Government%20requirements%20for%20-%20WCAG%20Next%20Possible%20Models&In-Reply-To=%3C280701d19425%241c219a00%245464ce00%24%40gmail.com%3E&References=%3C280701d19425%241c219a00%245464ce00%24%40gmail.com%3E> w3c-wai-ig-request@w3.org with “subscribe” as the subject line.

 

Cell: 703-371-5545 |  <mailto:ryladog@gmail.com> ryladog@gmail.com | Oakton, VA |  <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | Office: 703-371-5545

 

 <https://www.w3.org/WAI/> 

 

From: Denis Boudreau (gmail) [mailto:dboudreau01@gmail.com] 
Sent: Thursday, April 28, 2016 7:29 PM
To: Kevin White <kevin@dewoollery.co.uk>
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>
Subject: Re: Let's add an approved date field to Failures and Techniques

 

Please allow me to jump in. :)

 

 

On Apr 28, 2016, at 15:04, Kevin White <kevin@dewoollery.co.uk <mailto: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.

 

Cheers.

 

/Denis