Re: Success Criteria guidance

  *   Be testable through automated or manual processes.

I think this should be clarified to

  *   Be testable through automated or manual processes to the same standard as WCAG 2.0

The text is the same as WCAG 2.0 was held to – what is the concern that you are trying to address with the additional text?

I also do not understand the following:

  *   Ensure for revised SC that pages that meet the revised SC continue to meet the corresponding WCAG 2.0 SC.

This is for backward compatibility.  If you conform to SC #.#.# in WCAG 2.1 you need to also meet #.#.# in WCAG 2.0.  The reverse is not necessarily true since WCAG 2.1 will have updates.


  *   .. but specific enough not to become a 'catch-all' for any given requirement.

I agree that this one is ambiguous, and that is why it is in the “should” grouping.

This one I do not really understand either

  *   Avoid where possible establishing criteria for content which are addressed in other Success Criteria

To discourage redundancy of requirements.

Also glossary definitions can be used to simplify and shorten SC also not for shared terms
(see Use glossary definitions to simplify and shorten all SC for shared terms.)

The text now suggests more than just shared terms.

AWK


All the best

Lisa Seeman

LinkedIn<http://il.linkedin.com/in/lisaseeman/>, Twitter<https://twitter.com/SeemanLisa>




On Tuesday, August 2, 2016 1:51 PM, Andrew Kirkpatrick <akirkpat@adobe.com<mailto: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<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk