Re: Success Criteria guidance

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

Gregg, we discussed this on the call.  In general we want to structure some advice that helps avoid SC that are arguably too broad like 1.3.1 (Information and Relationships), and also avoid being too constrained like 2.1.1 (Keyboard).  Both create some amount of challenges, and we aren’t sure how to guide toward the right balance.  Of course, we need to study the current and possibly future technologies and listen to technologists about what is coming to guide us, but we hoped to have some sort of guiding statement here that would help.

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.

I like your edit. That is what we are trying to capture – the need to not create redundant criteria.

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.

6 words feels a little arbitrary, and given that only two of the WCAG 2.0 definitions are this short ("blocks of text” and “prerecorded”) perhaps the length can be assumed to be enough to justify a glossary entry for any ambiguous term?

So instead possibly:
Use glossary definitions to simplify and shorten all SC for shared or ambiguous terms

Thanks,
AWK