RE: Guidance for TF-submitted Success Criteria

Thank the heavens that you still have a great memory and clearly functioning brain to be able to share these simple but important points Gregg…….:-)

 

(My brain is highly challenged – each and every day….:-)

 

​​​​​

 

 

 

* katie *

 

Katie Haritos-Shea 
Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)

 

Cell: 703-371-5545 |  <mailto:ryladog@gmail.com> ryladog@gmail.com | Oakton, VA |  <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | Office: 703-371-5545 |  <https://twitter.com/Ryladog> @ryladog

 

From: Gregg Vanderheiden [mailto:gregg@raisingthefloor.org] 
Sent: Wednesday, July 20, 2016 11:57 AM
To: Andrew Kirkpatrick <akirkpat@adobe.com>
Cc: GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
Subject: Re: Guidance for TF-submitted Success Criteria
Importance: High

 

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,  <https://www.w3.org/TR/WCAG20/#textdef> text is used to convey information rather than <https://www.w3.org/TR/WCAG20/#images-of-textdef> images of text except for the following: (Level AA)
* 1.4.9 Images of Text (No Exception):  <https://www.w3.org/TR/WCAG20/#images-of-textdef> Images of text are only used for  <https://www.w3.org/TR/WCAG20/#puredecdef> pure decoration or where a particular presentation of  <https://www.w3.org/TR/WCAG20/#textdef> text is <https://www.w3.org/TR/WCAG20/#essentialdef> essential to the information being conveyed. (Level AAA)

* and

* 2.1.1 Keyboard: All  <https://www.w3.org/TR/WCAG20/#functiondef> functionality of the content is operable through a  <https://www.w3.org/TR/WCAG20/#keybrd-interfacedef> keyboard interface 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  <https://www.w3.org/TR/WCAG20/#functiondef> functionality of the content is operable through a  <https://www.w3.org/TR/WCAG20/#keybrd-interfacedef> keyboard interface 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. 

1. it makes it hard to report that one requirement in the provision has been met but not the other requirement when doing evaluations
2. 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 <mailto: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:

1. SC Numbering scheme
2. 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).  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 <mailto:akirkpat@adobe.com> 

http://twitter.com/awkawk