Re: Using more robust failures to support existing SCs

I would approve of a more robust failure strategy. Personally, I think
there are a number of reasons it is hard to get consensus on a Failure.
Some of those reasons have to do with ensuring it is "common" and always
fails the SC if it is done.

I think we could map a number of new failures to success criteria,
particularly issues that are identified by the cognitive, low vision and
mobile task forces. It might be easier to do that than create new success
criteria in the extensions.




Cheers,

David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn <http://www.linkedin.com/in/davidmacdonald100>

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 Fri, Oct 30, 2015 at 4:27 PM, Wayne Dick <wayneedick@gmail.com> wrote:

> I am concerned about using failures because the entire Understanding
> document is informative. The problem with missing support from WCAG 2.0 is
> that there is insufficient normative language to  support the accessibility
> needs of undeserved disabilities. There are very specific needs that may be
> covered by WCAG 2.0 with re-interpretation success criteria, but the
> problem with interpretation is that it can be changed without sufficient
> review.
>
> We have task forces because WCAG 2.0 left major groups out. If the rules
> could be misinterpreted to leave these disability groups out, then we need
> normative language to make it clear that there are user requirements that
> are necessary to those disability groups. The language must be normative to
> discourage retraction.
>
> Wayne
>
>
>
>
> On Fri, Oct 30, 2015 at 8:39 AM, Gregg Vanderheiden RTF <
> gregg@raisingthefloor.org> wrote:
>
>>
>> > 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
>> >>
>> >
>> >
>>
>>
>>
>