SC todo list

From Cognitive Accessibility Task Force

You can see the stats of each success criteria (SC) at [1]

Instructions

Read this whole section before submitting an SC

We need to putting the proposed Success Criteria (SC's) into the WCAG template

  1. Sign up to do a SC bellow
  2. Find the SC proposal at https://rawgit.com/w3c/coga/master/extension/index.html AND any wording changes at https://rawgit.com/w3c/coga/master/extension/rewroded%20sc%203.html
  3. make a new document for this success criteria based on the template: https://rawgit.com/w3c/coga/master/extension/template.html (note that this is based on Andrews template at https://github.com/w3c/wcag21/wiki/Proposals-for-new-Success-Criteria -but I added instructions and useful links)
  4. Add your document to coga github in the extension sub directory IE: https://github.com/w3c/coga/tree/master/extension (If this is hard then send it to Lisa)

I made a sample at : https://rawgit.com/w3c/coga/master/extension/support-personalization.html

Comply with: https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria (see bellow)


Try to take all the relevant info from the techniques document (https://rawgit.com/w3c/coga/master/techniques/index.html) and issue papers.

The techniques document has lots of really good information and relevant techniques 

pass and failure examples and  there are  Sources/research cited
The benefits section must fully make the case for the change.

In the benefits section we need to focus on explaining the new material to them and explain why changes were needed.

It is really really important, as we want to get these passed, to do this we really want to:

  1. show the benefits including any evidence and
  2. show test-ability
  3. make it clear

It is worth looking at wcag 2.O such as https://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html to see the kind of wording used in WCAG.

You can see an example of a general test procedure here:https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20160317/G92.html#G92-tests


Some thing we need to clarify that people with cognitive disabilities include many types of disabilities such as:

  1. Language related disabilities
  2. Memory related disabilities
  3. Focus and attention related disabilities
  4. Executive and decision making disabilities


Hopefully feedback will be collected at https://github.com/w3c/wcag21/labels/COGA

Success Criteria Requirements

Taken from https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria

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:

  1. 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.
  2. Be testable through automated or manual processes.
  3. Describe the specific condition required to meet the criteria, not the method to address the criteria.
  4. Utilize the WCAG 2.0 A/AA/AAA level structure.
  5. Ensure for revised Success Criteria that pages that meet the revised guidance continue to meet the corresponding WCAG 2.0 Success Criteria.
  6. Apply to all content unless preconditions for the application of the success criteria are explicitly identified (e.g. "except interruptions involving an emergency").
  7. Apply across technologies to the greatest extent possible. (Technology-specific issues should usually be addressed in Techniques.)
  8. Avoid creating a requirement for something that is already required by an existing Success Criterion.
  9. Have Success Techniques which demonstrate that each Success Criterion is implementable, using readily-available formats, user agents, and assistive technologies.

Success Criteria should:

  1. Be as broad as possible, but specific enough not to become a 'catch-all' for any given requirement.
  2. Use glossary definitions to simplify and shorten all Success Criteria for shared or ambiguous terms.

Checklist for proposals for new Success Criteria or to change existing Success Criteria

Each proposed SC is provided on its own page, and that page (location of the page TBD, likely on GitHub) contains:

  1. The SC text.
    • If suggesting a wording change to an existing success criteria, write the complete SC text and then follow that with a version which indicates 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)".
  2. Suggestion for Priority Level (A/AA/AAA).
  3. Indication of any suggested glossary definitions or changes.
  4. What Principle and Guideline it falls within (or suggestion for new guideline)
  5. A description of what the intent of the SC is, including what users benefit from the content successfully addressing it (examples are helpful, but not required).
  6. Clear information about how the proposal will benefit users, along with justification and evidence of the benefits (this may be a link to a separate resource).
  7. Description of how this SC can be tested.
  8. Possible technique titles which could be used to satisfy the SC (just the title).

Success Criteria Best Practice Guidelines

The Working Group is striving for WCAG 2.1 to be as clear as possible, and has established the following as Best Practice Guidance. For groups submitting Success Criteria proposals, these are guidelines and are not intended to be absolute. For example, a SC proposal may be written using notes or lists if the proposal is deemed clearer as a result, however, the Working Group may restructure the content upon further review for clarity.

  1. Ensure that the criteria is written as simply as possible without loss of clarity or testability. SC are better when they:
    1. Are concise and clear
    2. Minimize the use of lists to where they make the success criteria easier to follow. When lists are necessary numbered lists are preferred to more easily allow referencing specific items
    3. Avoid the use of "notes" to make the criteria clear (Notes are regarded as Normative in WCAG 2.0 and 2.1)
    4. Avoid jargon and unnecesarily complex language.
  2. The SC can be summarized into a simple language sentence that describes its theme


Volunteer

















Status: suggested changes need to be integrated






  • Humen help is provided
    • Allocated to:
    • New version:
    • Original version: not yet done


Retrieved from "https://www.w3.org/WAI/GL/task-forces/coga/wiki/index.php?title=SC_todo_list&oldid=1764"