Re: Discussion on SC numbering

Katie wrote:

> 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….:-(



I took that as a strong steer, but on the other hand, how do you increase an existing requirement without overlap? The page on SC requirements even has a section on updating an SC…





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

I think that would be too messy and confusing, especially when they are minor *additive* changes.



The Resize Content [1] one we can probably get away with, but worth noting that it has to deal with Mobile (type) user-agents having a different method of layout and different sizing methods from desktop. That wasn’t a problem for WCAG 2.0!



Even so, on a first read you would think, “Why are there two?” One is clearly a stronger requirement, but it will appear to be a sub-requirement. (Depending on order & numbering.)



I cannot see any possible way of wording Resize content (within the SC requirements) that would prevent overlap whilst increasing the sizing requirement.





Laura wrote:

> Move IDs to the end of each SC



Thanks, I also have difficulty remembering the numbers. Well, past 1.1.1 anyway!  The 20/21 thing stumped me for a second, but I can see that having the dot separator (2.1) would make it too ‘dotty’.


Having “ID: 1.4.4(20)” and “ID: 1.4(21)4” implies the 2.1 is replacing the previous, but in which case why have both?



Perhaps it could be something like “ID 2.0: 1.4.7”, “ID 2.1: 1.4.8“.



Overall though, I do like the idea of de-emphasising the IDs, it makes the ordering more flexible. It becomes an enhancement for experts, toolmakers and legal use, without confusing the largest group who (should) use the guidelines.



Cheers,



-Alastair



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