W3C home > Mailing lists > Public > public-low-vision-a11y-tf@w3.org > October 2016

Re: Combining SCs

From: Katie Haritos-Shea <ryladog@gmail.com>
Date: Mon, 3 Oct 2016 16:51:30 -0400
Message-ID: <CAEy-OxEC7QaRyhR3iSfkNHBT8Js_xFFPt4X5kbcD_YyE8tCj8A@mail.gmail.com>
To: AlastairCampbell <acampbell@nomensa.com>
Cc: WCAG <w3c-wai-gl@w3.org>, public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>
I understand Alistair, and thanks for seperating the thread....:-)

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.

So you are right, this is going to require careful thought. Adding the new
one or two specific SC is the best way to go, I beleive.

Katie Haritos-Shea
703-371-5545

On Oct 3, 2016 12:25 PM, "Alastair Campbell" <acampbell@nomensa.com> wrote:

> 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 20:52:10 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 27 April 2017 14:44:31 UTC