Re: Discussion on SC numbering

I'd rather see the numbers at the end of each SC than left out on the FPWD

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, Jan 4, 2017 at 7:32 AM, Alastair Campbell <acampbell@nomensa.com>
wrote:

> Hi Glenda,
>
>
>
> So to summarise the impact for the FPWD:
>
> -          Remove the numbers and explain separately that the numbering
> is under discussion, but is removed for the purpose of the draft reviews.
>
> -          Mark the new (and possibly edited/re-levelled) ones so people
> can identify the changes.
>
> -          Explain (separately) that there will be overlap between old &
> new ones, once the new ones have sufficient support / consensus there
> *may* be a process of refining all the SC to make it more coherent.
>
>
>
> Then numbering is something we tackle later in the process, pre-CR I would
> assume?
>
>
>
> Cheers,
>
>
>
> -Alastair
>
>
>
>
>
> *From: *Glenda Sims <glenda.sims@deque.com>
> *Date: *Tuesday, 3 January 2017 at 17:59
> *To: *Alastair Campbell <acampbell@nomensa.com>
> *Cc: *GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
> *Subject: *Re: FW: Discussion on SC numbering
>
>
>
> Alastair,
>
>
>
> Here is what I'm thinking:
>
>    1. *Allow overlap in First Public Working Draft (FPWD) -* I agree with
>    everyone who is saying...for now...focus on adding not modifying SC and
>    accept overlap for the FPWD. Then we *should* carefully modify current
>    requirements to reduce overlap.
>    2. *Chill about the order of the 3 digit of new 2.1 SC -* For WCAG 2.1
>    I think we need to temporarily let go of our need for ideal ordering of SC,
>    and instead rely on great short names for each proposed SC
>    (and proper tagging for filtering).
>
>
>    - Of course, any new WCAG 2.1 SC will be under the correct #.#
>       Guideline,
>       - but this is not the time to renumber to put similar WCAG 2.1 SC
>       next to existing (and conceptually related) WCAG 2.0 SC.
>       - Example:  WCAG 2.0 1.4.3 Contrast (Minimum) is really just about
>       text.  Let's leave it that way.  It is already a complex SC.  For the
>       proposed WCAG 2.1 SC on color contrast for Informational Graphics and
>       Visual Focus Indicators (and other fun things)...we can propose to add new
>       success criteria in the 1.4.x section.  Will it be right next to 1.4.3 when
>       you look at SC in numeric order...Nope.  But when you filter by tags...it
>       will be right there...because both could be tagged with a world like
>       "color/colour" and "contrast".
>
>
>    1. *Add a 4th digit/character for children -* For any new WCAG 2.1 SC
>    that can truly be seen as a child of a WCAG 2.0 SC, I suggest we could add
>    a ".a" to the end.
>
>
>    - Example: Lisa had a great example of how 2.2.1 Timing Adjustable has
>       a clause that says "given at least 20 seconds to extend the time limit",
>       but this may be too short for COGA (and others).  So, COGA could propose
>       (for WCAG 2.1) that there is a new SC called 2.2.1.a Timing Adjustable
>       Extended.
>
> Happy New Year Y'all,
>
> G
>
>
> glenda sims    |   team a11y lead   |    deque.com    |    512.963.3773
> <(512)%20963-3773>
>
> *web for everyone. web on everything.* -  w3 goals
>
>
>
> On Tue, Jan 3, 2017 at 11:01 AM, Alastair Campbell <acampbell@nomensa.com>
> wrote:
>
> Hi everyone,
>
> Resending this on Josh’s request.
>
> In addition, in the call I suggested that we should probably proceed as
> though we are only adding not modifying and accept overlap for the FPWD.
> Then we *should* carefully modify current requirements to reduce overlap.
>
> I also asked a question from a previous email: I'm also curious if anyone
> knows of another guidelines-type standard that has added a significant
> number of requirements in a later version, how did they handle numbering or
> re-wording of previous requirements?
>
> On 23/12/2016, 11:14, Alastair Campbell wrote:
>
>
> Gregg wrote:
> >  What I was referring to though — was that we ALSO have some that
> purposely overlap.   Like    Don’t do this except — and  Don’t do this
> ever  (at two different levels).      We have a number of places where we
> have multiple SC that overlap — with SC at different levels increasing the
> requirement.
>
> Yes – which makes sense, and was something you could do in 2.0 because you
> could manipulate both SCs at the same time.
>
> In a situation where we cannot modify the current ones at all, it is not
> possible to add related requirements without causing overlap/confusion.
>
> To take a really simple case, WCAG 2.0 has one AA contrast SC:
> “1.4.3 Contrast (Minimum): The visual presentation of text and images of
> text…” – which only applies to text, and I think all the docs support that
> approach.
>
> Assuming the new contrast SCs for graphics & interactive elements pass
> muster, could we not rename the current one to “Text contrast (Minimum)”?
>
> Taking a more complex example:
> https://github.com/w3c/wcag21/issues/51
>
> Assuming for sake of argument that we agree the level should be raised
> from AAA to AA (e.g. new evidence of user-need and/or it would now be
> easier to implement), there are also proposed changes within the SC:
>
> ---------------
> 2. Width is no more than 80 characters or glyphs [del](40 if CJK)[/del]
> [ins]for Latin and Semitic based languages; or 40 for Chinese, Japanese,
> and Korean; or can be selected by the user[/ins].
>
> 3. Text is not fully justified (aligned to both the left and the right
> margins), [ins] or justification can be set by the user[/ins].
>
> 5. Text can be resized, without assistive technology, up to 200 percent in
> a way that does not require the user to scroll horizontally to read a line
> of text on a full-screen window.
>
> [ins]6. Increased line and border spacing can be added around blocks of
> text and objects, such that they can be increased up to 200% without loss
> of content or functionality.[/ins]
> ---------------
>
> The changes in points 2 & 3 appear minor, point 5 is in the existing SC
> but completely redundant with the new Resize content SC, and point 6 would
> require another technique and addition to the understanding doc.
>
> I can’t see how you would make those changes into a new SC without it
> being too specific? (I.e. criticised as just a technique).
>
> For those people saying we shouldn’t touch the existing SCs, are you
> suggesting we reject all modifications?
>
> Even if the response is: “we should take the changes and make new SCs”, I
> don’t think those new SCs would be able to meet the criteria, so the effect
> would be to reject most or all modifications.
>
> Cheers,
>
> -Alastair
>
>
>