WCAG 2.1 SC Numbering

Introduction

We need to accommodate additional success criteria in WCAG 2.1 and there is a decision that needs to be made regarding how new SC or changed SC are numbered. This page details a few possible strategies for handling numbering and details pros and cons for each option to help the WG make a decision. The description for each option should indicate how the different types of additions/changes to the current set of SC would be handled. Examples are always helpful!

Types of additions / changes to success criteria

Adding a new SC for an existing guideline
Adding a new SC for a new guideline
Changing the text of an existing SC
Amending the text of an existing SC via the addition of a new SC
Moving an SC to a higher level (e.g. AAA to AA)
Moving an SC to a higher level and changing the text of the SC

What Guidelines could have new SCs in collision with exisiting ones

Any new Success Criterion that is under a *NEW* Guideline can have the regular 3 level number without colliding with another SC number . (This is the case with most of the proposed mobile SCs, i.e., Pointer 2.5.1))
Guidelines 1.1, 1.3 and 4.1 only have Level A SCs so any new SCs under them can keep the 3 number format without colliding with anything ... just add x.y.z numbering after the last existing SCs at the desired level.
The real issue of collision is for new A or AA SCs under existing Guidelines that have AA of AAA already there. That is

 Guidelines 1.2, 1.4, 2.1, 2.2, 2.3, 2.4, 3.1, 3.2, 3.3

Template for proposal

This is a template for making a proposed numbering scheme, to keep them consistent with each other. Do not delete or overwrite this template. Please copy it to add a new proposal at the bottom.

To use the template, put a brief label for the proposal (the part with two equal signs surrounding it). Describe the proposal in more detail in the subsequent text, where these instructions are. List pros and cons you can think of as bullets under the appropriate heading.

Pros

Cons

(Model 1) 4 tier numbering

Provide a 4 tier numbering system. Where possible new SCs will be given 3 numbers, but in order to fit them into the right Guideline sometimes another level will be needed. New Mobile may be under a new Guideline 2.5 and therefore can have their own 3 level numbering system 2.5.1, 2.5.2 etc... However additional Level A SC's to Guideline 1.3 there would be an additional level to allow it to be inserted at the right Level

3.1 Readable
- 3.1.1 Language of Page A
- 3.1.2 Language of Parts AA
- 3.1.2.1 New COGA AA
- 3.1.3 Unusual Words AAA
- 3.1.4 Abbreviations AAA
- 3.1.5 Reading Level AAA
- 3.1.6 Pronunciation AAA

A variation of this is the use of a letter:

3.1 Readable
- 3.1.1 Language of Page A
- 3.1.2 Language of Parts AA
- 3.1.2 (a) New COGA AA
- 3.1.3 Unusual Words AAA
- 3.1.4 Abbreviations AAA
- 3.1.5 Reading Level AAA
- 3.1.6 Pronunciation AAA

Pros:

Can keep and view the basic structure of the numbering in WCAG. People knowledgeable in WCAG will quickly know it.
This would be useful for when existing SC are "chiselled" into smaller bits (i.e. 1.3.1 is a large SC taht could be broken int smller pieces)

Cons:

Four layers seems a bit inelegant, and may confuse newcomers to WCAG
There may be a feeling that the forth level is kind of a second class citizen of SC, that some may view as a kind of like AAA which is not as required as those in the number system.
In statutes and regulations, adding another level of numbers generally indicates that the new section is a subsection of the layer above it. (e.g., 1.3.1.1 is a subsection of 1.3.1; 3.1.2(a) is a subsection of 3.1.2) This would be desirable where the new section is tied to the section above, but not where the new section stands on its own.
May have impact on tools.

(Model 2) Add a new section to the end of each existing Guideline that will have new SCs

Put all the new SCs at the end of their respective Guidelines. Where possible new SCs will fit them into the right Guideline. i.e., New Mobile may be under a new Guideline 2.5 and therefore can have their own 3 level numbering system 2.5.1, 2.5.2 etc... but those that don't fit in would be at the end of each Guideline under which they fall.

3.1 Readable
- 3.1.1 Language of Page A
- 3.1.2 Language of Parts AA
- 3.1.3 Unusual Words AAA
- 3.1.4 Abbreviations AAA
- 3.1.5 Reading Level AAA
- 3.1.6 Pronunciation AAA
- 3.1.7 New COGA AA
- 3.1.8 New Mobile A
- 3.1.9 New COGA AA

Pros:

There are advantages to sticking with 3 levels of numbers.
Adding new Success Criteria numerically as part of an expanding list allows for easier identification of new SC

Cons:

Then we'll have some new AA SCs which come AFTER the AAA SCs from 2.0
There may be a tendency to disregard the new SCs that appear AFTER the AAA's

(Model 3) Stick with 3 tier numbering, same as previous, but in the final presentation of the document, don't place them in numerical order, place them with levels

The way this would work would be as follows:

So you might have

