Re: Success Criteria guidance

This is a very good list
I numbered them below to make it easier to refer to them. 

1 through 7 look solid

8 is unclear " • Be as broad as possible, but specific enough not to become a 'catch-all' for any given requirement."
this sounds like advice but not a criterion.  Remember — that all CRITERIA need to be testable — and that applies to success criteria  AND TO THE CRITERIA FOR SUCCESS CRITERIA. 
this one does not look testable.     
I’m not sure what “become a catch-all” means 

9  I THINK a better way to say #9 is (if I understand it correctly)
“  Avoid creating a new SC to require something that is already required by and existing SC.”
#9 is a good one - and testable if the SC are. 

10  " Use glossary definitions to simplify and shorten all SC for shared terms.”
I think this is a good one.   Putting definitions inside of SC is easier in one sense — but it makes it much harder to parse the SC.   If the definition is just 2 or 3 words - then including it in the SC is good. But when it is longer, or has lengthly notes,  - putting the term in the guideline and its definition in the glossary is better,
To make this one ‘testable’ I would suggest
Use glossary definitions to simplify and shorten all SC for shared terms, or terms whose definitions would be more than half a dozen words in length.


RE Greg Lowneys comment.

these considerations are covered by the conformance criteria - rather than the success criteria. 


gregg

> On Aug 2, 2016, at 1:49 PM, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:
> 
> The Working Group discussed requirements for WCAG 2.1 Success Criteria on Tuesday’s call (http://www.w3.org/2016/08/02-wai-wcag-minutes.html).  The current set of requirements is copied below.  I’m raising this on the list because the group feels that it is close to consensus on this list but we wanted to raise this with the list for additional feedback and to call attention to one specific point raised that the group didn’t have time to fully resolve.
> 
> ==start==
> These requirements are provided as guidance to the WCAG Working Group as it works to define new Success Criteria in WCAG 2.1. The guidance here may be changed by the working group if necessary
> Success Criteria shall:
> Address a situation where a user with a disability will be disproportionately disadvantaged (as compared to a user without a disability) if the criteria is not met.
> Be testable through automated or manual processes.
> Describe the specific condition required to meet the criteria, not the method to address the criteria.
> Utilize the WCAG 2.0 A/AA/AAA level structure.
> Ensure for revised SC that pages that meet the revised SC continue to meet the corresponding WCAG 2.0 SC.
> Apply to all content, unless specific exceptions are included in the success criteria (e.g. "except interruptions involving an emergency").
> Apply across technologies to the extent possible. (Technology-specific issues should usually be addressed in Techniques.)
> Be as broad as possible, but specific enough not to become a 'catch-all' for any given requirement.
> Avoid where possible establishing criteria for content which are addressed in other Success Criteria
> Use glossary definitions to simplify and shorten all SC for shared terms.
> 
> ==end==
> 
> The additional point was raised by Greg Lowney and suggested that we should require the following as additional guidance:
> 
> (Success Criteria Shall) Clearly specify whether the described behavior is required to be (a) always on, (b) on in the default configuration, (c) available in the default configuration, or (d) available (possibly using third-party tools).
> 
> Group members – thoughts on the list and on Greg’s additional item?
> 
> Thanks,
> AWK
> 
> Andrew Kirkpatrick
> Group Product Manager, Standards and Accessibility
> Adobe 
> 
> akirkpat@adobe.com
> http://twitter.com/awkawk