Re: Combining SCs

> about its usefulness to implementers

​...and the comments about "bloat" speak directly to that.

If the requirements become to bloated, there is a very real risk of either
some of the newer SC being kept at AAA, or that adopters will not take up a
2.x as it becomes "too hard" as compared to 2.0. I don't believe either of
those scenarios are what we want either, is it?

JF​


On Tue, Oct 4, 2016 at 5:26 PM, 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 <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 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> 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
>



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

Advancing the mission of digital accessibility and inclusion