Re: Using more robust failures to support existing SCs

> On Oct 30, 2015, at 3:27 PM, Wayne Dick <wayneedick@gmail.com> wrote:
> 
> I am concerned about using failures because the entire Understanding document is informative.

correct.


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

You cannot re-interpret the SC.  The only valid interpretation is the one at the time the SC were adopted.   Since that is the understanding of the working group and the public reviewers. 

But there are many places where something was indented to be covered - but it was not explained well or not specifically mention because it did not exist at the time.  (there is a famous example of this in the ADA  where all the examples of store fronts were brick and mortar because the web based stores didnt exist yet)       The understanding document is exactly the right place to explain that things were intended to be covered that were - -but were not specifically mentioned.      There are also places where we weren’t clear. 

> 
> 
> We have task forces because WCAG 2.0 left major groups out.

I don’t think this is a fair statement at all.    There were not groups left out - major or minor.     We, along with all of the commenters in the public, were not able to identify all the different techniques and approaches — so task forces are formed to see if there are more things that can be done.    More techniques is one thing.    If additional SC can be identified - that would also be good to do — but the WG worked very hard to get all of the basic SC that could be identified that could be objective and broadly applied. 

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

If the rules are misinterpreted by someone - then the interpretations need to be corrected by providing clearer language in the Understanding document.   

> The language must be normative to discourage retraction.

Not clear what you mean here.     But changing the standard is a very long process — think 5 years or more.      It sounds easy but when you go through the process and try to get consensus and public comment etc — it is very long.    And if the only goal is editorial (not changing the meaning but just making it clearer so it is not misinterpreted )  then the Understanding document is also the best place and much faster.


NOTE - that the SC are deliberately made general so they apply across technologies.  This makes them harder to understand.   but for the most part, whenever we tried to make them simpler it meant making them more specific — and that made them more technology specific which was not our goal.   We went through 4 rounds of ‘simplification’ attempts — including engaging plain language experts - to try to simplify.    it is really hard to be simple and not specific to technologies. 


Keep pushing though.    it is hard but worth it when we can find ways. 

Gregg




> 
> Wayne
> 
> 
> 
> 
> On Fri, Oct 30, 2015 at 8:39 AM, Gregg Vanderheiden RTF <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>> wrote:
> 
> > On Oct 30, 2015, at 9:24 AM, Jonathan Avila <jon.avila@ssbbartgroup.com <mailto: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 <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 <mailto:jon.avila@ssbbartgroup.com>
> >
> > 703-637-8957 <tel:703-637-8957> (o)
> > Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
> >
> >
> > -----Original Message-----
> > From: Gregg Vanderheiden [mailto:gregg@raisingthefloor.org <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 <mailto: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
> >>
> >
> >
> 
> 
>