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

Hi David, 

If you like, do feel free to document what you see as common current failures and bring them to the group for review. 

Thanks 

Josh 


Sent from TypeApp



On 29 Apr 2016, 19:53, at 19:53, David MacDonald <david100@sympatico.ca> wrote:
>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
>>
>>
>>
>>
>>
>>
>>