WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

Number of posts in this thread: 11 (In chronological order)

From: Roel Van Gils
Date: Mon, Sep 04 2017 8:17AM
Subject: VoiceOver in Safari on iOS: how to handle focus when using software keyboard
No previous message | Next message →

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

From: Detlev Fischer
Date: Mon, Sep 04 2017 9:09AM
Subject: Re: VoiceOver in Safari on iOS: how to handle focus when using software keyboard
← Previous message | Next message →

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

From: John Hicks
Date: Mon, Sep 04 2017 9:14AM
Subject: Re: VoiceOver in Safari on iOS: how to handle focus when using software keyboard
← Previous message | Next message →

Hello

Thank you for this ! We have had major problems with an application where
"closest element to last screen tap" seems to be the default. In some
cases even on page reload (I know that focus should be controllable then
but we are using and old framework for the iPad app and it is a problem).

I am keen to read more on this

John



<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Garanti
sans virus. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2017-09-04 16:17 GMT+02:00 Roel Van Gils < = EMAIL ADDRESS REMOVED = >:

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

From: Roel Van Gils
Date: Mon, Sep 04 2017 11:02AM
Subject: Re: VoiceOver in Safari on iOS: how to handle focus when using software keyboard
← Previous message | Next message →

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

From: Jonathan Cohn
Date: Mon, Sep 04 2017 11:37AM
Subject: Re: VoiceOver in Safari on iOS: how to handle focus when using software keyboard
← Previous message | Next message →

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

From: Patrick H. Lauke
Date: Mon, Sep 04 2017 11:47AM
Subject: Re: VoiceOver in Safari on iOS: how to handle focus when using software keyboard
← Previous message | Next message →

On 04/09/2017 18:37, Jonathan Cohn wrote:
> 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

Pretty sure this is a long-standing gripe about iOS/VO and on-screen
keyboard interaction. It's well known but, for whatever reason, Apple
seems content to ignore it for years.

With regards to the "set focus to whatever focusable element is nearest
to the last known good focus location", yes that's a heuristic applied
by VoiceOver (also in situations like web content custom modal dialogs
being closed without focus being appropriately managed, which always
makes for fun results when trying to report accessibility issues and
getting mixed results depending on what the underlying page contains :) )

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Roel Van Gils
Date: Mon, Sep 04 2017 1:24PM
Subject: Re: VoiceOver in Safari on iOS: how to handle focus when using software keyboard
← Previous message | Next message →

Thanks, Patrick and Jonathan! Great input.

To summarise.

When focus management is done right - for example, by giving back `focus()` to the link or button that initiated a custom dialog, after a user performed an action that caused that dialog to be closed (i.e. being removed from the DOM or have its `display` property set to `none`) - all is fine :)

However, when the VoiceOver cursor is 'in limbo', its "set focus to whatever focusable element is nearest to the last known good focus location" heuristic is being triggered. I get that, and that's fine!

But, the same thing happens when using the on-screen keyboard and that is indeed a bug, I think. Because, when using the on-screen keyboard (provided by the OS), I think it's VoiceOver's responsibility (not the developer's) to remember the last known focused element (in practice, that will aways be an text field or text area) and restore that focus when the OS keyboard slides back down.

I'm wondering why Apple seems to ignore this, because to me this seems to be a very common UI interaction that must surely confuse many non-sighted users.

That being said, would there be any way to 'fix' this behaviour using JavaScript? I know it's rather easy to remember which element is being focused on a page and re-focus it after a dialog (that's part of the HTML) is being dismissed, but can this technique somehow be applied to closing the native OS keyboard as well? I've done some Googling, but I couldn't find anything on JavaScript events being sent to the page by the keyboard. It might be possible to detect when the keyboard appears and disappears by checking the height of the viewport or something, I guess, but that seems very hackish.

Is anyone aware of a reliable technique that could help me achieve this?

Thanks.

Roel

> On 4 Sep 2017, at 19:47, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>
> On 04/09/2017 18:37, Jonathan Cohn wrote:
>> 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
>
> Pretty sure this is a long-standing gripe about iOS/VO and on-screen keyboard interaction. It's well known but, for whatever reason, Apple seems content to ignore it for years.
>
> With regards to the "set focus to whatever focusable element is nearest to the last known good focus location", yes that's a heuristic applied by VoiceOver (also in situations like web content custom modal dialogs being closed without focus being appropriately managed, which always makes for fun results when trying to report accessibility issues and getting mixed results depending on what the underlying page contains :) )
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > >

From: Jonathan Cohn
Date: Mon, Sep 04 2017 2:13PM
Subject: Re: VoiceOver in Safari on iOS: how to handle focus when using software keyboard
← Previous message | Next message →

Hello,I took the initiative, and forwarded this note to the accessibility dev list at Apple. I'll reply back with any positive feedback.

Best wishes,

Jonathan Cohn



