RE: Compromise on Numbering: Changing 11 AAA numbers solves the level problem

To expand on the idea that I introduced at the meeting, we could define mnemonic two or three-letter codes to serve as stable identifiers for all of the success criteria. Whenever the text of a success criterion is changed, the identifier would be updated, solving the problem of making inadvertent references to the wrong version of an SC.

Thus, for example, we could have:

1.1.1        [NTC] Non-text Content

1.2.1 [AVP] Audio-only and Video-only (Prerecorded)

1.2.2 [CAP] Captions (Prerecorded)

1.2.3 [AMP] Audio Description or media Alternative (Prerecorded)


The codes used here are just illustrations of the idea. A font convention could be used to make them distinct, if necessary.
There would be a note in the document pointing out that the numbers are not stable, but that the identification codes are.

I don’t mind whether this proposal (or something like it) is adopted, but I do think we should separate the stable identifiers from the section numbering scheme, so that the latter can be changed easily with further revisions of the specification.

From: David MacDonald []
Sent: Wednesday, September 20, 2017 10:06 AM
To: Michael Cooper <>
Cc: Alastair Campbell <>; WCAG Editors <>; Wilco Fiers <>; WCAG <>
Subject: Re: Compromise on Numbering: Changing 11 AAA numbers solves the level problem

> Numbers are a terribly brittle way to ID something, and we have much better IDs already in the spec.

That's interesting. I hadn't thought about the HTML ID numbers which were previously XML ID numbers as ways to refer to success criterion. I'm quite certain that these IDs are not used in common practice anywhere where people are referring to SC's in the public. Usually records in a database are identified by number rather than an ASCII text string.

I was using the term ID as the way that automated tools and accessibility professionals would refer to the success criterion rather than the way that we would internally or in our code for the document.

The concern you're raising is interesting and will have to address that at some point.

Detlev, I think Michael was concerned about using the current success criterion numbers as IDs rather than the four digit scheme which I also think is a poor choice for us. The mockup is actually a good way to demonstrate that it's doesn't work.

David MacDonald

CanAdapt Solutions Inc.
Mobile:  613.806.9005



  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<>

On Wed, Sep 20, 2017 at 9:41 AM, Michael Cooper <<>> wrote:
On 20/09/2017 9:10 AM, David MacDonald wrote:

If we do that I think should start referring to the numbers as ID#s. Its a change in layout because WCAG 2 used the numbers as "Outline" mode to order them. The new layout would be changing that "ID" mode as unique identifiers but not the common way of referring to them by lay people. I'm OK with that change but I think we should articulate it.
We should not refer to numbers as IDs. Numbers are a terribly brittle way to ID something, and we have much better IDs already in the spec. In WCAG 2.0 the ID for SC 1.1.1 is "text-equiv-all"; in WCAG 2.1 we base the ID on the SC title so it's "non-text-content". In both cases there is a lot of infrastructure built around those IDs, and no infrastructure built around the numbers.

I know I'm going to lose the debate on numbers, where my position is that they are meaningless and we should number things as appropriate to *this* spec, but we should not attempt to solve concerns with numbers by declaring them as IDs when they are not and we already have better, more stable IDs.



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.


Received on Wednesday, 20 September 2017 15:24:12 UTC