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

I don't think anyone is suggesting trying to document *every* way to fail.
The suggestion is simply to do what we said we would do in WCAG 2, and that
is document *common* failures.

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.


Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

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 11:44 AM, Katie Haritos-Shea GMAIL <
ryladog@gmail.com> wrote:

> 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 GroupW3C Web Accessibility Initiative*
>
>
>
> *JOIN US: Subscribe to the WAI IG list, send an email to*
> *w3c-wai-ig-request@w3.org*
> <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> *with
> “subscribe” as the subject line.*
>
>
>
> *Cell: 703-371-5545 <703-371-5545> **|* *ryladog@gmail.com*
> <ryladog@gmail.com> *|* *Oakton, VA **|* *LinkedIn Profile*
> <http://www.linkedin.com/in/katieharitosshea/> *|* *Office: 703-371-5545
> <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> wrote:
>
>
>
>
>
> On 28 Apr 2016, at 19:50, Laura Carlson <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
>
>
>
>
>
>
>