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

+1 on Wilco's comments three number schem uless it truely ks a sub category
of an existing SC.

As a separate issue, it's also tempting to try to break up 1.3.1 as you've
laid out... I think that will generate lots of diverse opinions... :-) I
think its worth looking at separately.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <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
<http://www.davidmacd.com/disclaimer.html>

On Mon, Jun 27, 2016 at 12:31 PM, John Foliot <john.foliot@deque.com> wrote:

> Hi Josh,
>
> I wanted to follow up about a comment you made:
>
> > 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.
>
> Since Deque is one of those tool-makers, I took this question back to one
> of our engineers (Wilco Fiers - Chair - W3C Automated WCAG Monitoring CG
> https://www.w3.org/community/auto-wcag/) who wrote back:
>
> "I like that your solution doesn't reuse a number, that's a good thing.
> That would be very problematic. But still, something like 1.2.3.1 as a
> replacement of 1.2.3, That doesn't make much intuitive sense to me. I would
> expect that to be a sub criterion of some sort.
>
> I don't think the criteria should change numbers at all. Sure, the
> following list isn't all that aesthetically pleasing, but I seriously doubt
> it will ever confuse anyone or cause major bugs.
>
> x.1.1 A
>
> x.1.2 A
>
> x.1.3 AA
>
> x.1.4 A       <-- Raised a level
>
> x.1.5 AAA
>
> x.1.6 AAA
>
> x.1.7 AA     <-- New criterion
>
>
> Hope this helps!"
>
>
> There are (as Wilco notes) some existing Success Criteria that *should* be
> contemplated as 'sub-criteria', that Wilco is suggesting we should use the
> 4th number for, and as an example I can share that internally at Deque
> we've already done this (for evaluation purposes) to some existing SC
> already. For example, 1.3.1 (Info and Relations) is, I think, considered
> extremely broad in scope, and internally we've broken it down into a series
> of testing for different aspects of the SC, like this:
>
> SC 1.3.1 — Info and Relationships
>
>    - 1.3.1.a — Semantics
>    - 1.3.1.b — Data Tables
>       - 1.3.1.b.detail – Data Tables in Detail
>    - 1.3.1.c — Programmatic Labels
>    - 1.3.1.d — Group Related Form Elements
>    - 1.3.1.e — Headings
>    - 1.3.1.f  — Lists
>
> More data points to consider...
>
> JF
>
> On Mon, Jun 27, 2016 at 6:21 AM, josh@interaccess.ie <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.
>>
>> 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
>>>
>>>
>>>
>>> *Can**Adapt* *Solutions Inc.*
>>> Tel:  613.235.4902
>>>
>>> LinkedIn
>>> <http://www.linkedin.com/in/davidmacdonald100>
>>>
>>> twitter.com/davidmacd
>>>
>>> GitHub <https://github.com/DavidMacDonald>
>>>
>>> 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
>>> <http://www.davidmacd.com/disclaimer.html>
>>>
>>> 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
>>
>>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com
>
> Advancing the mission of digital accessibility and inclusion
>