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

Re: Discussion on SC numbering

From: David MacDonald <david100@sympatico.ca>
Date: Wed, 21 Dec 2016 10:57:09 -0700
Message-ID: <CAAdDpDY2yaHFBmNMgXYJzOgxtcBDbt7bvozu97U7ewa8mR6Y8Q@mail.gmail.com>
To: Alastair Campbell <acampbell@nomensa.com>
Cc: Katie Haritos-Shea GMAIL <ryladog@gmail.com>, WCAG <w3c-wai-gl@w3.org>
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
>
>
>
>
>
>
>
Received on Wednesday, 21 December 2016 17:57:43 UTC

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