RE: Combining SCs

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 |  <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: 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 <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.

 <mailto:john.foliot@deque.com> john.foliot@deque.com

 

Advancing the mission of digital accessibility and inclusion