RE: Combining the sizing SCs

Hi Gregg,


To be clear, I do not want to combine as much as possible….this was said to be desired by those who want to add as few as possible SC…those who think it is already too long. I am not one of those persons.


I completely agree that they should be a specific and distinct as possible. And the concern about having too many is a bad idea in general. I think the testability control, will prevent too many from being approved, in a natural way.






* katie *


Katie Haritos-Shea 
Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)


Cell: 703-371-5545 |  <> | Oakton, VA |  <> LinkedIn Profile | Office: 703-371-5545 |  <> @ryladog


From: Gregg Vanderheiden [] 
Sent: Monday, October 3, 2016 10:24 AM
To: Katie Haritos-Shea <>
Cc: Alastair Campbell <>; GLWAI Guidelines WG org <>; public-low-vision-a11y-tf <>
Subject: Re: Combining the sizing SCs


Hi Katie


Why do you say you want to combine SC as much as possible.   As noted earlier, this causes all sorts of problems. 

* what if you meet half but not the other.  How do you report it without confusion.  

* you can’t check it as done - because half not done
* you can’t not check it or that sounds like neither is true

* in the How to Meet    and   Understanding WCAG   docs -  

* how do you list techniques as sufficient?   

* there may be 3 for one part and 4 options for the other. 
* you would need to list 12 combinations to say that any one combination was sufficient? 
* or else you create two separate conformance sections with two separate descriptions, rationales, examples, resources etc.  all for the same SC.  

* since separating into two this way - why not at the SC level

* Also messes up and discussion since you always have to discuss two issues when you talk about an SC


What is the saving in combining?  the advantage? 


I think I am missing something. 





On Oct 3, 2016, at 8:05 AM, Katie Haritos-Shea < <> > wrote:



While this seems like a good idea, remember that 2.1 has to be 100% backwards compatable (in that it will add new things, but all of the old things will still be true), so it may be more complicated to so. 

In other words you would still have to have the Resize SC (with it existing number) and a Resize Text plus Resize Content (with a new number). So it seems best to just make the new idea, Resize Content by itself the new number.

We *do* want to combine all NEW SC ideas as much as we can, but combining old with a new will be much harder to do, considering our requirements for 2.1.

Do others agree or disagree that this is consistant with one of the goals of 2.1?

Katie Haritos-Shea


On Oct 3, 2016 4:59 AM, "Alastair Campbell" < <> > wrote:

Hi everyone,


I’m not sure how many people track the github issues, but I added one on Friday about the sizing SCs: 


It covers the issues that came up at the meeting in TPAC, and proposes a replacement for Sizing All Content & Text-Sizing. 


I don’t have access to editing the LVTF wiki area, but it’s probably best to have a new one and copy over some of the associated text for benefits, techniques etc.


Is it best to discuss on-list or on-github?


Kind regards,






Alastair Campbell <> 

tel: +44 (0)117 929 7333 <tel:%2B44%20%280%29117%20929%207333>  / 07970 879 653

follow us: @we_are_nomensa or me: @alastc


Nomensa Ltd. King William House, 13 Queen Square, Bristol BS1 4NT

Company number: 4214477 | UK VAT registration: GB 771727411


Received on Monday, 3 October 2016 14:30:33 UTC