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>
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 <703-371-5545> **|* *ryladog@gmail.com*
> <ryladog@gmail.com> *|* *Oakton, VA **|* *LinkedIn Profile*
> <http://www.linkedin.com/in/katieharitosshea/> *|* *Office: 703-371-5545
> <703-371-5545> **|* *@ryladog* <https://twitter.com/Ryladog>
>
>
>
> *From:* John Foliot [mailto:john.foliot@deque.com]
> *Sent:* Tuesday, October 4, 2016 10:27 AM
> *To:* Alastair Campbell <acampbell@nomensa.com>
> *Cc:* WCAG <w3c-wai-gl@w3.org>; public-low-vision-a11y-tf <
> 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>
> 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
>
>
>
> Advancing the mission of digital accessibility and inclusion
>



-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion