WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: VoiceOver in Safari on iOS: how to handle focus when using software keyboard

for

From: Detlev Fischer
Date: Sep 4, 2017 9:09AM

Hi Roel,
I tried to reproduce this on an iPad pro 10.5 with IOS 10.3.3 (keyboard folded back so it brings up the virtual kb). VO on, I swiped to move focus to the first field. Once I double tapped once the first field had focus, virtual kb came up write and then activate the next button - the little chevron type control at the top right of the virtual keyboard - the focus advances to the next field. When I used the hide keyboard control, the focus was lost and I have to swipe to filed from the top of the screen. Not sure what you mean with tapping 'ready' - I can't see a keyboard control (or anything on your codepen page) named so.
Best,
Detlev

--
Detlev Fischer
testkreis c/o feld.wald.wiese
Thedestr. 2, 22767 Hamburg

Mobil +49 (0)157 57 57 57 45
Fax +49 (0)40 439 10 68-5

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites

Roel Van Gils schrieb am 04.09.2017 16:17:

> Hi all,
>
> Lately, I've started noticing that most web forms suffer from the following
> behaviour when filling them out using VoiceOver on iOS.
>
> Have a look at this very simple form I set up:
>
> - Go to https://codepen.io/roelvangils/full/ZJPqVL/ (or any other web form)
> using Safari on an iOS device running iOS 9 or later
> - Turn VoiceOver on
> - Navigate to the first text field (labeled 'First field' in the Codepen
> example)
> - Double tap to bring up the iOS keyboard.
> - (Note that, as soon as you start interacting with the on-screen keyboard, the
> VO cursor (naturally) will lose its focus, so it's no longer on the text
> field.)
> - Type some text and tap 'Ready' to dismiss the keyboard.
>
> Now, watch closely what happens next: the on-screen keyboard disappears and
> VoiceOver will try and figure out what to focus now. It seems to have forgotten
> which element on the page had focus before the on-screen keyboard was brought
> up, so it will move the VO focus to the on-screen element that is *closest* to
> the screen coordinates of the last element that had focus (the 'Done' button in
> the keyboard strip, in this example).
>
> So, dependent on the layout of the form, this will always be some arbitrary
> element on the page. For example, in my example (tested on an iPhone 6 in
> landscape mode) it will jump to 'Third field' after filling in 'First field'.
>
> I can easily reproduce this problem on iOS 9, iOS 10 and iOS 11 Beta. It's
> probably just normal behaviour, but I don't think it's logical at all since
> most VO users are not interested in the visual presentation of a web form.
>
> In some basic user tests I performed, this behaviour indeed proved to confuse
> an (moderately experienced) user. They assumed the focus would simply return to
> the last element that had focus, so they could continue their way from that
> point on. That's what I was expecting too.
>
> My question are:
>
> 1. Is this really the expected behaviour and does anyone know what the
> reasoning behind this is?
> 2. Is anyone aware of a (probably JavaScript based) workaround to circumvent
> this behaviour? Or would you advise against trying to 'fix' this issue?
>
> I'm looking forward to your views on this matter.
>
> Thanks,
> Roel
>
>
> --
> Roel Van Gils
> Inclusive Design & Accessibility Consultant
>
> Tel.: +32 473 88 18 06
> Skype: roelvangils
> Twitter: twitter.com/roelvangils
> LinkedIn: linkedin.com/in/roelvangils
>
>
> > > > >