Re: Help needed with numbering success criteria for WCAG 2.1

On 27 Jun 2016, at 13:21, josh@interaccess.ie wrote:

> ------ 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.

The question is what happens when a AA criterion is “promoted” to be 
an A criterion, for example:

x.1.1 – A
x.1.2 – A
x.1.3 – AA
x.1.4 – AA
x.1.5 – AA
x.1.6 – AAA

If x.1.4 is promoted to A, that would make it

x.1.1 – A
x.1.2 – A
x.1.4 – A
x.1.3 – AA
x.1.5 – AA
x.1.6 – AAA

or

x.1.1 – A
x.1.2 – A
x.1.3 – A (was: x.1.4)
x.1.4 – AA (was: x.1.3)
x.1.5 – AA
x.1.6 – AAA

or

x.1.1 – A
x.1.2 – A
x.1.3 – AA
x.1.4 – A
x.1.5 – AA
x.1.6 – AAA

I find everything but the latter very confusing, at least for the 2.x 
WCAG branch, we’re of course free to adopt a different counting 
technique for 3.0.

> 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.

I don’t know how the problem would be addressed by a prefix/suffix…

Reformulating

x.1.1 – A
x.1.2 – A
x.1.3 – AA
x.1.4 – AA
x.1.5 – AA
x.1.6 – AAA

to

x.1.A.1 – A
x.1.A.2 – A
x.1.AA.1 – AA
x.1.AA.2 – AA
x.1.AA.3 – AA
x.1.AAA.1 – AAA

would work but would also break legacy tools, and I’m not too sure we 
want to do that in 2.x. Also, if x.1.AA.2 (which is a mouthful, too) was 
promoted from AA to A, it would be

x.1.A.1 – A
x.1.A.2 – A
x.1.A.3 – A (used to be x.1.AA.2)
x.1.AA.1 – AA
(x.1.AA.2 – Moved to x.1.A.3)
x.1.AA.3 – AA
x.1.AAA.1 – AAA

This makes somewhat sense and would be consistent, but it would also 
make the numbering much more complicated.

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

+1 – I think it is a very complicated issue (to do right and somewhat 
“user”friendly).

Eric

>
> 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




--

Eric Eggert
Web Accessibility Specialist
Web Accessibility Initiative (WAI) at World Wide Web Consortium (W3C)