Re: Discussion on SC numbering

Hi everyone,

I’ve put together some examples of how the numbering schemes could pan-out for guideline 1.4, it has really helped me visualise and understand how each could work:
https://alastairc.ac/tests/wcag21-examples/


I cherry-picked 5 new SCs from github, 4 LVTF and 1 COGA, partly because I know them reasonably well and partly because they are good for demonstrating issues with each approach.

Hopefully it is apparent they are not official! (Red banner, heading text, no-index meta element to prevent search engines listing them), but they match the styling of WCAG for the purpose of this exercise.

The main issues that jumped out at me is not the numbering, but issues that come from the “Not modifying existing SC” assumption, which has two impacts:


1.      The document become very muddled and confusing, especially in the case of new SCs which are increasing requirements of existing SCs.
For example, “Resize content” is visually underneath (therefore ‘less’ than?) the current “Resize text”, but it hugely overlaps in purpose and increases the requirement.
The COGA example of bringing up an AAA requirement to AA (with an additional point in it) is even more confusing, as you have two almost identical SCs at different levels.


2.      Increasing existing requirements without editing the existing SCs is fundamentally incompatible with number 8 of the SC requirements [1]: “Avoid creating a requirement for something that is already required by an existing Success Criterion.” (Lisa pointed this out near the end of yesterday’s call.)

I agree that SCs should overlap as little as possible, overlap makes testing harder and the communication of results much harder. However, we can’t apply that SC requirement without editing current SCs.

I think this is the most difficult issue to deal with, but it is more important and fundamental than which numbering scheme is used.

My opinion is that it is more important for WCAG 2.1 to be a coherent and understandable document than maintaining the exact wording of existing SCs. I agree that it should be backwards compatible, but we can modify (increase) current SCs and maintain backwards compatibility, and the change can be managed with an associated document that outlines the changes.

-------------------
On the numbering scheme, a few things became apparent:

Model 1, 4th level numbering: Having an additional number (e.g. 1.4.5.1) makes that SC appear to be a sub-SC underneath its parent, even if it is unrelated. For example, having the enhanced “Visual Presentation” under “Images of Text”.

Model 2, append-only: Putting all the new SCs at the end means that you lose the association between similar SCs. For example, you have the old Resize text, and then the new Resize content way underneath, which is actually a stronger requirement. Odd, and I think this hurts understandability the most.

Model 3, append numbers but maintain topical ordering: Maintains a good order and association, it is just odd to have 1.4.11 following 1.4.3. Assuming we don’t use model 6, this would be my preference.

Model 4, level markers: similar to model 3 but I think the “1.4.AA.3” looks odd.

Model 5, renumbering: Avoids the problems of models 1-4, but for experienced testers/consultants this would be confusing for years.

Model 6, remove numbers: This (now) makes the most sense to me, especially if a WCAG 2.2 is possible. Any of the problems above would be magnified if more SCs are slotted in later for a 2.2. It means we can keep a good order, with the A/AA/AAA groupings and

I also put together an example based on model 6, but allowing for updating the 2.0 SCs:
https://alastairc.ac/tests/wcag21-examples/wcag21-model6b.html


This allowed me to:

-          Remove the AAA SC for “Visual presentation”, as it is supplanted by the new AA version.

-          Put the new “Resize content” first, and follow it with a “Resize text only”, which is then a fall-back SC for when the exceptions for Resize content are active for mobile layouts or diagram type content.

-          Update the handle of the current “Contrast” to “Text contrast”, to differentiate it from the new graphics & interactive element SCs. That might be a step too far, but it would be nice to do.

Of course, those changes might not be relevant depending on which SCs get through in whatever form, but they are the kind of changes that I think we will need to make for WCAG 2.1 to be an understandable and successful update.

I think we are damned if we do and damned if we don’t, people will complain either way. However, looking ahead two to three years I think coherence will trump maintaining the exact current SC text.

Sorry for the marathon email, and, erm, happy holidays!
-Alastair

1] https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria