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: Roel Van Gils
Date: Sep 4, 2017 11:02AM

Hi Detlev,

Thank you very much for trying to reproduce these steps!

I hadn't tested this on an iPad myself, so I just tried it on my brand new new iPad Pro 10.5 inch (😍) as well, and I noticed that the soft keyboard on the iPad doesn't have a 'Done' button in the upper right area of the horizontal bar positioned right above the keyboard.

However, the iPad keyboard has a button with a keyboard icon and a down pointing arrow (labeled 'Hide keyboard' by VoiceOver) that's positioned in the the bottom right corner of the screen. If you hit this button on the iPad when VO is on, something even stranger happens.

It actually depends on where exactly on the 'hit area' of the 'Hide keyboard' button you double tap, which element on the screen receives focus as soon as the keyboard is dismissed.

In my case, the 'New tab' (+) button ((if you double tap in the left part of the 'Hide keyboard' button) *or* the 'Tabs' button in the Safari toolbar (if you double that in the right part) where focused.

This actually proves my theory that VoiceOver bases its decision on what item to focus, depending on how closely its coordinates correspond to the location of the last tap on the keyboard. (And, apparently, the algorithm 'wraps' around the edges of the screen to determine that).

This doesn't only happen when the on-screen keyboard is being dismissed. It also happens on websites and single page web apps that hide parts of the page. For example, when you dismiss a page overlay (by double tapping an × button, for example) VO loses its 'grip' and then focuses some other (for a blind user totally arbitrary) interactive page element.

So, long story short: has anyone else experienced this, or has anyone advice on dealing with this (probably deliberate) VO behaviour?

Thanks!
Roel



> On 4 Sep 2017, at 17:09, Detlev Fischer < <EMAIL REMOVED> > wrote:
>
> 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
>>
>>
>> >> >> >> >>
>
> > > >