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

 >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 didn't consider this, and certainly would not want to message that 
anything published before x date on a tech is or is not relevant.
I see this suggestion more of a 'heads up' about how 'current' a tech 
may be - independently of whether it pertains or not to a given page.

Further, the time stamp may could help devs see more current work that 
could be relevant to their responsive needs, or HTML.next etc  - and may 
improve their perceived sense of relevancy. The flip side is that there 
may be perfectly good techs that are relevant but are just well - 
'classic'.

Maybe we need a 'golden oldies' section ;-)

Josh



>
>Thanks,
>AWK
>
>Andrew Kirkpatrick
>Group Product Manager, Accessibility and Standards
>Adobe
>
>akirkpat@adobe.com
>http://twitter.com/awkawk
>
>From: "josh@interaccess.ie" <josh@interaccess.ie>
>Reply-To: "josh@interaccess.ie" <josh@interaccess.ie>
>Date: Wednesday, April 27, 2016 at 07:26
>To: Gian Wild <gian@accessibilityoz.com>, David MacDonald 
><david100@sympatico.ca>, WCAG <w3c-wai-gl@w3.org>, WAI-IG 
><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>
>Resent-Date: Wednesday, April 27, 2016 at 07:25
>
>
>------ Original Message ------
>From: "Gian Wild" <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:gian@accessibilityoz.com
>>
>>Mobile (Australia): 042 442 6262
>>
>>Cell (United States): (206) 701 6363
>>
>>
>>
>>Offices:
>>
>>United States: (415) 621 9366
>>
>>Canberra: (02) 6108 3689
>>
>>Melbourne: (03) 8677 0828
>>
>>Brisbane: (07) 3041 4011
>>
>>
>>
>>From: David MacDonald [mailto:david100@sympatico.ca]
>>Sent: Tuesday, 26 April 2016 12:55 PM
>>To: WCAG <w3c-wai-gl@w3.org>; w3c WAI List <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
>>
>>LinkedIn
>>
>>twitter.com/davidmacd
>>
>>GitHub
>>
>>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
>>