3.1 Readable
- 3.1.1 Language of Page A
- 3.1.7 (new) COGA SC A
- 3.1.2 Language of Parts AA
- 3.1.3 Unusual Words AAA

Pros:

the familiar pattern of ruler-separated A | AA | AAA sections of Success Criteria within Guidelines is upheld

Cons:

rendering a numerically ordered list asymmetrically different is an anti-pattern, and could introduce confusion
If items are not in numeric order, readers would have to use a software Search function to find a specific SC, and those who are reading on paper could have great difficulty.
It trick readers into thinking an SC doesn’t exist, when they can’t find it where they expect it to be.

Link to proposed SCs, and Guidelines

(Model 4) Introduce a level marker to SC numbers

The core issue driving this debate seems to be that there is an implied semantic for the number of a SC with respect to its conformance level. In theory, the Principles and Guidelines don't have any meaning to the numbers assigned to them, so we could add those without causing angst about introducing confusion. Within a conformance level, SC numbers also don't have semantics - SC #.#.1 and #.#.2 could have their order switched no problem, if they are both at the same conformance level.

If we renumber the SC to include the conformance level in the numbering scheme, e.g,. #.#.A.1 and #.#.A.2, followed by #.#.AA.1 or something then it would be no problem to introduce a #.#.A.3 without bumping anything else out of the way - the first AA SC following would still keep its number #.#.AA.1.

Applying this example to Guideline 1.2, the numbers would become:

1.2.1 -> 1.2.A.1
1.2.2 -> 1.2.A.2
1.2.3 -> 1.2.A.3
1.2.4 -> 1.2.AA.1
1.2.5 -> 1.2.AA.2
1.2.6 -> 1.2.AAA.1
1.2.7 -> 1.2.AAA.2
1.2.8 -> 1.2.AAA.3
1.2.9 -> 1.2.AAA.4

Other values could be used instead of A, AA, and AAA, such as A, B, C or 1, 2, 3. Adding a new Level A SC, it would get the number 1.2.A.4, without bumping the numbering of SC after it.

Pros

Includes conformance level in the semantic structure of numbering, which we seem to presume anyway.
Allows SC to be inserted without bumping the numbering of SC at other conformance levels.

Cons

Causes a renumbering of all the SC from WCAG 2.0, with the cons of that.
It's effectively a 4-level numbering system, making numbers harder to remember.

(Model 5) Renumber all the SC

The WCAG 2.0 SC didn't get their current numbers until the current set of SC was finalized, very late in the process. Every time we published a new draft, the SC had new numbers based on what had been added and removed. The numbers were auto generated and there was no attempt to preserve them between drafts (in contrast to IDs and handles, which we did preserve as long as SC remained substantially the same). Therefore, we clearly weren't thinking of them as having much semantic importance.

We could continue that in 2.1 and just number the SC appropriate to where they land, after insertions, level changes, etc. Many SC would get new numbers. They would all keep their handles and IDs.

Pros

Straightforward.
Consistent with WCAG 2.0.
Doesn't require a lot of angst to think about what number something should have.

Cons

WCAG 2.0 SC numbers do seem to have been hardened into stone (albeit arguably inappropriately) in many contexts, so this breaks that.
Users wanting to compare what success criteria requirements have changed with the 2.1 update cannot compare across the same SC number which makes mapping tracing changes somewhat more confusing
References to Success Criteria in past discussions e.g. on W3C mailing lists or the Webaim mailing list which are so important for learning get more confusing if one always has to process whether references point to the number before or after renumbering.

(Model 6) Remove SC numbers altogether

In WCAG 2.1, do not use SC numbers, to avoid confusion with the numbers that were in WCAG 2.0. Instead, just rely on the handles that are also provided for SC and are much less likely to be impacted by new or changed SC. The SC also each have IDs that are not the number, which we should encourage more use of.

Pros

Avoids angst about renumbering.
Removes something from the guidelines that actually doesn't have an instrinsic semantic meaning, yet people presume it does.
Would put more focus on referring to SC by their handles, which are more semantically associated with them anyway.

Cons

Will be seen as a shocking change from WCAG 2.0.
Many orgs may be using the numbers as IDs in their own references and tools - even if inappropriately.
We do know some SC by their number, particularly 1.1.1 (the alt text one) and 1.3.1 (the kitchen sink one), so might be uncomfortable to lose.
Potentially difficult for international and non-English communication that use localized handles.

Non-Specific Feedback

(Feedback that is applicable in any or some of the proposed models)

The WCAG WG can look to statutes for patterns of changes. We add, remove, and even renumber statutes all the time. While each state can vary how they do it, there is a fair amount of consistency. People in the legal field have dealt with this type of issue for years and years, so the WCAG WG may find it helpful to look to the patterns used in statutes and see if that would work for WCAG changes, rather than reinventing the wheel.

Legislative approach (or “when to try and assign numbers”)

Generally legislation falls under two broad categories:

New legislation
Specific intent to amend/correct/repeal existing statutes

