Re: Proposal: expanding/modifying Guideline 2.1 and its SCs (2.1.1, 2.1.2, 2.1.3) to cover Touch+AT

On 14/07/2016 21:21, David MacDonald wrote:
> Here's Patrick's proposal
> ​"​
> All functionality of the content is operable through accessibility
> supported non-pointer input interfaces (such as keyboards), without
> requiring specific timings for individual interactions,
> ​except ​
> ​...
> . (Level A)
> ​"​
> ​
> I've taken the liberty of running this by a lawyer​ with low vision to
> whom I taught assistive technology when he drafted legislation for the
> Canadian Government.  His paraphrased comments are as follows:
>
> - The SC does not *require* the use of keyboards with this language. The
> bracketed phrase (such as keyboards) shows that it is important to us,
> but it is an example, not a requirement

Changing this from "such as" to "including, but not limited to,"?

> - It does not say "... *all* accessibility supported non-pointer input
> interfaces", so any subset of "all" would sufficiently meet this SC, and
> this subset could exclude keyboard
> - It does not require it to work with pointer events, because it doesn't
> say "all accessibility supported AT". So some subset of "all" may not
> include pointer events, so it does not accomplish that either.

I struggle to understand this point...why are we talking about pointer 
events here?

> - It doesn't need to work with the screen reader turned on because it
> doesn't say "all ..."
> - Making the phrase "...ALL accessibility supported AT..." would throw a
> very wide net, requiring it to work with any new AT regardless of its
> market uptake, so that is not a solution either.

If we added ALL, the "accessibility supported" part would take care of 
new AT that behaves in a sane, accessibility supported way? Also, I 
think it would be a GOOD thing that this is future proof and includes 
new AT (as long as it's accessibility supported per 
https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head) 
?

> - If you want to require keyboard, you have to say so specifically or
> include it as an integral part of a definition of "non-pointer event"
> (not just as part of a non-binding list)
>
> In our 2.5.1
> ​mobile proposal which this attempts to replace, ​
> we qualified the
> ​scope of the ​
> AT by saying "platform assistive technology that remaps touch gestures"

As pointed out earlier in the week, Dragon NaturallySpeaking also 
behaves in a way similar to what touch+AT does, and that is currently 
also not really covered by the current keyboard-specific Guideline/SC. 
If we qualified this as being just about touch gestures, then we'd patch 
WCAG for touch, but leave this sort of input out again (requiring 
further triplication of SCs?).

> ​. Maybe that would work in here. I don't know. But unless we can solve
> these issues, I think we need to stick with our mobile 2.5.1 ​separate
> from 2.1.1.

P
-- 
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Thursday, 14 July 2016 20:31:49 UTC