RE: In WCAG NEXT let's put a date field on failures

David MacDonald wrote:
> 
> ===Problem===
> 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.

Hi David,

I think part of the problem is here, when you state: "... some voices that will not want to tighten things up." - I will suggest that by "tightening" a Success Criteria, you are changing it - you are asking from it more today than you were 8 years ago, which is a serious, perhaps critical problem.

Now, I am all for providing a good, better, best collection of Techniques to achieve success, and it's good that we've had so many new Techniques added over the years. 

I am less convinced however that there is a huge need for Failures, as frankly we really don't want to be 'promoting' them in any way. More importantly, the fears that you expressed are very real: in the example you brought forward on today's call, it suggested that without aria or html5 landmarks, documents would "fail" (and BTW here's the failure technique), yet the 'parent' Success Criteria does not require aria or html5 landmarks. Ergo, by adding that proposed failure technique today, you would be changing the normative requirement for the Success Criteria, whether anyone wants to admit that or not. 

To use your "tightening" example, the Success Criteria was tightened to a torque level of "8 psi" in 2008, and you now want to tighten it to "12 psi" today (because we can), but that still remains clearly a change.


I think the more appropriate way of "tightening" things is to revisit the problem area(s) and put forth a new SC that augments and strengthens an existing SC, in a fashion similar to how SC 1.4.6 Contrast (Enhanced) is a "tightening" of SC 1.4.3 Contrast (Minimum), or how SC 3.3.6 Error Prevention (All) is a "tightening" of 3.3.4 Error Prevention (Legal, Financial, Data), and which could be argued is an enhancement of SC 3.3.1 Error Identification.

So in the case discussed on today's call, instead of attempting to back-door something via a "failure technique" why doesn't this WG contemplate (for example) a new "SC 1.3.4 Structural Consistency" (or some such) for WCAG.next, and introduce the new technology and "requirements" that way?

To me, the bottom line is that I recognize that we now *DO* have the technology and techniques to do more than what WCAG 2.0 mandates, but that we cannot (and should not) be attempting to use a stable and fixed standard to advocate for that growth - that if we want (and expect) more/better today, we do that by introducing new requirements, and not attempt to retro-fit existing ones.

> 
> ====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.

I am in favor of clearer time-stamping on Techniques, but I think the W3C should stay out of how and why those time-stamps may be used: we are not a regulatory body, we do not make or write laws or other legislations, and I think we need to stay out of that business completely (not only w.r.t. accessibility standards, but I feel the same way about the ongoing discussion over the EME extension spec as well, which is broadly contained under the larger and quite contentious discussion around DRM on the web.) If the Government of Tinyland wants to use those time-stamps as a means of tracking or measuring progress, hey, great, but that is for them to decide, not the W3C. 

Cheers!

JF

Received on Tuesday, 26 April 2016 21:49:20 UTC