WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Good external keyboard only a11y for iOS/UIKit/Swift

for

From: Joshue O Connor - InterAccess
Date: May 21, 2018 4:07AM

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