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>; 'David MacDonald' <david100@sympatico.ca>; 'Gregg Vanderheiden' <gregg@raisingthefloor.org>
Cc: 'Andrew Kirkpatrick' <akirkpat@adobe.com>; 'Joshue O Connor' <josh@interaccess.ie>; 'Gian Wild' <gian@accessibilityoz.com>; '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

 

*  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