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

Hi John,

> I am left asking “where is the value-add?” Why do we
> need to document more Failure techniques on WCAG 2.0
> today? I don’t know, and I think it’s an honest
> question to be asking.

In my experience a developer is more likely to address an issue if I
can point him to the related W3C failure document.

My 2 cents.

Kindest Regards,
Laura

On 4/28/16, John Foliot <john.foliot@deque.com> wrote:
> Hi Katie,
>
>
>
> While we are level setting, please know that this is not an attack on David,
> or any of the work he has done over the years: I too value his contributions
> immensely – this is not personal and please do not think otherwise.
>
>
>
> David has lamented the fact that there have been very few failure techniques
> advanced since the launch of WCAG 2.0 (he classified it as a failure), and
> I’m trying to understand why he feels that way. I’m not “complaining”, I’m
> trying to understand what the real issue is. I’m trying to understand why
> some people feel that more Failure techniques is something we should be
> working on. While you’ve suggested some older tools took advantage of
> Failure techniques (which tools?), we also have at least 2 developers of
> modern tools suggesting that the Failures are far less important today
> (perhaps in part because no new ones have come forward since the initial set
> was published?) And as Gregg noted “Failures are failures whether we
> document them or not” and so I am left asking “where is the value-add?” Why
> do we need to document more Failure techniques on WCAG 2.0 today? I don’t
> know, and I think it’s an honest question to be asking.
>
>
>
>
>
> David has previously suggested that he believes the reason why we are not
> getting more Failure techniques is based on 3 fears:
>
>
>
> 1) Fear that it changes the requirements of WCAG
> 2) If not, a fear that there is a *perceived* change to WCAG
> 3) Fear that pages that once passed will not pass after a new common failure
> is introduced.
>
>
>
> I couldn’t agree more, and I suspect that these potential concerns are very
> real; David has noted we’ve seen push back on other proposed failures in the
> past for just those same reasons (especially #1 & #3, which are to me
> essentially the same thing).
>
>
>
> I personally just don’t see the value in attempting to write more Failure
> Techniques for existing Success Criteria, but if members of the Working
> Group want to continue that effort, I would suggest that any new Failure
> techniques (or the set-up to them) explicitly addressed the 3 core ‘fears’
> that David has noted and dispel those fears up-front, otherwise the
> effort(s) will likely meet the same fate as Issue 173 seems destined for.
> And I would also like to understand the business reason for pursuing this,
> if for no other reason than because today I don’t.
>
>
>
> Thanks.
>
>
>
> JF
>
>
>
>
>
>
>
> From: Katie Haritos-Shea GMAIL [mailto:ryladog@gmail.com]
> Sent: Wednesday, April 27, 2016 3:57 PM
> To: 'John Foliot' <john.foliot@deque.com>; 'David MacDonald'
> <david100@sympatico.ca>; 'Gregg Vanderheiden' <gregg@raisingthefloor.org>
> Cc: '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
>
>
>
> John,
>
>
>
> *  I did some informal checking with two people I know who are directly
> involved in creating evaluation tools: Karl Groves (Tenon.io) and Wilco
> Fiers (Deque Systems, Chair of the W3C Automated WCAG Monitoring Community
> Group
>
>
>
> You are correct that is not a robust sampling of tool authors and tools that
> are out there and have been for used for years. I was very recently looking
> through a couple of tools specific rulesets and they do use the failures as
> well as the techniques to build their rules. But the WCAG failures always
> result in failures in their tools – which is good in general, but it depends
> on how they are implemented.
>
>
>
> To level set, WCAG *does* focus on sufficient techniques, and the
> Understanding document – by far - way more than failures, as indicated by
> the few, as David identified, have been implemented in the last 8 years.
>
>
>
> The exercise that David undertook, to try to document a new failure based on
> some concerns - was a valiant effort, even if rejected. And he again, by
> far, has written so many techniques/examples/test-cases/etc (in other words
> positive resources that are very useful and not failures) that it is
> probably impossible to count.
>
>
>
> ​​​​​So what is your point here? To “re-evaluate their place and value in
> the larger ecosystem”? How large are they to you? They have a place, just
> not *the* place. The place is what we always focus on, techniques, the
> understanding doc, and now, how to address adding new content.
>
>
>
> Are you complaining that he tried to address a legitimate concern? His
> effort certainly didn’t waste my time.
>
>
>
>
>
>
>
> * katie *
>
>
>
> Katie Haritos-Shea
> Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)
>
>
>
> 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
>
>
>
> From: John Foliot [mailto:john.foliot@deque.com]
> Sent: Wednesday, April 27, 2016 2:20 PM
> To: 'Katie Haritos-Shea GMAIL' <ryladog@gmail.com <mailto:ryladog@gmail.com>
>>; 'David MacDonald' <david100@sympatico.ca <mailto:david100@sympatico.ca>
>>; 'Gregg Vanderheiden' <gregg@raisingthefloor.org
> <mailto:gregg@raisingthefloor.org> >
> Cc: 'Andrew Kirkpatrick' <akirkpat@adobe.com <mailto:akirkpat@adobe.com> >;
> 'Joshue O Connor' <josh@interaccess.ie <mailto:josh@interaccess.ie> >;
> 'GLWAI Guidelines WG org' <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org> >;
> 'IG - WAI Interest Group List list' <w3c-wai-ig@w3.org
> <mailto:w3c-wai-ig@w3.org> >
> Subject: RE: Let's add an approved date field to Failures and Techniques
>
>
>
> Hi Katie, all,
>
>
>
> You wrote: “…the reason failure techniques are so important is that it is
> what drives/quantifies FAILURES in accessibility evaluation and repair
> tools.”, which I want to push back on, just a bit.  I did some informal
> checking with two people I know who are directly involved in creating
> evaluation tools: Karl Groves (Tenon.io) and Wilco Fiers (Deque Systems,
> Chair of the W3C Automated WCAG Monitoring Community Group -
> https://www.w3.org/community/auto-wcag/).
>
>
>
> What I heard back from them doesn’t fully jive with your assertion – Wilco
> stated outright that he doesn’t look at them very much as they are “too
> vague” and “too non-technical”. Karl said “Not all of the defined Failures
> are testable via automated tools. And the Failures aren't an exhaustive
> list… I've only recently begun consulting the failures to determine if
> there's anything I may have overlooked.”
>
>
>
> Now, I agree that this is hardly a robust representative sampling, but I
> think it does call into question the assumption that Failure Techniques are
> being used by the tool makers, or at least questions the overall value of
> Failures in the larger process.
>
>
>
> I’m not suggesting we abandon the Failures techniques, only that we honestly
> re-evaluate their place and value in the larger ecosystem. Is there anyone
> else that is reliant on the Failures documents, and if so, can somebody
> explain why? As Gregg noted: “Failures are failures whether we document them
> or not. Documenting them is just a courtesy to people to make COMMON
> failures more evident (and less common)”, which is how I’ve always thought
> of them, so I am surprised to hear that others see the Failures as more
> important than that. (I’m really not trying to be a jerk here, I really am
> not understanding this)
>
>
>
> Having failures that are “…worded as carefully as possible so as to provide
> bulletproof failures” kind of feels like an anti-pattern to me – that we are
> spending time and resources documenting multiple ways of saying “don’t do
> this”, when to my mind the better way forward is to continue to offer more
> Success Techniques (aka “Do this – or this, or this, or this”) which as
> David has noted, this WG is doing already, with 150 new SC since 2008 –
> which is awesome.
>
>
>
> Signed “Scratching my head in Texas”
>
>
>
> JF
>
>
>
> From: Katie Haritos-Shea GMAIL [mailto:ryladog@gmail.com]
> Sent: Wednesday, April 27, 2016 11:55 AM
> To: 'John Foliot' <john.foliot@deque.com <mailto:john.foliot@deque.com> >;
> 'David MacDonald' <david100@sympatico.ca <mailto:david100@sympatico.ca> >;
> 'Gregg Vanderheiden' <gregg@raisingthefloor.org
> <mailto:gregg@raisingthefloor.org> >
> Cc: 'Andrew Kirkpatrick' <akirkpat@adobe.com <mailto:akirkpat@adobe.com> >;
> 'Joshue O Connor' <josh@interaccess.ie <mailto:josh@interaccess.ie> >; 'Gian
> Wild' <gian@accessibilityoz.com <mailto:gian@accessibilityoz.com> >; 'GLWAI
> Guidelines WG org' <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org> >; 'IG -
> WAI Interest Group List list' <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>
>>
> Subject: RE: Let's add an approved date field to Failures and Techniques
>
>
>
> *  David and others, I also struggle myself to understand how/why Failure
> Techniques are so important to some content creators.
>
>
>
> My understanding that the reason failure techniques are so important is that
> it is what drives/quantifies FAILURES in accessibility evaluation and repair
> tools, which so many more people than developers utilize. Therefore, they
> *must* be worded as carefully as possible so as to provide bulletproof
> failures – and hopefully tool builders will implement failure rules as
> carefully as possible in their tools.
>
>
>
> ​​​​​
>
>
>
>
>
>
>
> * katie *
>
>
>
> Katie Haritos-Shea
> Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)
>
>
>
> 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
>
>
>
> From: John Foliot [mailto:john.foliot@deque.com]
> Sent: Wednesday, April 27, 2016 12:43 PM
> To: 'David MacDonald' <david100@sympatico.ca <mailto:david100@sympatico.ca>
>>; 'Gregg Vanderheiden' <gregg@raisingthefloor.org
> <mailto:gregg@raisingthefloor.org> >
> Cc: 'Andrew Kirkpatrick' <akirkpat@adobe.com <mailto:akirkpat@adobe.com> >;
> 'Joshue O Connor' <josh@interaccess.ie <mailto:josh@interaccess.ie> >; 'Gian
> Wild' <gian@accessibilityoz.com <mailto:gian@accessibilityoz.com> >; 'GLWAI
> Guidelines WG org' <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org> >; 'IG -
> WAI Interest Group List list' <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>
>>
> Subject: RE: Let's add an approved date field to Failures and Techniques
>
>
>
>> We need a solution, if not a date field I'm all ears... how are we going
>> to solve this in WCAG.NEXT?
>
>
>
> Hi David, All
>
>
>
> What I’d like to see is more “new” Success Criteria, or as you and I have
> discussed off-line, a new category of Best Practices that would be linked to
> modern technologies, while leaving other Techniques as simply “other ways”
> of doing things – create a “Super Technique” as it were.
>
>
>
> For example, in the discussion around 1.3.1 I think we can all agree that
> using aria landmarks or HTML5 Sectioning elements would be *today’s* Best
> Practice, and a holistic WCAG with a new category of Best Practice would
> hopefully provide the additional ‘umph’ to get developers to move in that
> direction. In that regard, adding a visible date to the new technique would
> be extremely useful (it also would assist in the “technology supported”
> discussion).
>
>
>
> On a related thought, while the discussion and decisioning around WCAG.next
> is still ongoing, I think we might perhaps also start asking ourselves if
> there are any Success Criteria that we may need today that isn’t coming
> directly from one of the 3 Task Forces currently working on that (for
> example David, you and I chatted about returning to the MAUR to see if there
> were any potentially new SC opportunities in that document). So perhaps we
> should contemplate a wider review like that as well.
>
>
>
> As a strawman example, and using SC 1.3.1 as a starting point, perhaps we
> would look to create a SC 1.3.1.1 which would *require* aria landmarks or
> HTML5 Sectioning elements… or perhaps we might want to shift this notion to
> a 4.1.2.1 or a 4.1.3 (as all of the 4.x Success Criteria are under the
> banner of “Maximize compatibility with current and future user agents”). In
> the comments that came out of the WCAG.next discussion, Katie had suggested
> that a ‘new’ Success Criteria in WCAG 2.1 would be backward-ported to a WCAG
> 2.0 Best Practice, so that no matter which WCAG you are developing and
> conforming to, as a content author you have either a Requirement or a Best
> Practice.
>
>
>
> In other words, let’s “modernize” WCAG in as many ways as we can, but by
> adding to it, not seeking to redefine or arbitrarily  enhance existing
> Success Criteria.
>
>
>
> David and others, I also struggle myself to understand how/why Failure
> Techniques are so important to some content creators. In a simplistic view,
> Failures seem to be “Don’t do this” statements, whereas Techniques for
> Success are “You should do this (or this, or this, or this)” – and so I see
> the fundamental difference as being one between positive re-enforcement and
> negative re-enforcement, and as the guy known to state “Be the Fireman and
> not the Cop” I am struggling to understand how the negative re-enforcement
> provides value (but I leave open the possibility that it does, and I’m just
> not seeing it). Thanks in advance for helping me better understand this.
>
>
>
> Cheers
>
>
>
> JF
>
>
>
>
>
> From: David MacDonald [mailto:david100@sympatico.ca]
> Sent: Wednesday, April 27, 2016 10:53 AM
> To: Gregg Vanderheiden <gregg@raisingthefloor.org
> <mailto:gregg@raisingthefloor.org> >
> Cc: Andrew Kirkpatrick <akirkpat@adobe.com <mailto:akirkpat@adobe.com> >;
> Joshue O Connor <josh@interaccess.ie <mailto:josh@interaccess.ie> >; Gian
> Wild <gian@accessibilityoz.com <mailto:gian@accessibilityoz.com> >; GLWAI
> Guidelines WG org <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org> >; IG - WAI
> Interest Group List list <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> >
> Subject: Re: Let's add an approved date field to Failures and Techniques
>
>
>
> I've given up trying to introduce failures to WCAG 2. Even ones that should
> be failures like letting blind people know where the regions on a page are.
>
> There have been 3 little administrative failures voted "yes" in 8 years. The
> technology independent strategy of "ever green" success criteria and updated
> non normative techniques and failures of WCAG 2 in this regard has been a
> total failure. So even though in principle yes... a failure is always a
> failure... the whole business with respect  to failures has been a failure
> and I'm hoping for a new way forward.
>
> This might make industry a little uncomfortable, but they've always been
> uncomfortable with requirements... for perhaps good reasons from their
> perspective but the end result is that people with disabilities suffer ...
>
> We need a solution, if not a date field I'm all ears... how are we going to
> solve this in WCAG.NEXT?
>
>
>
>
> Cheers,
> David MacDonald
>
>
>
> CanAdapt Solutions Inc.
>
> Tel:  613.235.4902
>
> LinkedIn <http://www.linkedin.com/in/davidmacdonald100>
>
>
> twitter.com/davidmacd <http://twitter.com/davidmacd>
>
>  <https://github.com/DavidMacDonald> GitHub
>
> 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 Wed, Apr 27, 2016 at 9:33 AM, Gregg Vanderheiden
> <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org> > wrote:
>
> agree
>
>
>
> failures don’t become failures on the date they were documented.    Failures
> are failures whether we document them or not. Documenting them is just a
> courtesy to people to make COMMON failures more evident (and less common).
>
>
>
> They should stay up as long as they are accurate and should be removed when
> not.      And we can document failures at any time it seems helpful.    But
> the date a failure is documented has nothing to do with anything.
>
>
> gregg
>
>
>
> On Apr 27, 2016, at 8:24 AM, Andrew Kirkpatrick <akirkpat@adobe.com
> <mailto:akirkpat@adobe.com> > wrote:
>
>
>
> My concern about date-stamping failures is that failures are not normative
> and we already have plenty of confusion about that.  Setting a date on a
> failure and saying that if a page was published before Jan 1, 2017 that the
> failure doesn’t apply is going to further confuse that. I recognize the
> value of the interpretation of standards to be able to easily adjust to
> changes in technology, but it is very tricky business and we will need to
> think carefully about how to best accomplish that.
>
>
>
> Thanks,
>
> AWK
>
>
>
> Andrew Kirkpatrick
>
> Group Product Manager, Accessibility and Standards
>
> Adobe
>
>
>
> akirkpat@adobe.com <mailto:akirkpat@adobe.com>
>
> http://twitter.com/awkawk
>
>
>
> From: "josh@interaccess.ie <mailto:josh@interaccess.ie> "
> <josh@interaccess.ie <mailto:josh@interaccess.ie> >
> Reply-To: "josh@interaccess.ie <mailto:josh@interaccess.ie> "
> <josh@interaccess.ie <mailto:josh@interaccess.ie> >
> Date: Wednesday, April 27, 2016 at 07:26
> To: Gian Wild <gian@accessibilityoz.com <mailto:gian@accessibilityoz.com> >,
> David MacDonald <david100@sympatico.ca <mailto:david100@sympatico.ca> >,
> WCAG <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org> >, WAI-IG
> <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> >
> Subject: Re[2]: Let's add an approved date field to Failures and Techniques
> Resent-From: WCAG <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org> >
> Resent-Date: Wednesday, April 27, 2016 at 07:25
>
>
>
>
>
> ------ Original Message ------
>
> From: "Gian Wild" <gian@accessibilityoz.com
> <mailto:gian@accessibilityoz.com> >
>
> [...]
>
>
>
> That is an absolutely FANTASTIC idea!!
>
> I think this is a good idea, and would no have no objection.
>
>
>
> Thanks
>
>
>
> Josh
>
>
>
>
>
>
>
> --
>
>
>
> Gian Wild, CEO
>
> AccessibilityOz
>
>
>
> Email: <mailto:gian@accessibilityoz.com> gian@accessibilityoz.com
>
> Mobile (Australia): 042 442 6262
>
> Cell (United States): (206) 701 6363 <tel:%28206%29%20701%206363>
>
>
>
> Offices:
>
> United States: (415) 621 9366 <tel:%28415%29%20621%209366>
>
> Canberra: (02) 6108 3689
>
> Melbourne: (03) 8677 0828
>
> Brisbane: (07) 3041 4011
>
>
>
> From: David MacDonald [mailto: <mailto:david100@sympatico.ca>
> david100@sympatico.ca]
> Sent: Tuesday, 26 April 2016 12:55 PM
> To: WCAG < <mailto:w3c-wai-gl@w3.org> w3c-wai-gl@w3.org>; w3c WAI List <
> <mailto:w3c-wai-ig@w3.org> w3c-wai-ig@w3.org>
> Subject: Let's add an approved date field to Failures and Techniques
>
>
>
> I think we have a problem introducing failures that we will have
>
> to address in WCAG.NEXT. I would like to propose a solution.
>
> ===Problem===
> WCAG was created to be an ever green document. The SCs are not
> technology dependent, non normative techniques and failures, can be
> created to address new realities that we see on the ground as the web
> develops. This has happened for techniques, but not failures. We have
> created about 150 new techniques since 2008, and only *3* (three)
> failures.
>
> It is not from a lack of failure proposals, there have been plenty in
> 8 years. However, it is almost impossible to gain consensus on a
> failure, because there are always a some voices that will not want to
> tighten things up, for various reasons, some of them I would agree
> with in some situations. Here are the main reasons its hard to pass a
> failure:
>
> 1) Fear that it changes the requirements of WCAG
> 2) If not, a fear that there is a *percieved* change to WCAG
> 3) Fear that pages that once passed will not pass after a new common
> failure is introduced.
>
> ====Solution=====
> Id' like to propose an "Approved date" field, to techniques and
> failures, which would be populated when we gained consensus on a
> technique or failure. This will give jurisdictions a tool to exempt
> failures that were created after a site was built.
>
>
>
>
>
>
>
> Cheers,
> David MacDonald
>
>
>
> CanAdapt Solutions Inc.
>
> Tel:  613.235.4902 <tel:613.235.4902>
>
>  <http://www.linkedin.com/in/davidmacdonald100> LinkedIn
>
>
>  <http://twitter.com/davidmacd> twitter.com/davidmacd
>
>  <https://github.com/DavidMacDonald> GitHub
>
>  <http://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
> <http://www.davidmacd.com/disclaimer.html> privacy policy
>
>
>
>
>
>


-- 
Laura L. Carlson

Received on Thursday, 28 April 2016 18:51:01 UTC