Re: Proposed approach on WCAG 2.1 numbering and IDs

+1

glenda sims  |   team a11y lead   |    deque.com    |    512.963.3773
*web for everyone. web on everything.* -  w3 goals

[image: IAAP International Association of Accessibility Professionals:
Certified Professional in Accessibility Core Competencies (CPACC)]
<http://www.accessibilityassociation.org/certification>

On Tue, Sep 26, 2017 at 9:39 AM, Michael Cooper <cooper@w3.org> wrote:

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