W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2016

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

From: Gregg Vanderheiden RTF <gregg@raisingthefloor.org>
Date: Tue, 3 May 2016 12:27:36 -0500
Cc: IG - WAI Interest Group List list <w3c-wai-ig@w3.org>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
Message-Id: <A1C13527-F96F-4483-B27D-F5BC65C5B1FD@raisingthefloor.org>
To: Alastair Campbell <acampbell@nomensa.com>
thanks Alistair,

I’m not sure I see the difference between 1 and 2

they are both ways to pass.    And if we documented them— they are also all probably common.    And what is best practice on a page may not be what is used most commonly.    


Best Practice:  Considered to be the best technique or method for most but not all situations.


For #3 - what does it mean that they are common ways to fail but don’t automatically fail?      Do they manually fail? 

	Perhaps “Warning:  Things that sometimes fail - depending on how they are applied.   Check carefully) 


> On May 3, 2016, at 12:00 PM, Alastair Campbell <acampbell@nomensa.com> wrote:
> Gregg wrote: 
>> This is an intriguing idea but I worry that too many places or countries even will take “this is a common way to fail” and interpret it as a failure.
> Perhaps with a little more obvious structure? On the call just now I suggested we could have four levels:
> 1. Techniques (definitely passes, quite specific)
> 2. Best practices (common ways to pass)
> 3. Warnings (common ways that pages don’t pass, but don’t automatically fail.)
> 4. Failures (common ways that pages definitely fail, quite specific).
> I’m not sure there’s much we can do about Governments requiring techniques or seeing every non-pass as a failure, that would be best tackled by pushing the idea of functional performance vs requirements.
> http://mandate376.standards.eu/standard 
> That also maps to what testing tools tend to do, as they simply can’t fail many things, so have to warn about them.
> Cheers,
> -Alastair

Received on Tuesday, 3 May 2016 17:28:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:36:58 UTC