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".
   3. *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


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