RE: Discussion on SC numbering

+1 to Andrew. We should not touch current SC. If there is slight overlap with SC, so be it….:-)

 

​​​​​* katie *

 

Katie Haritos-Shea 
Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)

 

Cell: 703-371-5545 |  <mailto:ryladog@gmail.com> ryladog@gmail.com | Oakton, VA |  <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | Office: 703-371-5545 |  <https://twitter.com/Ryladog> @ryladog

NOTE: The content of this email should be construed to always be an expression of my own personal independent opinion, unless I identify that I am speaking on behalf of Knowbility, as their AC Rep at the W3C - and - that my personal email never expresses the opinion of my employer, Deque Systems.

 

From: Andrew Kirkpatrick [mailto:akirkpat@adobe.com] 
Sent: Wednesday, December 21, 2016 9:42 AM
To: Alastair Campbell <acampbell@nomensa.com>; WCAG <w3c-wai-gl@w3.org>
Subject: Re: Discussion on SC numbering

 

Thanks Alastair, this is helpful.

 

I like the idea of keeping the text of each 2.0 SC the same and adding SCs for 2.1. I’m worried that if we don’t do that that because we feel that we can modify the SC in ways that are backward compatible we will find that we have inadvertently broken backward compatibility because of something that we miss. 

 

If we do maintain the text, then we have a clear development path for the incorporation of new SC and the order and the numbering can be changed (and re-changed) easily. We could also have two official versions if we wanted to do something simple like grouping the A/AA/AAA items together in one version of listing the SC in order in another.

 

When I think about the volume of training materials and testing resources that have built in the current SCs, and that rules like EN 301 549 and (hopefully) the new 508 that include the 2.0 SCs, I think that the “upsell” to 2.1 for people who have learned how to work with 2.0 will be more like a dot-release instead of a major release.

 

As you point out, no choice is perfect.

 

Thanks,

AWK

 

Andrew Kirkpatrick

Group Product Manager, Standards and Accessibility

Adobe 

 

akirkpat@adobe.com <mailto:akirkpat@adobe.com> 

http://twitter.com/awkawk

 

From: Alastair Campbell <acampbell@nomensa.com <mailto:acampbell@nomensa.com> >
Date: Wednesday, December 21, 2016 at 06:28
To: WCAG <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org> >
Subject: Re: Discussion on SC numbering
Resent-From: WCAG <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org> >
Resent-Date: Wednesday, December 21, 2016 at 06:29

 

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