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

RE: Combining the sizing SCs

From: Katie Haritos-Shea GMAIL <ryladog@gmail.com>
Date: Mon, 3 Oct 2016 11:14:11 -0400
To: "'Gregg Vanderheiden RTF'" <gregg@raisingthefloor.org>
Cc: "'Alastair Campbell'" <acampbell@nomensa.com>, "'GLWAI Guidelines WG org'" <w3c-wai-gl@w3.org>, "'public-low-vision-a11y-tf'" <public-low-vision-a11y-tf@w3.org>
Message-ID: <0c6901d21d88$cc3886a0$64a993e0$@gmail.com>
Yea - combining doesn’t make it much shorter -  just reduces the number of SC by making it much more complicated — a worse problem I think than length. 

 

Agreed!

 

​​​​​

 

 

 

* katie *

 

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

 

Cell: 703-371-5545 |  <mailto:ryladog@gmail.com> ryladog@gmail.com | Oakton, VA |  <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | Office: 703-371-5545 |  <https://twitter.com/Ryladog> @ryladog

 

From: Gregg Vanderheiden RTF [mailto:gregg@raisingthefloor.org] 
Sent: Monday, October 3, 2016 10:35 AM
To: Katie Haritos-Shea <ryladog@gmail.com>
Cc: Alastair Campbell <acampbell@nomensa.com>; GLWAI Guidelines WG org <w3c-wai-gl@w3.org>; public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>
Subject: Re: Combining the sizing SCs

 

Ah 

great.   

 

Yea - combining doesn’t make it much shorter -  just reduces the number of SC by making it much more complicated — a worse problem I think than length. 

 

best 


gregg 

 

On Oct 3, 2016, at 10:29 AM, Katie Haritos-Shea GMAIL <ryladog@gmail.com <mailto:ryladog@gmail.com> > wrote:

 

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 |  <mailto:ryladog@gmail.com> ryladog@gmail.com | Oakton, VA |  <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | Office: 703-371-5545 |  <https://twitter.com/Ryladog> @ryladog

 

From: Gregg Vanderheiden [ <mailto:gregg@raisingthefloor.org> mailto:gregg@raisingthefloor.org] 
Sent: Monday, October 3, 2016 10:24 AM
To: Katie Haritos-Shea < <mailto:ryladog@gmail.com> ryladog@gmail.com>
Cc: Alastair Campbell < <mailto:acampbell@nomensa.com> acampbell@nomensa.com>; GLWAI Guidelines WG org < <mailto:w3c-wai-gl@w3.org> w3c-wai-gl@w3.org>; public-low-vision-a11y-tf < <mailto:public-low-vision-a11y-tf@w3.org> public-low-vision-a11y-tf@w3.org>
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. 

 

thx 


gregg

 

On Oct 3, 2016, at 8:05 AM, Katie Haritos-Shea < <mailto:ryladog@gmail.com> ryladog@gmail.com> wrote:

 

Alistair,

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
703-371-5545

 

On Oct 3, 2016 4:59 AM, "Alastair Campbell" < <mailto:acampbell@nomensa.com> acampbell@nomensa.com> wrote:

Hi everyone,

 

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

 <https://github.com/w3c/low-vision-SC/issues/16> https://github.com/w3c/low-vision-SC/issues/16

 

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

 

-- 

 

Alastair Campbell

 

 <http://www.nomensa.com/> www.nomensa.com

tel:  <tel:%2B44%20%280%29117%20929%207333> +44 (0)117 929 7333 / 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 15:14:46 UTC

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