Re: Discussion on SC numbering

Since whatever we choose will probably make sense to us, and will less
likely make sense to our stakeholders, would it make sense to come up with
our top 3 ideas that have the most consensus and then go public asking for
their option with a poll ?

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Wed, Dec 21, 2016 at 10:02 AM, Alastair Campbell <acampbell@nomensa.com>
wrote:

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