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:24PM

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

> On 4 Sep 2017, at 22:13, Jonathan Cohn < <EMAIL 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 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 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
>>> >>> >>> >>> >>
>> >> >> >> >
> > > >