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

>> 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)
?

I think we ran into that issue when we were tr
​y​
ing to formulat
​e​
2.5.1
​. Say you and me decide to go into business. We create the "David and
Patrick magic hand gesture translator."​ It is assistive technology.
"Accessibility supported" language is intended to require pages to work
with assistive technology. This is not web content so WCAG no requirements
on it. HOWEVER, it is assistive technology, and therefore if 2.1.1 applies
to ALL non-pointer technologies, then it would have to include this too.
That is a very expansive rabbit hole I would say. Go to CSUN and 2.1.1
would require web pages to work with EVERY Assitive Technology.

​We addressed this in our 2.5.1 proposal ​

"​2.5.1 ​
Touch with Assistive Technology: All functions available by touch are still
available by touch after platform assistive technology that remaps touch
gestures is turned on. (Level A)
​"​

The qualifier is that it is limited to "
platform assistive technology that remaps touch gestures"
​.

Now as we try to genericize ​the mobile requirements, to try to apply to
all touch environments, we have a problem, because many on Windows
platforms, the main AT is not delivered with the platform, it is purchased
separated (ZoomText, JAWS, Read & Write Gold, etc...). So how do we
characterize mainstream technology without forcing developers to support
the "D&P magic hand gesture translator" and every other Ma & Pop AT out
there.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Thu, Jul 14, 2016 at 4:31 PM, Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> 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
>
>
>