RE: SC failure for opening new window without prior notice ?

Very helpful post.  It is always best to take a look at fundamentals as the work continues, especially as people come in and go on to other things.



Allen Hoffman
Deputy Executive Director
The Office of Accessible Systems & Technology
Department of Homeland Security
202-447-0503 (voice)
allen.hoffman@hq.dhs.gov<mailto:allen.hoffman@hq.dhs.gov>

DHS Accessibility Helpdesk
202-447-0440 (voice)
202-447-0582 (fax)
202-447-5857 (TTY)
accessibility@dhs.gov<mailto:accessibility@dhs.gov>

This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain sensitive and legally privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited.  If you have received this message in error, please reply immediately to the sender and delete this message.  Thank you.

From: CAE-Vanderhe [mailto:gregg@raisingthefloor.org]
Sent: Sunday, July 20, 2014 3:26 PM
To: GLWAI Guidelines WG org
Subject: Re: SC failure for opening new window without prior notice ?

Couple of thoughts on this thread  and on  WCAG WG Documented Failures

 - commenting on several items that came up.

Disclaimer:  Because these comments have not been vetted by the working group - these are my thoughts (informed by what happened at the working group discussions as we built WCAG) but are only my understanding of the facts as they relate to this discussion, not an official working group response.  For an official response - you can send your questions in via the public comment mechanism and the working group will reply.


  *   Level AAA is not advisory.  (someone seemed to refer to level AAA success criteria as advisory)    a AAA failure is a failure at level AAA, as much as the failure of any other SC at any other level (A or AA) at that level.   (only advisory techniques are advisory)


  *   Something should not be claimed to be a failure of any SC for any other reason than if it fails to meet the language of the SC.   In this thread I have seen several other thoughts as to why something should be a failure of an SC.  But the SC language is what rules - with the Understanding Doc providing non-normative information on what the Working Group members meant by the SC when they agreed on it - after having gotten all of the information and feedback from the field.
  *   The working group does not document everything that might be a failure in the Techniques Document.

     *   The only failures that are documented are things that are

        *   are common (commonly occur)
        *   are of consequence and
        *   are  ALWAYS a failure  (there is no way to do this and still be accessible).

     *   The working group has removed failures when it was found that there were ways to do them in a manner that was accessible due to changes in technology or AT.  They may still be failures in some situations or environments, but if they are not always a failure they should not be listed.

  *   AT failures are not Failures the working group documents.  (as someone noted - AT failures are User Agent failures not content failures)

     *   Because we have 'accessibility support' it is true that something can fail to meet a success criteria if there are no AT that support the technique that you are using to meet the SC.   However, the fact that some AT doesn't support it is not sufficient to say that there is no AT support.   The working group (purposefully) did not define how much AT support needed to be there - it left this to regulatory agencies that would also say where the WCAG should apply.     But it was clear that AT support did not mean support of ALL AT.
     *   In any case,  something that fails because some AT doesn't yet support it - should not be something that would be documented as a Failure (in the techniques do).  First, it fails the test of "is always a failure".    Second - it is temporal and would no longer be true as soon as the problem is fixed.    (this differs from something that no one knows how to solve).

  *   Opening a new window is something that can easily be - and is for many AT is - detected, and the user notified.   However notification is only required if it happens on providing input or changing a setting, not on giving a command.
  *   This provision was intended to avoid having the context changed in disorienting ways when the user has done something that never (usually) changes the context.  For example, navigating to or from an entry field.

     *   But clicking on a link very commonly changes the context, opening a new window or changing some or all of the current window. The provision is not intended to ward users of these activities.

  *   Failures are almost treated as 'negative SCs"  by some -  and, although informative - are treated by many as normative.   Because of this they should be created very sparingly - and only used to identify things are are COMMON, MAJOR, and DEFINITE Failures.   They also should not just be re-statements of the SC themselves.  This is unnecessary (redundant) - and risks rewording the SC - which is not appropriate.  The language of the SC were extremely carefully considered and the language there is the consensus language that was adopted and is the standard.


Hope this is helpful.

Gregg