Re[2]: Help needed with numbering success criteria for WCAG 2.1

------ Original Message ------
From: "John Foliot" <john.foliot@deque.com>
To: "David MacDonald" <david100@sympatico.ca>
Cc: "White, Jason J" <jjwhite@ets.org>; "josh@interaccess.ie" 
<josh@interaccess.ie>; "WCAG" <w3c-wai-gl@w3.org>
[...]

>David wrote:
>
> > Any new Success Criteria that have the x.x.x schema under these 
>Guidelines would have to go at the end. So a new AA SC would end up 
>after an existing AAA in the number Guideline
>
>Serious question: does anyone see this as a problem?
[Chair hat off]

Yes, I do. Thanks to David for bringing this up - and to JF for the 
comment. Noted. My preference would be a scheme where new SCs would 
'slot in' with the existing scheme (somehow) and not break existing 
tools used for evaluation etc.

OOTTMH - I'd almost consider using the letter/prefix or suffix 
suggestion almost as a preferred 'namespaced' type solution that would 
more easily call out what was new, within the SC schema and may not 
interfere with current automated evaluation methods too much.

Could be wrong (I could be right) - happy to hear either way.

Thanks

Josh


>
>For example, under Guideline 1.4, we have a total of 9 Success 
>Criteria: 2 A's, 3 AA's, and 4 AAA's. If we were to add a new 1.4 
>Guideline requirement (at any level), would it be an impediment or 
>problem to have, say, 1.4.10 (AA)? (I strongly suspect we'll not see 
>too many A's this time 'round). In other words, keep the Guideline 
>numbering as important at a logical level (i.e. "Guideline 1.4 
>Distinguishable: Make it easier for users to see and hear content 
>including separating foreground from background"), but the order of 
>presentation between A, AA, and AAA is to my mind less critical. The 
>only time I see this as being an issue (and I am not sure how much of 
>an issue it would be) is when generating a full evaluation report.
>
>By experience (and observation from our different clients at Deque), 
>most developers (or other roles involved in creation and maintenance of 
>web content), when faced with "accessibility issues" tend to whittle 
>them down to individual bugs, often tracked in a bug tracker (and 
>usually with their own internal identifier number), and in larger 
>organizations, often times individual bugs will be assigned to 
>different developers, so they rarely are dealing with "The Brick" that 
>is a complete evaluation of a page/web-site. So while there is the 
>notion that there is a nice holistic symmetry in having the SC 
>presented as A, AA, AAA in the larger document, I don't think it will 
>have any significant impact on actually moving things forward.
>
> > Simply presenting them out of order and grouped by Level
>
>Personally, I'd actually lean towards keeping them in numerical order 
>in the actual specification, and let tools and supporting documentation 
>allow for filtering and grouping based upon those criteria (for 
>example, similar to how the quickref "How To Meet WCAG 2.0" allows 
>filtering today - 
>https://www.w3.org/WAI/WCAG20/quickref/?currentsidebar=%23col_customize)
>
>JF
>
>On Sun, Jun 26, 2016 at 8:05 PM, David MacDonald 
><david100@sympatico.ca> wrote:
>>Count me in...
>>
>>Here's a few thoughts as we prepare to discuss it.
>>
>>- Any new Success Criterion that is under a *NEW* Guideline can have 
>>the regular 3 level number without colliding with another SC number . 
>>(This is the case with most of the proposed mobile SCs, i.e., Pointer 
>>2.5.1))
>>
>>- Guidelines 1.1, 1.3 and 4.1 only have Level A SCs so any new SCs 
>>under them can keep the 3 number format without colliding with 
>>anything ... just add x.y.z numbering after the last existing SCs at 
>>the desired level.
>>
>>- The real issue of collision is for new A or AA SCs under existing 
>>Guidelines that have AA of AAA already there. That is
>>    1.2, 1.4, 2.1, 2.2, 2.3, 2.4, 3.1, 3.2, 3.3, 3.4.
>>
>>Any new Success Criteria that have the x.x.x schema under these 
>>Guidelines would have to go at the end. So a new AA SC would end up 
>>after an existing AAA in the number Guideline (i.e. a new COGA AA 
>>under GL "2.2 Enough time" would be 2.2.6, would have to follow the 
>>2.2.5 Re-authentication AAA).
>>
>>We would have to address that issue something like:
>>
>>-Giving it a prefix, or a suffix,
>>- Simply presenting them out of order and grouped by Level
>>- Or creating a new guideline for these SCs.
>>
>>For SC's that modify an existing SC then perhaps adding a 4th level 
>>x.x.x.x would be necessary. But the 4th level would not be appropriate 
>>for anything else because it would cause the NEW SC to be a sub of an 
>>existing SC.
>>
>>
>>Cheers,
>>David MacDonald
>>
>>
>>CanAdapt Solutions Inc.
>>
>>Tel:  613.235.4902
>>LinkedIn
>>
>>twitter.com/davidmacd
>>
>>GitHub
>>
>>http://www.can-adapt.com/
>>
>>
>>
>>   Adapting the web to all users
>>
>>             Including those with disabilities
>>
>>If you are not the intended recipient, please review our privacy 
>>policy
>>
>>On Sun, Jun 26, 2016 at 5:47 PM, White, Jason J <jjwhite@ets.org> 
>>wrote:
>>>
>>>
>>>
>>>
>>>From: John Foliot [mailto:john.foliot@deque.com]
>>>Sent: Sunday, June 26, 2016 4:32 PM
>>>
>>>
>>>I would be interested in this activity. I have some thoughts on this 
>>>already (I know, shocking huh?), but I'm also interested to hear 
>>>other's ideas as well.
>>>
>>>[Jason] A solution that might work would be to add a prefix letter 
>>>(e.g., “x”) to the number of every modified or promoted success 
>>>criterion. This would clearly distinguish version 2.1 from version 
>>>2.0 success criteria for authors, evaluation tools and in other 
>>>contexts.
>>>
>>>I think it should be decided, case by case, whether to rewrite and 
>>>expand the scope of an existing guideline or success criterion, or 
>>>whether to introduce a new one. Readability for users of version 2.1 
>>>would have priority, in my mind, over backward compatibility. Once 
>>>people move to the new version, the older version becomes much less 
>>>relevant to most of their work.
>>>
>>>
>>>--------------------------------------------------------------------------------
>>>This e-mail and any files transmitted with it may contain privileged 
>>>or confidential information. It is solely for use by the individual 
>>>for whom it is intended, even if addressed incorrectly. If you 
>>>received this e-mail in error, please notify the sender; do not 
>>>disclose, copy, distribute, or take any action in reliance on the 
>>>contents of this information; and delete it from your system. Any 
>>>other use of this e-mail is prohibited.
>>>
>>>
>>>Thank you for your compliance.
>>>
>>>--------------------------------------------------------------------------------
>>
>
>
>
>--
>John Foliot
>Principal Accessibility Strategist
>Deque Systems Inc.
>john.foliot@deque.com
>
>Advancing the mission of digital accessibility and inclusion