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> 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 <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 <https://github.com/patrickhlauke>
>>> http://flickr.com/photos/redux/ <http://flickr.com/photos/redux/> | http://redux.deviantart.com <http://redux.deviantart.com/>
>>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>> 
>>> 
>>> 
>> 
>> 
>