Re: Using more robust failures to support existing SCs

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