Re: Proposed approach on WCAG 2.1 numbering and IDs

+1 to this proposal
Detlev

Sent from phone

> Am 26.09.2017 um 16:39 schrieb Michael Cooper <cooper@w3.org>:
> 
> 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