Re: Discussion on SC numbering

1) I agree.  many people know them by their number and not their name.     so at least for the existing ones — put the number at the end.

2) if you edit and old one — you should use redlining so that it is easy to see/determine what the changes are without having to eyeball two versions of the text back and forth (which some people cannot do). 

Gregg C Vanderheiden
greggvan@umd.edu



> On Jan 4, 2017, at 7:38 AM, David MacDonald <david100@sympatico.ca> wrote:
> 
> I'd rather see the numbers at the end of each SC than left out on the FPWD
> 
> Cheers,
> David MacDonald
>  
> CanAdapt Solutions Inc.
> Tel:  613.235.4902
> LinkedIn 
>  <http://www.linkedin.com/in/davidmacdonald100>
> twitter.com/davidmacd <http://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 <mailto: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 <mailto:glenda.sims@deque.com>>
> Date: Tuesday, 3 January 2017 at 17:59
> To: Alastair Campbell <acampbell@nomensa.com <mailto:acampbell@nomensa.com>>
> Cc: GLWAI Guidelines WG org <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>
> Subject: Re: FW: Discussion on SC numbering
> 
>  
> 
> Alastair,
> 
>  
> 
> Here is what I'm thinking: 
> 
> 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.
> 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".
> 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 <http://deque.com/>    |    512.963.3773 <tel:(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 <mailto: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 <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
> 
>  
> 
>