WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Helene VINH
Date: Sep 5, 2017 2:30AM

Hello,

I am working on airline websites and we also noticed this annoying issue while doing user tests with VoiceOver users.
I open a ticket but it hasn't been touched yet: https://bugs.webkit.org/show_bug.cgi?id4899
Hopefully they will do something about it.

Best regards

Helene Vinh
Developer, AeRE Product User Interface
R&D-AIR-DGM-AEK-FED-ERP
Amadeus s.a.s.
T: +33 (0)4 97 15 88 43
<EMAIL REMOVED>
www.amadeus.com


-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Jonathan Cohn
Sent: 04 September 2017 19:37
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: [EXT] Re: [WebAIM] VoiceOver in Safari on iOS: how to handle focus when using software keyboard

The done button is found on my iPhone 6 running latest production build by going to the suggestions above the qw and then swiping left. This does sound like a Client bug. I usually do not use the done button, but I would expect it should put focus in either the last field in the set or else keep it in the field where keyboard input is occurring.
There is a accessibility developers mailing list hosted by Apple that might be useful to communicate with.
https://lists.apple.com/mailman/listinfo/accessibility-dev


Best wishes,

Jonathan Cohn



> On Sep 4, 2017, at 10:17 AM, Roel Van Gils < <EMAIL REMOVED> > wrote:
>
> 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
>
>
> > > archives at http://webaim.org/discussion/archives
>