W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2016

Re: Discussion on SC numbering

From: Alastair Campbell <acampbell@nomensa.com>
Date: Wed, 21 Dec 2016 17:02:09 +0000
To: Katie Haritos-Shea GMAIL <ryladog@gmail.com>
CC: 'WCAG' <w3c-wai-gl@w3.org>
Message-ID: <54B79368-891C-4802-8716-8003C8341769@nomensa.com>
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.



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

Received on Wednesday, 21 December 2016 17:02:45 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:07 UTC