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

I've tried to stay out of this thorny thread but when I understood that one
purpose of it is to replace the 2.5.1 mobile proposal, I realized I need to
ensure the concerns I had when trying to write 2.5.1 will be addressed in
this 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)

>From the very beginning of mobile a11y discussions, my most important
concern has been that when users turn on VO or Talkback on a mobile, the
conforming page will work. I'm concerned that the new language does not
require it to work with the AT layer running. But it is built on a hope
that if high level events are chosen, it WILL work with AT running.

So I guess it's time we, as a task force, understand in a general way how
these layers of APIs and OS etc fit together in the mobile environment.

Let me start it off based on our discussions with Chris today and my own
understanding from desktop a11y APIs and environments. I am fine with being
corrected if I've got some part of this wrong. We need to understand it to
make good decisions.

We have basically have 3 layers of software on mobile devices.

- kernel on the bottom
- OS level in the middle
- AT (and other software) running on top of that

Chris tells us that Keyboard interface events are registered at the kernel
level and sent to the OS level as keyboard events. He says AT events are
registered at the AT level on the top of the stack and are either sent to
the kernel level as fake keyboard events or (as Patrick explains in this
thread) may just communicated straight to the OS level (i.e., "move focus
to next") bypassing the KB interface.

Historically, most every AT used fake keyboard events but that is no longer
true, and now its a mix of fake keyboard events and direct communication of
events to the OS so we need to extend our requirements so that these
non-fake keyboard events are covered in ADDITION to keyboard. Maybe in the
future a Indie UI type of standard will fix the mess, but that is nowhere
in the near term, since the group was disbanded.

So we have keyboard interface events coming from the bottom of the stack
and AT events coming from the top of the stack, and we want a SC that
covers it all.

Patrick says that the sufficient technique will be to use high level events
(Onclick, onblur, etc) and therefore we won't need two techniques to meet
the SC. So we won't end up with this mess.

-Sufficient technique A (for keyboard) AND Technique B (for AT)

Anyway, the only way I could live with it is if Keyboard is explicitly
required
​ AND ensure that our proposal for 2.5.1 requiring functions to work when
platform AT is on​
:

Something like:

"All functionality of the content is operable through non-pointer input
interfaces (which includes the keyboard interface), without requiring
specific timings.. (Level A)"

NOTE: All functionality is still required to work with a keyboard as per
WCAG 2
NOTE: All functions available by touch are still available by touch after
platform assistive technology that remaps touch gestures is turned on.

Also, I think we would want to create a term in place "non-pointer event"
It's really clunky as Alastair said.

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 8:34 PM, Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> On 14/07/2016 23:43, David MacDonald wrote:
>
> ​. 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.
>>
>
> The AT would hook into the OS/platform's standardised APIs (or hook into
> the UAs like browsers through additional plugins, like Dragon does for
> instance).  There is (at least to my mind) a tacit understanding that UAs
> (including AT) need to work in a standardised and consistent way. Otherwise
> ANYTHING in WCAG could be up for discussion (e.g. we assume that UAs
> understand HTML). That would at least by my expectation, though I see WCAG
> dodges that bullet and/or gets itself muddled:
>
> "This topic raises the question of how many or which assistive
> technologies must support a Web technology in order for that Web technology
> to be considered "accessibility supported". The WCAG Working group and the
> W3C do not specify which or how many assistive technologies must support a
> Web technology in order for it to be classified as accessibility supported.
> This is a complex topic and one that varies both by environment and by
> language."
> [...]
> "The Working Group, therefore, limited itself to defining what constituted
> support and defers the judgment of how much, how many, or which AT must
> support a technology to the community and to entities closer to each
> situation that set requirements for an organization, purchase, community,
> etc."
>
> So if "accessibility supported" is not a phrase that can be applied to the
> assistive technology itself, fine to drop it.
>
> ​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"
>> ​.
>>
>
> Note that not so long ago (few years?), TalkBack didn't come as standard
> on Android and had to be downloaded/installed as a separate app. So even on
> mobile, it's not guaranteed to always be as cut and dry
>
> 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...).
>>
>
> Narrator comes with Windows 8.1 / 10 by default. It's quite limited, but
> it is there...and on touchscreen laptop/tablet/2-in-1 devices, it allows
> for gesture-based navigation too.
>
> 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.
>>
>
> WCAG's glossary https://www.w3.org/TR/WCAG20/#atdef already says that
> we're talking about *mainstream* user agents. It should likely also talk
> about *mainstream* assistive techologies (because in its current wording,
> it allows for Ma & Pop AT that runs in conjunction with a mainstream user
> agent, meaning that currently ALL SCs need to also cover the Ma & Pop
> scenario whether they like it or not?
>
> I think that's a discussion that warrants a much wider participation than
> just the mobile TF. It feels like WCAG itself lacks a definition of
> assistive technology
>
> Certainly the concept of *mainstream* AT that relies on standard
> platform/UA interfaces/APIs should be mentioned somewhere in the glossary.
>
>
> 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
>
>
>