RE: Device manipulation

Ø  Yes - when you have a keyboard access to gestures that access pointing motions that access on screen keyboards to access a web page — it gets complicated.

The challenge is that you can’t get the on-screen keyboard to come up unless in certain fields AND the standard on-screen keyboard in iOS does not have arrow keys on it like up/down, AND even if you had a custom on-screen keyboard those keys are not sent from Safari to the web page.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
703.637.8957 (Office)
Visit us online: Website<http://www.ssbbartgroup.com/> | Twitter<https://twitter.com/SSBBARTGroup> | Facebook<https://www.facebook.com/ssbbartgroup> | Linkedin<https://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog/>
Check out our Digital Accessibility Webinars!<http://www.ssbbartgroup.com/webinars/>

From: Gregg Vanderheiden RTF [mailto:gregg@raisingthefloor.org]
Sent: Tuesday, May 31, 2016 4:02 PM
To: Jonathan Avila
Cc: public-mobile-a11y-tf@w3.org
Subject: Re: Device manipulation



gregg

On May 31, 2016, at 2:38 PM, Jonathan Avila <jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>> wrote:

>  You need to look at
>  whether all aspects can be accessed from Voiceover
>  whether each voiceover gesture has a keyboard equivalent — (which they do)
>  whether you can turn off the speech on voiceover (which you can)
An item to consider is that there are sticky keys, key repeat, etc supported on the platform.  There is now – but before there were keystrokes that required multiple keys to be pressed at once and this would surely be an issue for many keyboard only users.  Luckily this has been addressed and quick navigation mode assists as well.

>  so as long as the app works fully with voiceover for navigation (via gesture) it will also be fully keyboard navigable
The challenge in my experience is that many ARIA paradigms do not work with gestures in the browser because the paradigms rely on key events for the arrow keys which are not sent from Safari to web content either with or without VoiceOver running.  So you run into a situation where the web page is keyboard accessible on the desktop but NOT touch or (keyboard accessible via VoiceOver) on iOS.  Gregg, could you please give your thoughts on this?


Yes - when you have a keyboard access to gestures that access pointing motions that access on screen keyboards to access a web page — it gets complicated.


Technically the web page supports keyboard access but there is no way to send those keys from VoiceOver gestures or an external keyboard to the page.

Yes - and the on-screen keyboard often does not include the modifier keys you need….



