Re: Help needed with numbering success criteria for WCAG 2.1

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?

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