> On Sep 4, 2017, at 3:24 PM, Roel Van Gils < = EMAIL ADDRESS REMOVED = > wrote:
>
> Thanks, Patrick and Jonathan! Great input.
>
> To summarise.
>
> When focus management is done right - for example, by giving back `focus()` to the link or button that initiated a custom dialog, after a user performed an action that caused that dialog to be closed (i.e. being removed from the DOM or have its `display` property set to `none`) - all is fine :)
>
> However, when the VoiceOver cursor is 'in limbo', its "set focus to whatever focusable element is nearest to the last known good focus location" heuristic is being triggered. I get that, and that's fine!
>
> But, the same thing happens when using the on-screen keyboard and that is indeed a bug, I think. Because, when using the on-screen keyboard (provided by the OS), I think it's VoiceOver's responsibility (not the developer's) to remember the last known focused element (in practice, that will aways be an text field or text area) and restore that focus when the OS keyboard slides back down.
>
> I'm wondering why Apple seems to ignore this, because to me this seems to be a very common UI interaction that must surely confuse many non-sighted users.
>
> That being said, would there be any way to 'fix' this behaviour using JavaScript? I know it's rather easy to remember which element is being focused on a page and re-focus it after a dialog (that's part of the HTML) is being dismissed, but can this technique somehow be applied to closing the native OS keyboard as well? I've done some Googling, but I couldn't find anything on JavaScript events being sent to the page by the keyboard. It might be possible to detect when the keyboard appears and disappears by checking the height of the viewport or something, I guess, but that seems very hackish.
>
> Is anyone aware of a reliable technique that could help me achieve this?
>
> Thanks.
>
> Roel
>
>> On 4 Sep 2017, at 19:47, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> On 04/09/2017 18:37, Jonathan Cohn wrote:
>>> 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
>>
>> Pretty sure this is a long-standing gripe about iOS/VO and on-screen keyboard interaction. It's well known but, for whatever reason, Apple seems content to ignore it for years.
>>
>> With regards to the "set focus to whatever focusable element is nearest to the last known good focus location", yes that's a heuristic applied by VoiceOver (also in situations like web content custom modal dialogs being closed without focus being appropriately managed, which always makes for fun results when trying to report accessibility issues and getting mixed results depending on what the underlying page contains :) )
>>
>> P
>> --
>> Patrick H. Lauke
>>
>> www.splintered.co.uk | https://github.com/patrickhlauke
>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>> >> >> >> >
> > > >

From: Roel Van Gils
Date: Mon, Sep 04 2017 11:24PM
Subject: Re: VoiceOver in Safari on iOS: how to handle focus when using software keyboard
← Previous message | Next message →

Thanks, Jonathan. Looking forward to their reply. Is this dev list public?

> On 4 Sep 2017, at 22:13, Jonathan Cohn < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hello,I took the initiative, and forwarded this note to the accessibility dev list at Apple. I'll reply back with any positive feedback.
>
> Best wishes,
>
> Jonathan Cohn
>
>
>
>> On Sep 4, 2017, at 3:24 PM, Roel Van Gils < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> Thanks, Patrick and Jonathan! Great input.
>>
>> To summarise.
>>
>> When focus management is done right - for example, by giving back `focus()` to the link or button that initiated a custom dialog, after a user performed an action that caused that dialog to be closed (i.e. being removed from the DOM or have its `display` property set to `none`) - all is fine :)
>>
>> However, when the VoiceOver cursor is 'in limbo', its "set focus to whatever focusable element is nearest to the last known good focus location" heuristic is being triggered. I get that, and that's fine!
>>
>> But, the same thing happens when using the on-screen keyboard and that is indeed a bug, I think. Because, when using the on-screen keyboard (provided by the OS), I think it's VoiceOver's responsibility (not the developer's) to remember the last known focused element (in practice, that will aways be an text field or text area) and restore that focus when the OS keyboard slides back down.
>>
>> I'm wondering why Apple seems to ignore this, because to me this seems to be a very common UI interaction that must surely confuse many non-sighted users.
>>
>> That being said, would there be any way to 'fix' this behaviour using JavaScript? I know it's rather easy to remember which element is being focused on a page and re-focus it after a dialog (that's part of the HTML) is being dismissed, but can this technique somehow be applied to closing the native OS keyboard as well? I've done some Googling, but I couldn't find anything on JavaScript events being sent to the page by the keyboard. It might be possible to detect when the keyboard appears and disappears by checking the height of the viewport or something, I guess, but that seems very hackish.
>>
>> Is anyone aware of a reliable technique that could help me achieve this?
>>
>> Thanks.
>>
>> Roel
>>
>>> On 4 Sep 2017, at 19:47, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>> On 04/09/2017 18:37, Jonathan Cohn wrote:
>>>> 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
>>>
>>> Pretty sure this is a long-standing gripe about iOS/VO and on-screen keyboard interaction. It's well known but, for whatever reason, Apple seems content to ignore it for years.
>>>
>>> With regards to the "set focus to whatever focusable element is nearest to the last known good focus location", yes that's a heuristic applied by VoiceOver (also in situations like web content custom modal dialogs being closed without focus being appropriately managed, which always makes for fun results when trying to report accessibility issues and getting mixed results depending on what the underlying page contains :) )
>>>
>>> P
>>> --
>>> Patrick H. Lauke
>>>
>>> www.splintered.co.uk | https://github.com/patrickhlauke
>>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>> >>> >>> >>> >>
>> >> >> >> >
> > > >

From: Helene VINH
Date: Tue, Sep 05 2017 2:30AM
Subject: Re: [EXT]VoiceOver in Safari on iOS: how to handle focus when using software keyboard
← Previous message | Next message →

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 ADDRESS REMOVED =
www.amadeus.com


From: Jim Homme
Date: Fri, Sep 08 2017 6:26AM
Subject: Re: [EXT]VoiceOver in Safari on iOS: how to handle focus when using software keyboard
← Previous message | No next message

Hi,
I just realized by reading this thread that I never press the Done button on the keyboard because I never know when I'm going to find it. I usually touch the screen to get focus to go out of the field and make the keyboard disappear. I'm sure that is very inefficient, but it works. I can always navigate my way to where I want to be after that.

Jim


=========Jim Homme,
Team Lead and Accessibility Consultant,
Bender HighTest Accessibility Team
Bender Consulting Services, Inc.,
412-787-8567,
= EMAIL ADDRESS REMOVED =
http://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
E+R=O