Proposed approach on WCAG 2.1 numbering and IDs

There's been a lot of discussion about how we should number WCAG 2.1 SC, 
whether we should renumber WCAG 2.0 SC, and whether and how SC numbers 
serve as IDs. There have been a lot of suggestions but I think most of 
the proposed solutions introduce their own problems. In addition to 
maintaining backwards compatibility with WCAG 2.0, we also need to 
consider forwards compatibility with a potential WCAG 2.2 as well as 
minimize the set of different approaches that could confuse people more 
than they help.

Accordingly, I suggest we adopt a "simplest" approach to resolving the 
debate so we can unblock our work on SC harmonization:

  * We've heard loud and clear that people don't want WCAG 2.0 SC
    renumbered, so we should stick to that.
  * Attempts to come up with different numbering schemes for 2.1 SC will
    just be more confusing, so we should number them using the same
    pattern that was used for 2.0.
  * The main reason we needed to contemplate renumbering was to sort SC
    within a given guideline together by conformance level, meaning some
    2.1 SC would get inserted between 2.0 SC. But in discussion, the
    importance of keeping conformance levels in a block seemed not to be
    too high. Therefore we should just leave 2.1 SC tacked on to the end
    of the guideline with numbering as they naturally land, as we've
    already done. If we do a 2.2 and add more SC, we'd just continue that.
  * The How to Meet / Quick Reference document should provide sorting
    features that allow SC of a given conformance level to be grouped
    together, causing numbers to be discontiguous if people choose that
    sort. But the static spec itself should not have discontiguous SC
    numbers, so SC will appear in number order, not always in
    conformance level order.
  * Implementers that want to use SC numbers as IDs in their own
    implementations can do so, and won't have existing WCAG 2.0
    implementation disrupted. However, we should provide better
    documentation of the IDs that already exist, which are generated
    from the title of each SC and are shown in the "permalinks" at the
    end of the line by each SC. Beyond this support we provide for
    referencing, we should not be in the business of defining internals
    of implementations.
  * People can refer to SCs colloquially either by number or by the SC
    title, which is already brief yet descriptive. With those two
    reference forms available, we should not introduce any further ones,
    which would have diminishing returns.

Essentially this all boils down to, let's not make any changes from how 
the draft is currently structured to accommodate numbering and IDs. With 
this stabilized, we can now look at other issues on the SC without 
worrying about the impact on numbering.

Michael