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

We added a 'short name identifier' (that is the text after the number) for
all SC in 2.0 that map to those HTML identifiers on the code "text-equiv-all";
maybe the short name identifier' is the way to go.....

Katie Haritos-Shea
703-371-5545

On Sep 20, 2017 11:25 AM, "White, Jason J" <jjwhite@ets.org> wrote:

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 [mailto:david@can-adapt.com]
*Sent:* Wednesday, September 20, 2017 10:06 AM
*To:* Michael Cooper <cooper@w3.org>
*Cc:* Alastair Campbell <acampbell@nomensa.com>; WCAG Editors <
team-wcag-editors@w3.org>; Wilco Fiers <wilco.fiers@deque.com>; WCAG <
w3c-wai-gl@w3.org>

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


Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Mobile:  613.806.9005 <(613)%20806-9005>

LinkedIn
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fdavidmacdonald100&data=02%7C01%7Cjjwhite%40ets.org%7Cd01102d25bf543df0d2008d50030d6fb%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636415132125853712&sdata=X%2FQDIOkHLpszcvGkwwIF7YuFVha5E%2BNJyOdOMcKDyo4%3D&reserved=0>

twitter.com/davidmacd
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fdavidmacd&data=02%7C01%7Cjjwhite%40ets.org%7Cd01102d25bf543df0d2008d50030d6fb%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636415132125853712&sdata=rgtcxxyOf%2B3BqSXWJ0YNGfnS5vw5ocHUmZlvB3W7HBQ%3D&reserved=0>

GitHub
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDavidMacDonald&data=02%7C01%7Cjjwhite%40ets.org%7Cd01102d25bf543df0d2008d50030d6fb%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636415132125853712&sdata=A9Gu26lvDqNoJ649U3sQkUos2c6GgVQnJMzhF6WYYnU%3D&reserved=0>

www.Can-Adapt.com
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.can-adapt.com%2F&data=02%7C01%7Cjjwhite%40ets.org%7Cd01102d25bf543df0d2008d50030d6fb%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636415132125853712&sdata=NXd2%2FrBTxRt5UNg%2F7esaP%2FLuHQgczUcfRuA8A4en7Nc%3D&reserved=0>



*  Adapting the web to all users*

*            Including those with disabilities*



If you are not the intended recipient, please review our privacy policy
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.davidmacd.com%2Fdisclaimer.html&data=02%7C01%7Cjjwhite%40ets.org%7Cd01102d25bf543df0d2008d50030d6fb%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636415132125853712&sdata=w%2FxfJTzuDpn0oxpGlrcK0mmHSqr5k41zrsXRwxESUwU%3D&reserved=0>



On Wed, Sep 20, 2017 at 9:41 AM, Michael Cooper <cooper@w3.org> 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.

Michael



------------------------------

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