Re: Using more robust failures to support existing SCs

> On Oct 30, 2015, at 9:24 AM, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote:
> 
>> and they (failures) can only be created if there is no way to pass under any circumstances for any content for any technology if you do this.
> 
> Just looking at the failures list for WCAG this does not appear to always be the case.  Some of the failures are technology specific such as with CSS, scripting, etc. IMO. http://www.w3.org/WAI/GL/WCAG20-TECHS/failures.html

Correct.   So that failure is alway a failure when it applies.    
When you apply it to any other technology - the failure is not true because the failure specifies that it only applies to CSS etc.  

That is an example of how to write a Failure - to be one that is very specific so that it is never “true” when there is not real failure. 






> 
>> 2) it has to be impossible to pass the SC for all case if the failure is true.
> 
> Yes, but the " Understanding Techniques for WCAG Success Criteria" note indicates "Content that has a failure does not meet WCAG success criteria, unless an alternate version is provided without the failure.”
> 
Yes -  the content under evaluation fails — so there has to be an alternative version of the content  that passes.     The conformance criteria say that an alternate version of the page can exist.  But that page much then meet all the SC to pass. 

> I've always understood this to mean that even if you had a failure you could still meet the SC requirement through an alternative method that passes an SC.  So a failure is only a failure if there isn't another technique that doesn't meet the success criteria. So for example, you could have a meaningful image with no alt text but have a description of the image in text right next to the image.

Yes —  the PAGE is what is tested.   So if the content in on the page twice - and one is accessible - then the page passes.    If you think about it — this has to always be true since a picture (as a component of content on the page) is never really accessible to people who are blind, but the PAGE is - because it provides alt-text  to present the purpose of the picture in text. 





> 
> Jonathan
> 
> -- 
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group 
> jon.avila@ssbbartgroup.com
> 
> 703-637-8957 (o) 
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
> 
> 
> -----Original Message-----
> From: Gregg Vanderheiden [mailto:gregg@raisingthefloor.org] 
> Sent: Thursday, October 29, 2015 5:44 PM
> To: Joshue O Connor
> Cc: GLWAI Guidelines WG org
> Subject: Re: Using more robust failures to support existing SCs
> 
> Failures are great — but they are VERY hard to do.
> 
> They never broaden an SC — and they can only be created if there is no way to pass under any circumstances for any content for any technology if you do this. 
> 
> We (the working group) has had to remove a number that we created due to this.  
> 
> 
> 1) the  SC has to absolutely require it
> 2) it has to be impossible to pass the SC for all case if the failure is true. 
> 
> They are very helpful to evaluators when they can be created.
> 
> Gregg
> 
> 
>> On Oct 29, 2015, at 11:12 AM, Joshue O Connor <josh@interaccess.ie> wrote:
>> 
>> Hi all,
>> 
>> In the last thread - some interesting comments from Detlev and Jon A, got me thinking and I want to give a +1. I agree with Detlev and Jon and think this is a clever approach to providing better support for existing SCs, by having more and varied failures.
>> 
>> Thanks
>> 
>> Josh
>> 
> 
>

Received on Friday, 30 October 2015 15:39:15 UTC