If legislation is new, often the legislators do not worry about numbering until the dust has settled and the new bill has been passed into law. This is very much like the WCAG WG, where we do not need to identify SC numbers for new sections until we have them all agreed up and see where and how they fit.

If the intent is to modify an existing law, that law’s citation will be identified in the bill. This is very much like the WCAG WG, when we know we want to address something that was missing, unclear, or needs changing in a current SC.

To renumber or not to renumber…

In the legislative/statutory world

renumbering generally the last option
people rely on section and title/chapter numbers – these become citations.
if renumbering, Revisor of Statutes creates a detailed table to show the old number, the new number, when it took effect, etc.
WCAG – has become international standard and may have been adopted in whole by states, countries, etc. If we renumber, the numbers will no longer be consistent.
Inconsistent numbers/citations mean everything that cites them contains invalid cites *When renumbering, often it is done by whole groups of numbers. For example, if the WG needed a new Principle and it had to be first:

    Something critically important
    Perceivable
    Operable
    Understandable
    Robust

In the above example, all existing content would get "moved down" and renumbered to make room for the new principle.

Patterns for inserting a new section between existing sections

Pattern A: Use a number after the title

In the example below, is it likely that 13A, 13B, and 13C were added after 13, but related to it. They were classified in with Title 13, but were different enough to get their own title number tied to 13, but distinct from it. This is a very common format.

  13 	GOVERNMENT DATA PRACTICES
  13A 	RELEASE OF INFORMATION BY FINANCIAL INSTITUTIONS
  13B 	MATCHING PROGRAMS; COMPUTERIZED COMPARISON OF DATA
  13C 	ACCESS TO CONSUMER REPORTS
  14	ADMINISTRATIVE PROCEDURE

WCAG Guideline level examples (fake)

This could be added at any level, here at the Guideline level.

  1. Perceivable
  1.1 Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language. 
  1.2 Provide alternatives for time-based media.
  1.3 Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
  1.3A Another Guideline about using customization that seems close to 1.3, but distinct.
  1.3B Another Guideline about customization that also seems consistent with 1.3 and 1.3A, but is also distinct
  1.4 Distinguishable: Make it easier for users to see and hear content including separating foreground from background.

WCAG Success Criteria level examples (fake)

   1.2.2 Captions (Prerecorded): Captions are provided for all prerecorded audio ... (Level A)
   1.2.3 Audio Description or Media Alternative (Prerecorded): ... (Level A)
   1.2.3A Some new SC that is related to this concept, but distinct
   1.2.3B Another new SC that is related but distinct 
   1.2.4 Captions (Live): Captions are provided for all live audio content ... (Level AA)

Pattern B: Add another digit on the end of a number to make it larger.

Like using another layer and difficult to find example.
Can be confusing.
Generally used at the smallest level (for WCAG, at the SC level)

Statute Example

    Sec. 2.007. AFFIDAVIT OF ABSENT APPLICANT
    Sec. 2.0071. MAINTENANCE OF RECORDS BY CLERK RELATING TO LICENSE FOR ABSENT APPLICANT
    Sec. 2.008. EXECUTION OF APPLICATION BY CLERK

WCAG Guideline examples (fake)

    1. Perceivable
    1.1 Provide text alternatives for any non-text content ... 
    1.2 Provide alternatives for time-based media.
    1.3 Create content that can be presented in different ways ...
    1.31 Another Guideline about using customization (related to 1.3, but distinct)
    1.32 Second new Guideline about customization (also related to 1.3, but distinct)
    1.4 Distinguishable: Make it easier for users to see and hear content including separating ...

WCAG Success Criteria level examples (fake)

    1.2.2 Captions (Prerecorded): Captions are provided for all prerecorded audio ... (Level A)
    1.2.3 Audio Description or Media Alternative (Prerecorded): An alternative for ... (Level A)
    1.2.31 Some new SC that is related to this concept, but distinct (Level A)
    1.2.32 Another new SC that is related but distinct (Level A)
    1.2.4 Captions (Live): Captions are provided for all live audio content ... (Level AA)

Patterns for adding a subsection.

This is used when something is very closely tied to an existing section, but has not been covered with enough detail and needs to be called out separately

Statutory Example

    (e) The operator of a facility issued an operating certificate by the department shall…
       (1) Upon written request by the operator, the department may…
           (i) the specific regulation for which a waiver is sought;
           (ii) the reasons the waiver is desirable or necessary; and
           (iii) a description of what will be done to achieve or maintain …
       (2) The department may require that the operator adopt additional methods …

WCAG example (fake)

    1.4.3 Contrast (Minimum): The visual presentation of text and images of text ... (Level AA)
      Large Text: ...
      Incidental: ...
      Logotypes: ...
    1.4.3 (a) Minimum contrast requirements for non-text action items (buttons)
    1.4.3 (b) Maximum contrast requirements for ...
    1.4.4 Resize text: Except for captions and images of text ... (Level AA)

How to keep track of additions and deletions