Re: Combining SCs

Hi Katie,

NB: I’m separating the ‘combining’ thread from the ‘sizing’ thread, this is the combining one.

To be clear – I don’t want to overly combine SCs, but there are two or three new potential SCs from the LVTF on sizing, plus the existing WCAG one. If we can’t replace or adjust a current WCAG one, we could end up with a re-stating of the old one with a higher-requirement. 

Also, I appreciate that the chairs said previously that we should focus on coming up with the new SCs, and we’ll see how they fit when we have the whole picture, so this conversation is a bit premature. But since you asked… ;-) 

I might be too optimistic, but this:
> “2.1 has to be 100% backwards compatible (in that it will add new things, but all of the old things will still be true).”

Might not be the same as this:
> “you would still have to have the Resize SC (with it existing number) and a Resize Text plus Resize Content (with a new number).”

We could we draft a replacement Resize SC at the same number that is 100% backwards compatible, but does the number & wording have to remain as-is with only additional SCs?

It is a bit early to argue either way, but there is a useful scenario on sizing that we can consider when we get there.

Imagine we had these SCs on sizing:

A) 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)

B) 1.4.x 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)

C) 1.4.x 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)

In this case I think C needs some adjustment, but for sake of argument we’ll use it here.

C is essentially a re-stating of A at a higher level, assuming that was approved as a useful new SC it makes the original 1.4.4 redundant, why leave it there?

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.

I just thought it was a useful example to consider…

Kind regards,

-Alastair

Received on Monday, 3 October 2016 16:25:50 UTC