- From: Andrew Kirkpatrick <akirkpat@adobe.com>
- Date: Tue, 31 May 2016 14:50:13 +0000
- To: lisa.seeman <lisa.seeman@zoho.com>
- CC: "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
- Message-ID: <A47C8B12-0A7C-42FB-94AD-0CCF7D9A8A46@adobe.com>
Great, thanks for the clarification. To clarify my point, I don’t believe that saying “most experts” is fine. Thanks, AWK Andrew Kirkpatrick Group Product Manager, Standards and Accessibility Adobe akirkpat@adobe.com http://twitter.com/awkawk From: "lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>" <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>> Date: Tuesday, May 31, 2016 at 10:19 To: Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>> Cc: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>> Subject: Re: acceptance criteria for new success criteria Yup this is what I was trying to say with #2. Saying most experts will agree is fine. So long as we are clear how testable success criteria must be to be accepted. All the best Lisa Seeman LinkedIn<http://il.linkedin.com/in/lisaseeman/>, Twitter<https://twitter.com/SeemanLisa> ---- On Tue, 31 May 2016 17:10:18 +0300 Andrew Kirkpatrick<akirkpat@adobe.com<mailto:akirkpat@adobe.com>> wrote ---- Lisa, The main item that I find missing in the acceptance criteria is testability. You do have machine testability listed in the “where possible” part of the list, and I agree with including machine testability there, but all success criteria need to be testable as a basic acceptance criteria. I’m differentiating between “testable” and “machine testable” in the same what that WCAG 2.0 does. SC 1.1.1 requires alternate text on images for example. This is testable, but not (yet) machine testable. WCAG 2.0 says "WCAG 2.0 builds on WCAG 1.0 [WCAG10] and is designed to apply broadly to different Web technologies now and in the future, and to be testable with a combination of automated testing and human evaluation." If the language of a success criteria will not allow an evaluator to clearly determine whether a page has passed or failed, then that SC must not be approved. For example, if we proposed a success criteria that read “Text must not be too small to read” we would quickly dismiss that text as not testable. You may be hitting on this with the #2 "Ensure that the conformance requirements are clear such that most experts will agree if a success criteria has been met.” but this isn’t exactly right as I believe that we can’t say “most experts” for a requirement (also, the conformance requirements are for conformance to the WCAG 2.1 document, not to individual SC). Either way, “Success Criteria must be testable” should be in the list. Thanks, AWK Andrew Kirkpatrick Group Product Manager, Standards and Accessibility Adobe akirkpat@adobe.com<mailto:akirkpat@adobe.com> http://twitter.com/awkawk From: "lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>" <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>> Date: Thursday, May 26, 2016 at 11:48 To: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>> Subject: acceptance criteria for new success criteria Resent-From: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>> Resent-Date: Thursday, May 26, 2016 at 11:48 Hi I would like to propose the following as acceptance criteria for new success criteria or for changes to existing success criteria: 1. Ensure that requirements may be applied across technologies such as HTML, CSS, SVG etc 2. Ensure that the conformance requirements are clear such that most experts will agree if a success criteria has been met. 3. Utilize the WCAG 2.0 A/AA/AAA structure. Further, we aim to should provide the following supporting material by the time we go to CR. 1. Identify who benefits from accessible content (such as people with cognitive limitations such as an low short term memory) 2. Outline (but not necessarily complete) one supporting technique for each success criteria I do not think this should be acceptance criteria but, where possible and _without_ compromising accessibility, we should also: 1. Write it with ease of use in mind 2. Success criteria should be potentially machine testable in the future 3. Consider and document ideas for authoring tools to reduce the author burden 4. Write to a diverse audience 5. Try to make it "forward compatible" 6. Try to make it fit under the current principles and, where possible, guidelines. Note that most of these terms are further discussed at https://www.w3.org/TR/wcag2-req/ All the best Lisa Seeman LinkedIn<http://il.linkedin.com/in/lisaseeman/>, Twitter<https://twitter.com/SeemanLisa>
Received on Tuesday, 31 May 2016 14:50:47 UTC