Re: Guidance for TF-submitted Success Criteria

Hi Andrew

 in answer to your questions….



RE: Your question about how to have an SC that is like another.

IN WCAG 2.0  what we did was to use the same SHORT NAME with a parenthetical after it.   
For example 
1.4.5 Images of Text: If the technologies being used can achieve the visual presentation, text <https://www.w3.org/TR/WCAG20/#textdef> is used to convey information rather thanimages of text <https://www.w3.org/TR/WCAG20/#images-of-textdef> except for the following: (Level AA)
1.4.9 Images of Text (No Exception): Images of text <https://www.w3.org/TR/WCAG20/#images-of-textdef> are only used for pure decoration <https://www.w3.org/TR/WCAG20/#puredecdef> or where a particular presentation of text <https://www.w3.org/TR/WCAG20/#textdef> isessential <https://www.w3.org/TR/WCAG20/#essentialdef> to the information being conveyed. (Level AAA)
and
2.1.1 Keyboard: All functionality <https://www.w3.org/TR/WCAG20/#functiondef> of the content is operable through a keyboard interface <https://www.w3.org/TR/WCAG20/#keybrd-interfacedef> without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)
2.1.3 Keyboard (No Exception): All functionality <https://www.w3.org/TR/WCAG20/#functiondef> of the content is operable through a keyboard interface <https://www.w3.org/TR/WCAG20/#keybrd-interfacedef> without requiring specific timings for individual keystrokes. (Level AAA)


RE: Your question about how to have an SC that is like another   and  1 vs 2 SC.

If adding a new requirement - it is better to have it be a separate SC — or it breaks the WCAG model (and the model for most standards) of having two requirements in one provision. 
it makes it hard to report that one requirement in the provision has been met but not the other requirement when doing evaluations
it makes it hard to handle in Understanding WCAG 2.1 - in that you won’t be able to say that a technique is sufficient for the SC  — you will have things that are sufficient for one part but not the other, vice versa and sometimes both.   Very confusing to readers, evaluators and in discussion. 

Using the same text for a new SC with a few changes as needed - would be the same model as WCAG 2.0.   (see above for examples)   
  It also makes it easy to see what the differences are between the two.


ciao 

gregg

> On Jul 20, 2016, at 10:20 AM, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:
> 
> WCAG,
> Yesterday on the call we discussed what guidance we can provide to the TFs as they work to draft Success Criteria for the WG to review.
> 
> There were two main points of the discussion:
> SC Numbering scheme
> Where current SC text can be modified
> There was a lot of great work by John Foliot and others done collecting information about numbering scheme options for a WCAG 2.1 (https://www.w3.org/WAI/GL/wiki/WCAG_2.1_SC_Numbering <https://www.w3.org/WAI/GL/wiki/WCAG_2.1_SC_Numbering>).  The general thinking collected by John and on the call seems to be that Model 2 seems to be the best option.  
> 
> 1. 
> Model 2 would result in new SC being added at the end of a set of numbers within each Guideline (e.g. 1.3.4 and 1.4.10 and 4.1.3 would be examples of new possible SC numbers).  The downside is that the order of WCAG 2.0 has the level A SC first in a guideline number sequence, followed by AA, followed by AAA, and this will be disrupted in places as a possible 1.4.10 might be A or AA but would follow 1.4.9 which is AAA.  This would require that we work to make this clear to people reading the future version, but seems to be a better solution than the other models.  Note that the order may also be changed by existing SC changing in priority level.
> 
> There is a question about whether we may want to also consider adding a letter after a new SC if that SC is very close to an existing one in concept.  For example, if we were to decide to change SC 1.4.3 [Contrast (Minimum)] to require that text in a logo needs to meet the 4.5:1 ratio (this is a fabricated example, please don’t comment on the merits of the example), we might consider either:
> 
> 1.4.10 Logo Text Contrast: Text that is part of a logo or brand name has a contrast ratio of at least 4.5:1.
> Or 
> 1.4.3A Logo Text Contrast: Text that is part of a logo or brand name has a contrast ratio of at least 4.5:1. (possibly with Note: This SC expands on/modifies SC 1.4.3)
> 
> In both cases, a site might meet 1.4.3 and fail the new SC (and therefore not meet WCAG 2.1), but the new SC modifies the current SC.  
> 
> The WG is interested in which model works best for people – is there a benefit in understanding the new SC if it is adjacent?
> 
> 2. 
> Regarding guidance to the Task Forces, the WG decided to ask the Task Forces to write the SC in a way that doesn’t change the existing SC inline, but adds an entirely new SC for a topic.  This may mean that a change that could be done in just a few words in an existing SC might require additional text, but the group felt that we need to provide this clear direction to the TFs and that once the SC are in for review the WG may revisit the issue of whether the goals of clarity and brevity are better attained by modifying the original SC and if the benefit of doing so outweighs the potential confusion caused by the modification of the familiar current SC.
> 
> Please chime in if you have any questions, comments, or concerns.
> 
> Thanks,
> AWK
> 
> Andrew Kirkpatrick
> Group Product Manager, Standards and Accessibility
> Adobe 
> 
> akirkpat@adobe.com
> http://twitter.com/awkawk