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

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