RE: Discussion on SC numbering

Alistair,

 

I get your point. Hmmmm…

 

The problem is I *thought* we were not going to change the existing SC, and that this was clearly indicated to the TFs when proposing new SC….:-(

 

Boy this is one reason it would have been nice to have *clearly defined* as a requirement (and again, I thought it was). Add to the lessons-learned department….

To be backwards compatible it looks as if the new content they suggest for an existing SC will have to became a new SC related just to the specific changes.

 

This would sort of go along with the idea that each new SC should have - and then test – very distinct criteria.

 

 

 

​​​​​* 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: Alastair Campbell [mailto:acampbell@nomensa.com] 
Sent: Wednesday, December 21, 2016 10:59 AM
To: Katie Haritos-Shea GMAIL <ryladog@gmail.com>
Cc: 'WCAG' <w3c-wai-gl@w3.org>
Subject: Re: Discussion on SC numbering

 

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

 

Hi Katie,

 

That isn’t the situation for many new SCs, the impact of that approach is that either:

-          None of the ‘increased’ requirements can make it through to 2.1 (including many from COGA), or

-          We will have duplicate (raised level) or severely overlapping SCs.

 

For example (from a quick skim, there are probably more):

https://github.com/w3c/wcag21/issues/56

https://github.com/w3c/wcag21/issues/51

https://github.com/w3c/wcag21/issues/40

https://github.com/w3c/wcag21/issues/33

https://github.com/w3c/wcag21/issues/32

https://github.com/w3c/wcag21/issues/29

https://github.com/w3c/wcag21/issues/22

https://github.com/w3c/wcag21/issues/13

https://github.com/w3c/wcag21/issues/7

https://github.com/w3c/wcag21/issues/77 

 

All of those will either overlap *a lot*, or they can’t go into 2.1.

 

NB: I had raised this previously [1], but it wasn’t really the time to discuss it as the SCs weren’t close enough. Now they are.

 

What I’m saying is that if a new SC is “Good” (meets the SC requirements apart from overlap), then we tackle each case, analyse the understanding, techniques & failures docs, and if it can be done in a backwards compatible way, update the existing SC.

 

Cheers,

 

-Alastair

 

1] https://lists.w3.org/Archives/Public/w3c-wai-gl/2016OctDec/0018.html