Re: WCAG 2.2 acceptance criteria

Hi All,

To perhaps also put a finer distinction on it... W3C Process mandates two
independent implementations of whatever new technology is being proposed -
a testing activity we actually did last spring during CSUN for the 2.1
Success Criteria (where, for SC 1.3.6 @ AAA we actually used the
implementations that Lisa had pointed us to). Those implementations may or
may not also serve as a 'testing tool', but as the Silver discussion
continues, a repeatable testing methodology will need to surface for each
new requirement, whether that is via a tool (mechanical tests - see: ACT
TF), or via a 'cognitive walk-though' or similar methodology (a process
still to be fully defined in Silver).

At the end of the day, while it is true that our primary audience is and
will always be users with disabilities (of all stripes and forms), a second
important consideration is compliance requirements mandated by legislation.
To clear that hurdle, we will need to ensure that both implementers and
consumers have a baseline measurable & impartial (non-subjective) "test",
so that entities can then claim conformance based upon the outcome of said
test.

JF

On Thu, Mar 7, 2019 at 10:52 AM Alastair Campbell <acampbell@nomensa.com>
wrote:

> Hi Lisa,
>
>
>
> > To meet new user needs we may need new tools and reviews may need to
> acquire new skills and knowledge.
>
>
>
> Which is fine, perhaps we can clarify that it means available at the time
> of publication?
>
>
>
> New tools, especially if they “take a day” from a programmer would need to
> be available at the time of publication, for the reasons I outlined in the
> last email.
>
>
>
>
>
> > Also new tools will come as soon as we know a SC will be accepted. in
> other word at CR. With WCAGs current history it will not come before then.
>
>
>
> Can you point to a previous example? I.e. where a tool that didn’t exist
> was required to meet an SC wasn’t available until after CR?
>
> The closest I can think of is ARIA in WCAG 2.0, but it wasn’t actually
> required to meet the SCs.
>
>
>
> It is very difficult to deal something in CR which then has to be pulled
> because no one has created a tool, the whole timeline goes back a step. The
> way the W3C prefers to work is to have working prototypes/code created
> prior to specs. This has been a hard-learned approach [1].
>
>
>
> I suggest that if an SC needs a tool, we work up the SC template and go
> through the initial process. That could be accepted on the condition that a
> tool will be available. If it does not become available then the SC will be
> removed before CR.
>
>
>
> It would also help to put those SC(s) first so people have more time to
> work on the tools, I’ll make a note of that.
>
>
>
> Cheers,
>
>
>
> -Alastair
>
>
>
>
>
> 1] Accessibility example for what should be a ‘simple’ thing, the naming
> algorithm.
>
>
> https://www.linkedin.com/pulse/future-accname-spec-planning-strategy-functional-using-garaventa/
>


-- 
*​John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com