- From: lisa.seeman <lisa.seeman@zoho.com>
- Date: Mon, 08 Aug 2016 12:33:13 +0300
- To: "W3c-Wai-Gl@W3. Org" <w3c-wai-gl@w3.org>
- Message-Id: <156697de2a0.dc02c8fb55077.4436306497267990453@zoho.com>
Hi Folks Neil (who helped with drafting the COGA SC) and I have the suggest the following changed draft. The changes are small but I think makes it much more doable and more inline with the practicalities of drafting them and will result in better quality before the first working draft. They are also more inline with the bar for current WCAG SC bar. Acceptance criteria Each proposed SC is provided on its own page, and that page (location of the page TBD, likely on GitHub) contains: The SC textIf suggesting a wording change to an existing success criteria, write the complete SC text and indicate the changes by surrounding new text with "@@". For example (just an example), "1.4.3 Contrast (Minimum): The visual presentation of @@text, images of text, and icons@@ has a contrast ratio of at least 4.5:1, except for the following: (Level AA)". SC text should be written to be testable (human or machine) Indication of any suggested glossary definitions or changes. What Principle and Guideline it falls within Information about the user benefits OR a link to more information that includes how this success criteria maps to user needs or provides a user benefit By June 2017 we should supply for each SC A description of what the intent of the SC is, including which users benefit from the content successfully addressing it. Clear information about how the proposal will benefit users If it is not clear then a description of how this SC can be tested. Possible technique titles which could be used to satisfy the SC (just the title). Guidance The following are guidelines that will help the Working Group efficiently process suggested SC: Ensure that the criteria is written as simply as possible. SC are better when they:Are short in length. However brevity should not at the expense of clarity or testability. Minimize the use of lists to where they make the success criteria easier to follow. Lists can be used to prevent the creation of multiple, similar success criteria. When using lists, numbered lists are preferred to more easily allow referencing specific items Avoid the use of "notes" unless it makes the success criteria easier to follow (Notes are regarded as Normative in WCAG 2.0 and 2.1) Avoid jargon and unnecessarily complex language. However simplicity should not at the expense of clarity or testability The SC can be summarized into a simple language sentence that describes its themeAll the best All the best Lisa ---- On Tue, 02 Aug 2016 22:34:32 +0300 Andrew Kirkpatrick<akirkpat@adobe.com> wrote ---- Group, The WCAG group also reviewed proposed criteria for proposals for new or changed SCs for WCAG 2.1. These criteria are more of a checklist for task forces submitting proposals and provides details of what the WG is looking for in order to have enough information to review proposals. If pieces are missing, proposals will be returned to the submitter for completion prior to being resubmitted. The criteria are: Each proposed SC is provided on its own page, and that page (location of the page TBD, likely on GitHub) contains: The SC text If suggesting a wording change to an existing success criteria, write the complete SC text and indicate the changes by surrounding new text with "@@". For example (just an example), "1.4.3 Contrast (Minimum): The visual presentation of @@text, images of text, and icons@@ has a contrast ratio of at least 4.5:1, except for the following: (Level AA)". Indication of any suggested glossary definitions or changes. What Principle and Guideline it falls within. A description of what the intent of the SC is, including what users benefit from the content successfully addressing it. Clear information about how the proposal will benefit users, along with justification and evidence of the benefits. Description of how this SC can be tested. Possible technique titles which could be used to satisfy the SC (just the title). Please comment if you feel like something on this list needs to be changed/clarified, and if you think that other items are needed and should be added to the list. Thanks, AWK Andrew Kirkpatrick Group Product Manager, Standards and Accessibility Adobe akirkpat@adobe.com http://twitter.com/awkawk
Received on Monday, 8 August 2016 21:23:22 UTC