RE: Success Criteria guidance

Andrew,

Yes, that answers my concern.

Thank you.

When I saw lists in the SC examples without unique numbers that was my concern as well.

Alan Smith, CSTE, CQA

Sent from Mail for Windows 10

From: Andrew Kirkpatrick
Sent: Wednesday, August 3, 2016 1:33 PM
To: ALAN SMITH; lisa.seeman; WCAG
Subject: Re: Success Criteria guidance

Hit send too soon…

Alan,
I think that this is a good idea to help people refer to different parts of the 2.1 document.  I think that we have this covered when we say :

 Minimize the use of lists, and when lists are necessary numbered lists are preferred to more easily allow referencing specific items

Does that address your concern?

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Standards and Accessibility
Adobe 

akirkpat@adobe.com
http://twitter.com/awkawk

From: "alands289@gmail.com" <alands289@gmail.com>
Date: Wednesday, August 3, 2016 at 11:38
To: Andrew Kirkpatrick <akirkpat@adobe.com>, "lisa.seeman@zoho.com" <lisa.seeman@zoho.com>, WCAG <w3c-wai-gl@w3.org>
Subject: RE: Success Criteria guidance

Can we also have unique numbers for each SC?  A bulleted list is hard to reference for communication, questions or for training purposes. 
 
Example from 1.3.1 where bullets are used. 
Numbering each is a better cognitive communication method.
 
Examples of Success Criterion 1.3.1
• A form with required fields 
A form contains several required fields. The labels for the required fields are displayed in red. In addition, at the end of each label is an asterisk character, *. The instructions for completing the form indicate that "all required fields are displayed in red and marked with an asterisk *", followed by an example. 
• A form that uses color and text to indicate required fields
A form contains both required and optional fields. Instructions at the top of the form explain that required fields are labeled with red text and also with an icon whose text alternative says, "Required." Both the red text and the icon are programmatically associated with the appropriate form fields so that assistive technology users can determine the required fields. 
• A bus schedule table where the headers for each cell can be programmatically determined
A bus schedule consists of a table with the bus stops listed vertically in the first column and the different buses listed horizontally across the first row. Each cell contains the time when the bus will be at that bus stop. The bus stop and bus cells are identified as headers for their corresponding row or column so that assistive technology can programmatically determine which bus and which bus stop are associated with the time in each cell. 
• A form where the labels for the checkboxes can be programmatically determined
In a form, the labels for each checkbox can be programmatically determined by assistive technology. 
• A text document 
A simple text document is formatted with double blank lines before titles, asterisks to indicate list items and other standard formatting conventions so that its structure can be programmatically determined. 
 
 
Alan Smith, CSTE, CQA

Sent from Mail for Windows 10
 
From: Andrew Kirkpatrick
Sent: Wednesday, August 3, 2016 11:03 AM
To: lisa.seeman; WCAG
Subject: 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, Twitter


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