WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Roel Van Gils
Date: Sep 4, 2017 8:17AM

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