W3C home > Mailing lists > Public > public-cognitive-a11y-tf@w3.org > March 2019

Re: WCAG 2.2 acceptance criteria

From: Steve Lee <stevelee@w3.org>
Date: Fri, 8 Mar 2019 09:34:32 +0000
To: public-cognitive-a11y-tf@w3.org
Message-ID: <5ed0440b-b237-0235-15c6-62db22087317@w3.org>
+1

On 08/03/2019 01:16, Katie Haritos-Shea wrote:
> 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 
> <mailto: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 <http://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 09:34:35 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:02 UTC