Re: Combining SCs

+1

gregg

> On Oct 4, 2016, at 11:26 AM, Katie Haritos-Shea GMAIL <ryladog@gmail.com> wrote:
> 
> JF: The trick for this WG going forward is to find the porridge (or soft bed) that is "just right".  :-) <>
>  
> I wouldn’t completely disagree, but you will see John, if you undertake the work of defining/assessing the testability of each proposed SC, as this WG is tasked to do, that combined requirements make testability harder to accomplish – and, makes it harder to have an SC be N/A in those cases that it easier to bypass un-related content when testing. 
>  
> This important work is not about the length of the spec, but about its usefulness to implementers and – most importantly, the successfulness of improving accessibility for users with disabilities. 
>  
> And, not so much about relying on the good-will of “W3C members outside of the daily activities of this group that [worry about the] spec bloat of WCAG”, if they do not understand or care about the needs of users this spec is being built for.
>  
>  
> ​​​​​
>  
>  
>  
> * katie *
>  
> Katie Haritos-Shea 
> Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)
>  
> Cell: 703-371-5545 | ryladog@gmail.com <mailto:ryladog@gmail.com> | Oakton, VA | LinkedIn Profile <http://www.linkedin.com/in/katieharitosshea/> | Office: 703-371-5545 | @ryladog <https://twitter.com/Ryladog>
>  
> From: John Foliot [mailto:john.foliot@deque.com] 
> Sent: Tuesday, October 4, 2016 11:03 AM
> To: Katie Haritos-Shea GMAIL <ryladog@gmail.com>
> Cc: Alastair Campbell <acampbell@nomensa.com>; WCAG <w3c-wai-gl@w3.org>; public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>
> Subject: Re: Combining SCs
>  
> > “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."
> 
> > 
> ​...​
> the concern about having too many is a bad idea in general.
> 
> ...and therein lies the rub
> ​ 
> - not everyone agrees with that statement at face value. 
>  
> ​T​
> here is a Goldilocks problem here between to vague and too many,
> ​ and it will be something we will have to struggle through,​
> but I did hear from W3C members outside of the daily activities of this group that spec bloat of WCAG is a concern, and so not operating with that understanding may prove hurtful to us
> ​ (for example, as we re-charter this WG within the W3C)​
> . We need to strive for the right balance and accept that too many is indeed too many, and as equally hurtful as "kitchen sink" 
> Success ​
> Criteria​
> like 1.3.1. 
>  
> (For example, UAAG was referenced to me as being 'bloated', with 26 Guidelines,
> ​ ​
> and
> ​ 
> 112 Success Criteria
> ​)​
>  
> > 
>  I’d rather have more clearly defined, scoped and distinctly testable SC – than some arbitrary limit on the number of SC.
>  
> ​I agree that setting some arbitrary number going forward is self-defeating, but I don't necessarily agree that some ​combinations and merging of SC should be off the table either. The trick for this WG going forward is to find the porridge (or soft bed) that is "just right".  :-)
>  
>  
> ​JF​
>  
>  
> On Tue, Oct 4, 2016 at 4:41 PM, Katie Haritos-Shea GMAIL <ryladog@gmail.com <mailto:ryladog@gmail.com>> wrote:
>> John, <>
>>  
>> In your busy and time-stealing bad luck in travels you missed a discussion about this with Gregg and I. 
>>  
>> Where I said “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.”
>>  
>> So, in short, that fact that here are 50 plus today, doesn’t mean that 50 plus will be able to pass the testability criteria. And in fact the work of combing SC ideas is very likely to make testability much harder. For that reason, and to have the best most distinct and reliable standard, I’d rather have more clearly defined, scoped and distinctly testable SC – than some arbitrary limit on the number of SC.
>>  
>> Take 1.3.1 for example, in hindsight, wouldn’t it have been much easier to have that SC broken out into its logical units of tables, forms, lists, textual emphasis, etc. – that t have the difficult ‘kitchen sink’?
>>  
>>  
>> ​​​​​
>>  
>>  
>>  
>> * katie *
>>  
>> Katie Haritos-Shea 
>> Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)
>>  
>> Cell: 703-371-5545 <tel:703-371-5545> | ryladog@gmail.com <mailto:ryladog@gmail.com> | Oakton, VA | LinkedIn Profile <http://www.linkedin.com/in/katieharitosshea/> | Office: 703-371-5545 <tel:703-371-5545> | @ryladog <https://twitter.com/Ryladog>
>>  
>> From: John Foliot [mailto:john.foliot@deque.com <mailto:john.foliot@deque.com>] 
>> Sent: Tuesday, October 4, 2016 10:27 AM
>> To: Alastair Campbell <acampbell@nomensa.com <mailto:acampbell@nomensa.com>>
>> Cc: WCAG <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>; public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org <mailto:public-low-vision-a11y-tf@w3.org>>
>> Subject: Re: Combining SCs
>>  
>> > Adding the new one or two specific SC is the best way to go, I believe.
>>  
>> Perhaps, but there is also an additional dynamic at play, and that is that there are currently 50 newly proposed SC coming from various TFs within the Working Group, and on more than one occasion during TPAC I heard concerns over excess bloat of 2.x. Thus any opportunity we have for normalization or combination of requirements should be looked at quite closely. 
>> 
>> Alastair's scenario is a good one, and it is also why I was also focussing on a good numbering scheme early on. Given his scenario, could we not also do something like this?
>>  
>> <example>
>>  
>> SC 1.4.4 Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (AA)
>>  
>>> SC 1.4.4.1 Resize content: The content of the Web page can be increased to 400 percent without loss of content or functionality, without bi-directional scrolling, with following the exceptions: (content that has to be 2D, and mobile user-agents). (A)
>>>  
>>> -or-
>>>  
>>> 1.4.4.1 Text sizing: Except for images of text, text can be resized without assistive technology up to the user agent maximum without loss of content and functionality. (A)
>>>  
>> ​</example>​
>>  
>> 
>> > This isn’t worth spending a lot of time on now, we need to get all the new SCs in a pot first and boil them down to the essentials, then we can hash this out.
>>  
>> +1
>>  
>> JF 
>>  
>> On Tue, Oct 4, 2016 at 12:07 PM, Alastair Campbell <acampbell@nomensa.com <mailto:acampbell@nomensa.com>> wrote:
>>> Katie wrote:
>>> 
>>> > “Even though C restates with a higher requirement, it is still OK, I think, as long as each is testable. Because we can't remove or change 1.4.4 so an entity would fail in 2.1 for that SC if they passes it in 2.0.”
>>> 
>>>  
>>> 
>>> I think if we could show that anything passing this 2.1 SC would also pass the 2.0 SC, I’d like to be able to replace the original. Apparent duplication would make the document harder to understand.
>>> 
>>>  
>>> 
>>> However, we’re a little way off that decision point, we need to go through the process of agreeing the new ones first…
>>> 
>>>  
>>> 
>>> Cheers,
>>> 
>>>  
>>> 
>>> -Alastair
>>> 
>>>  
>>> 
>>>  
>>> 
>> 
>> 
>> 
>>  
>> -- 
>> John Foliot
>> Principal Accessibility Strategist
>> Deque Systems Inc.
>> john.foliot@deque.com <mailto:john.foliot@deque.com>
>>  
>> Advancing the mission of digital accessibility and inclusion
> 
> 
> 
>  
> -- 
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com <mailto:john.foliot@deque.com>
>  
> Advancing the mission of digital accessibility and inclusion