Re: Success Criteria guidance

I totally agree that it's useful to have unique identifiers so that things can be referenced, and the item Andrew quoted (from the "Success Criteria Requirements" section of the "WCAG 2.1 Success Criteria" page) would certainly encourage numbered lists in SC (where lists are needed at all). That being said, three suggestions:

(1) Alan was pointing out omissions in the Understanding document, and it's not clear that the item Andrew quoted applies there. Since the Understanding document is non-normative and can be revised much more easily, it's less critical to get it right the first time, but it would be good to encourage better adherence to some style guide. Is there a style guide? Note that Examples differ not only in use of identifiers, but also in lower-priority things like capitalization and punctuation, e.g.

     (from Examples of Success Criterion 2.1.1)    * Example 1: A drawing Program.
     (from Examples of Success Criterion 1.3.1)    * A form with required fields

(2) Personally, I lean towards using *numbered* lists for stand-alone items such as Principles, Guidelines, and Success Criteria, but *lettered* lists for things that don't stand alone, such as list items within an SC. This helps make the distinction very clear, and also avoids confusion if we ever do add fourth level headings for another reason. (Thus the third exception under 1.1.1, currently styled "* Sensory", would be "c. Sensory" and could be cited as "1.1.1.c Sensory".) But that decision should be part of the whole renumbering debate.

(3) Also, we might encourage those submitting new SC to include draft Examples, although we needn't require them. (That would presumably be in the "Acceptance Criteria for proposals for new Success Criteria ..." section).

-------- Original Message --------
Subject: Re: Success Criteria guidance
From: ALAN SMITH <alands289@gmail.com>
To: Andrew Kirkpatrick <akirkpat@adobe.com>, lisa.seeman <lisa.seeman@zoho.com>, WCAG <w3c-wai-gl@w3.org>
Date: 8/3/2016 11:14 AM
>
> 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 <mailto:akirkpat@adobe.com>
> *Sent: *Wednesday, August 3, 2016 1:33 PM
> *To: *ALAN SMITH <mailto:alands289@gmail.com>; lisa.seeman <mailto:lisa.seeman@zoho.com>; WCAG <mailto:w3c-wai-gl@w3.org>
> *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 <mailto:akirkpat@adobe.com>
>
> http://twitter.com/awkawk
>
> *From: *"alands289@gmail.com <mailto:alands289@gmail.com>" <alands289@gmail.com <mailto:alands289@gmail.com>>
> *Date: *Wednesday, August 3, 2016 at 11:38
> *To: *Andrew Kirkpatrick <akirkpat@adobe.com <mailto:akirkpat@adobe.com>>, "lisa.seeman@zoho.com <mailto:lisa.seeman@zoho.com>" <lisa.seeman@zoho.com <mailto:lisa.seeman@zoho.com>>, WCAG <w3c-wai-gl@w3.org <mailto: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 <mailto:akirkpat@adobe.com>
> *Sent: *Wednesday, August 3, 2016 11:03 AM
> *To: *lisa.seeman <mailto:lisa.seeman@zoho.com>; WCAG <mailto:w3c-wai-gl@w3.org>
> *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 <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
>