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

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