W3C home > Mailing lists > Public > public-silver@w3.org > March 2019

Re: WCAG 2.2 acceptance criteria

From: Katie Haritos-Shea <ryladog@gmail.com>
Date: Thu, 7 Mar 2019 20:16:36 -0500
Message-ID: <CAEy-OxFpo_6BCZ7cWZCnOu0rT2JPLsp1WdCm1PcrrhpK0tQfig@mail.gmail.com>
To: AlastairCampbell <acampbell@nomensa.com>
Cc: "Delisi, Jennie (MNIT)" <jennie.delisi@state.mn.us>, John Foliot <john.foliot@deque.com>, "lisa.seeman@zoho.com" <lisa.seeman@zoho.com>, COGA TF <public-cognitive-a11y-tf@w3.org>, Silver TF <public-silver@w3.org>
I am concerned about any amount of time being mentioned. It should be
testable, period.

This is a slippery slope that seems to favor one kind of SC over another.
The questions are, in my mind, is it valuable (?), and is it testable (?).

On Thu, Mar 7, 2019, 7:54 PM Alastair Campbell <acampbell@nomensa.com>
wrote:

> Hi everyone,
>
>
>
> To clarify a couple of points:
>
> > Part of the concerns the COGA group discussed was that manual tests are
> often required
>
>
>
> Indeed, any testing we do to show something is accessible is manual. The
> “tools” in that case are for efficiency rather than automation.
>
>
>
>
>
> > 1-2 images on a page, not a big deal to test. But, on a catalogue page,
> it could be significant.
>
>
>
> That’s not been my experience, we do a lot of e-commerce work and (taking
> a non-client example) Amazon.co.uk has 192 images on the homepage. It
> doesn’t take long to test because you can click a button and list those
> image (thus knowing it’s 192), either separately or in context with the alt
> text showing.
>
>
>
> The same type of test would be easy to create for showing symbols based on
> metadata. This is *not* about user groups, it is about method.
>
>
>
> Taking a hypothetical example: What if a method involved comparing every
> word on a page to a particular list of words? It is something that could be
> automated, but if there were no tool to do that by publication date and
> this one check took longer to test than every other check put together,
> that would prevent uptake.
>
>
>
> The original bullet was:
>
> > Be feasibly testable through automated or manual processes, i.e. take a
> few minutes per page with current tools.
>
>
>
> The update from 2.1 was adding ‘feasible’ and the “i.e…”.
>
>
>
> So there are two aspects:
>
>    1. It is feasible to test, however we define that.
>    2. Any tools required to (feasibly) test it are available by
>    publication.
>
>
>
> These are thing which caused ‘discussion’ during 2.1, so I wanted to make
> the requirement explicit before we started 2.2.
>
>
>
> Glenda wrote:
>
> > Be feasibly testable in a "reasonable amount of time" through automated
> or manual processes prior to Candidate Recommendation stage.
>
>
>
> I’d go with either ‘feasible’, or ‘a reasonable about of time’ rather than
> both, and the CR stage bit doesn’t make sense without referring to the
> testing-tool (which wasn’t clear enough before either).
>
>
>
> John has a point about the method of testing being the most important
> thing, but I think that is covered by requiring each SC to have a testable
> technique at an early stage.
>
>
>
> I’d suggest this update:
>
> “Can be tested in a reasonable amount of time through automated or manual
> processes, and any tools needed to test it are available before the
> Candidate Recommendation stage.”
>
>
>
> By using “Can be tested in a reasonable amount of time…” I’m trying to say
> that it doesn’t mean everyone has to be able to test it quickly, and the
> type of content (or amount of content) will vary the time, but it is at
> least *possible* to test in a reasonable amount time.
>
>
>
> Cheers,
>
>
>
> -Alastair
>
>
>
>
>
Received on Friday, 8 March 2019 01:17:15 UTC

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2019 01:17:16 UTC