A list of VoiceOver keystrokes for VoiceOver gestures can be found here (http://axslab.com/articles/ios-voiceover-gestures-and-keyboard-commands.php).  I’m not sure it covers everything but they appear to cover the magic tap, scrub, action rotors, move to top/bottom etc.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
703.637.8957 (Office)
Visit us online: Website<http://www.ssbbartgroup.com/> | Twitter<https://twitter.com/SSBBARTGroup> | Facebook<https://www.facebook.com/ssbbartgroup> | Linkedin<https://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog/>
Check out our Digital Accessibility Webinars!<http://www.ssbbartgroup.com/webinars/>

From: Gregg Vanderheiden RTF [mailto:gregg@raisingthefloor.org]
Sent: Tuesday, May 31, 2016 2:12 PM
To: Paul Adam
Cc: David MacDonald; public-mobile-a11y-tf@w3.org<mailto:public-mobile-a11y-tf@w3.org>
Subject: Re: Device manipulation

when’d considering keyboard access for IOS — don’t look to the normal ‘hot key’ capabilities of IOS.  That will only get you partial access.

You need to look at

  *   whether all aspects can be accessed from Voiceover
  *   whether each voiceover gesture has a keyboard equivalent — (which they do)
  *   whether you can turn off the speech on voiceover (which you can)

so as long as the app works fully with voiceover for navigation (via gesture) it will also be fully keyboard navigable


gregg

On May 31, 2016, at 10:44 AM, Paul J. Adam <paul.adam@deque.com<mailto:paul.adam@deque.com>> wrote:

I’m not exactly sure what the question is here but I’ll give my input on keyboard accessibility on iOS and Android.

iOS is not keyboard operable like a desktop computer where you can tab around to links, buttons, and form controls. On iOS with a keyboard alone you can only tab through form input controls but not buttons and links.

So when you operate VoiceOver on iOS from a keyboard you’re just testing screen reader operability using the keyboard as an input. You could test that with touch also and get the same results.

iOS recently added an API called UIKeyCommand which will let developers attach keyboard-only shortcut keys to run specific functions in their app but this still does not let a keyboard-only user "tab" around the buttons and press enter to activate a button in a native iOS app.

Android is totally different in that it’s more like a desktop computer where you don’t need the screen reader turned on to have full keyboard access in web pages and native apps. So on Android you would always do keyboard-alone testing without TalkBack enabled because they are 2 very different methods of testing.

In native android apps developers need to specifically make sure their UI controls are keyboard-only accessible and have a visible focus indicator.

In iOS apps you’re only really worrying about screen reader Accessibility in the native Accessibility API. In Android Apps have to ensure both keyboard and screen reader accessibility.

Hope that helps!

My thoughts on WCAG is that the keyboard requirement applies to native apps and requires all their functions and UI controls to be keyboard operable within the limitations of that platform.

Thanks!

Paul J. Adam
Accessibility Evangelist
www.deque.com<http://www.deque.com/>

On May 30, 2016, at 11:05 PM, David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>> wrote:

My understanding is that there are currently gaps.... Paul do you want to chime in?

Cheers,
David MacDonald

CanAdapt Solutions Inc.
Tel:  613.235.4902
LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>
twitter.com/davidmacd<http://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 Mon, May 30, 2016 at 8:58 PM, Gregg Vanderheiden <gregg@raisingthefloor.org<mailto:gregg@raisingthefloor.org>> wrote:
I think that Keyboard Navigation is fully available for navigation in IOS.

IOS supports external keyboards and a  SILENT VOICEOVER  function — allows full access to the IOS programs.
There are keyboard equivalents for all the Voiceover gestures - and you can operate it without voice

Can someone confirm?

gregg

On May 23, 2016, at 12:20 PM, David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>> wrote:

It is clear under WCAG 2.1.1 that every function has to be keyboard enabled. I think however we may want to consider going further for the mobile requirement.

Keyboard functionality is not fully implemented on iOS and users generally reserve keyboard to input of volumes of text rather than navigation.
I've removed the "or keyboard" part out, since its covered in 2.1.1 and left it as follows.

​====​

2.6 [Proposed New MOBILE Success Criteria] Device manipulation: When device manipulation gestures are provided, touch operable alternative control options are available. (Level AA)
​Note: see also 2.1.1 for keyboard requirements.​

​=====​

For mobile, having a touch alternative is preferable to a keyboard alternative, but this proposed SC along with the existing 2.1.1 will require both... this may seem like a lot but I think it is worth bringing to the the larger group. This SC is to help dexterity disabilities, not blindness. Most plind people are used to shaking and tilting their devices (i.e., blind square)

We should maybe do some further study asking organizations working with people with dexterity problems who have mounted mobile devices whether the keyboard requirement of 2.1.1 would be sufficient or whether having a touch alternative to manipulatipn should be required.

Cheers,
David MacDonald

CanAdapt Solutions Inc.
Tel:  613.235.4902<tel:613.235.4902>
LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>
twitter.com/davidmacd<http://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, May 19, 2016 at 9:35 PM, Patrick H. Lauke <redux@splintered.co.uk<mailto:redux@splintered.co.uk>> wrote:
On 19/05/2016 23:09, Gregg Vanderheiden wrote:
Well - the keyboard interface provision ensures that there is always at
least that method (built in or connected keyboard operation)  for
operating things - that will work for people who don’t have fine (or
even any real ) pointing ability.

Then isn't the same provision also covering all other manners of device manipulation? Shaking, tilting, etc? i.e. is the entire SC superfluous because of the keyboard interface provision? (which, as a side note, I assume also includes the more general concepts like moving focus/activating a la VoiceOver/TalkBack ? I vaguely remember this being discussed at some point, but beyond discussion points at https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Keyboard_Access/Modality_Independent_Control/IndieUI can't find a definitive resolution)
But for those who can point but not well,  and for people with cognitive
disabilities that might be confused with overloaded pointing options -
 it could be very helpful to have these find pointing movement options
be real options and not the only way.

So now I'm wondering if it's really an SC, or more of a nice-to-have best practice technique (which doesn't necessarily have hard pass/fails), more suitable for publication as a note or similar...but that probably derails the whole argument further.

P

--
Patrick H. Lauke

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