E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 5 (In chronological order)

From: Joshue O Connor - InterAccess
Date: Sat, May 19 2018 6:08AM
Subject: Good external keyboard only a11y for iOS/UIKit/Swift
No previous message | Next message →

Hello WebAIMers,

I'm doing keyboard only testing of native iOS apps - with no AT. It's
very interesting and also hard to find good
advice on best practice for how to service users of an iOS app who may
use an external keyboard.

UIKit/UIButton etc in Swift seems to be a little like ARIA in that it
offers a semantic hook
for VoiceOver and possibly other AT but doesn't make these elements
focusable using external keyboard.
I'm not sure if adding isAccessibilityElement will do it either as that
may just serve traditional AT (I've not built a test).

I thought it's an interesting question to ask/discuss.

So anyone have good resources/tips on supporting simple (external)
keyboard a11y that they would like to share?

Thanks in advance.
__
Joshue O Connor
Director / InterAccess.ie

From: Jonathan Avila
Date: Sun, May 20 2018 1:48PM
Subject: Re: Good external keyboard only a11y for iOS/UIKit/Swift
← Previous message | Next message →

Hi Josh,

In our experience with native iOS apps input fields are generally the only keyboard accessible control without performing custom keyboard support. VoiceOver can be enabled, speech turned off, and modifier keys changed with sticky key support. In this mode apps can become keyboard interface accessible when accessibility enabled. In short for iOS we generally test for keyboard access (aside from input) with VoiceOver active. Switch control relies off of the same accessibility information provided through the API for VoiceOver and thus the accessibility API can be seen as a form of keyboard interface. Apps can add custom keystrokes and many do such as Word for iOS -- but I'd imagine it would be challenging to build a focus manager and build full keyboard support from the ground up.

Android is a different story. Android keyboard interface support is more built into the platform without relying on an accessibility services. Functionality is available to control the focus order, etc. and TalkBack does not have the same ability to have sticky key support. While some TalkBack keystrokes can be modified the key combinations would be difficult for some keyboard users to access and thus pure keyboard support (in my opinion) via the platform should be used to evaluate keyboard interface support without relying on Talkback.

Jonathan

Jonathan Avila
Chief Accessibility Officer
Level Access
= EMAIL ADDRESS REMOVED =
703.637.8957 office

Visit us online:
Website | Twitter | Facebook | LinkedIn | Blog

Looking to boost your accessibility knowledge? Check out our free webinars!

The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.

From: Joshue O Connor - InterAccess
Date: Mon, May 21 2018 4:07AM
Subject: Re: Good external keyboard only a11y for iOS/UIKit/Swift
← Previous message | Next message →

Hi Jon,

Many thank for the comprehensive reply - it's very useful.
>
>In our experience with native iOS apps input fields are generally the
>only keyboard accessible control without performing custom keyboard
>support. VoiceOver can be enabled, speech turned off, and modifier
>keys changed with sticky key support.
Is this is a common or well known approach (do you find) to enabling
keyboard a11y for many users? From the user perspective it seems clunky
in that, when using a keyboard in a regular website or application - if
elements are links/inputs etc, or via simple tabindex magic then voila.
IMO, many people who could benefit from keyboard a11y for apps may not
likely have a clue what VO is.

> In this mode apps can become keyboard interface accessible when
>accessibility enabled.
Right.

>In short for iOS we generally test for keyboard access (aside from
>input) with VoiceOver active. Switch control relies off of the same
>accessibility information provided through the API for VoiceOver and
>thus the accessibility API can be seen as a form of keyboard interface.
Yes. I was aware that for Switches/scanning applications they consume
the same semantics via the API/UIAccessibility protocol etc. Interesting
that you refer to it as a 'keyboard interface'. Actually, this kind of
thinking is useful as it is common to think of A11y APIs being only for
SR users, or at least they are the most complex but the delta between
other ATs that can usefully consume those APIs is where more inclusive
design happens I guess.

>Apps can add custom keystrokes and many do such as Word for iOS -- but
>I'd imagine it would be challenging to build a focus manager and build
>full keyboard support from the ground up.
Exactly, good point. That is what I was thinking, and it should be
trivial. There are certainly common use cases for many users who would
benefit from keyboard access to the UI on mobile/tablet devices.
>
>Android is a different story.
Right, out of the box. I've found native Android apps to have better
keyboard a11y.

>Android keyboard interface support is more built into the platform
>without relying on an accessibility services. [...]thus pure keyboard
>support (in my opinion) via the platform should be used to evaluate
>keyboard interface support without relying on Talkback.
Agreed. It's good to see Android ahead of the curve with this modality
:-)

Appreciate the feedback Jon, thanks.

Josh
>
>
>Jonathan
>
>Jonathan Avila
>Chief Accessibility Officer
>Level Access
> = EMAIL ADDRESS REMOVED =
>703.637.8957 office
>
>Visit us online:
>Website | Twitter | Facebook | LinkedIn | Blog
>
>Looking to boost your accessibility knowledge? Check out our free
>webinars!
>
>The information contained in this transmission may be attorney
>privileged and/or confidential information intended for the use of the
>individual or entity named above. If the reader of this message is not
>the intended recipient, you are hereby notified that any use,
>dissemination, distribution or copying of this communication is
>strictly prohibited.
>
>

From: Patrick H. Lauke
Date: Mon, May 21 2018 4:49AM
Subject: Re: Good external keyboard only a11y for iOS/UIKit/Swift
← Previous message | Next message →

On 21/05/2018 11:07, Joshue O Connor - InterAccess wrote:
> Hi Jon,
>
> Many thank for the comprehensive reply - it's very useful.
>>
>> In our experience with native iOS apps input fields are generally the
>> only keyboard accessible control without performing custom keyboard
>> support.  VoiceOver can be enabled, speech turned off, and modifier
>> keys changed with sticky key support.
> Is this is a common or well known approach (do you find) to enabling
> keyboard a11y for many users? From the user perspective it seems clunky
> in that, when using a keyboard in a regular website or application - if
> elements are links/inputs etc, or via simple tabindex magic then voila.
> IMO, many people who could benefit from keyboard a11y for apps may not
> likely have a clue what VO is.

As keyboard support in iOS in general (on the home screen, all other
standard apps, etc) is poor/nonexistent without VO running,
keyboard-reliant users on iOS would need to know this, or they'd not be
using iOS and using Android instead.

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

From: Joshue O Connor - InterAccess
Date: Mon, May 21 2018 8:22AM
Subject: Re: Good external keyboard only a11y for iOS/UIKit/Swift
← Previous message | No next message

------ Original Message ------
From: "Patrick H. Lauke" < = EMAIL ADDRESS REMOVED = >
>>[...]well known approach (do you find) to enabling keyboard a11y for
>>many users? From the user perspective it seems clunky in that, when
>>using a keyboard in a regular website or application - if elements are
>>links/inputs etc, or via simple tabindex magic then voila. IMO, many
>>people who could benefit from keyboard a11y for apps may not likely
>>have a clue what VO is.
>
>As keyboard support in iOS in general (on the home screen, all other
>standard apps, etc) is poor/nonexistent without VO running,
>keyboard-reliant users on iOS would need to know this, or they'd not be
>using iOS and using Android instead.
Yeah, seems less than elegant.

Thanks

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