WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WebAIM-Forum Digest, Vol 150, Issue 7

for

From: Roel Van Gils
Date: Sep 11, 2017 6:17AM

Thanks for your suggestion, Anna Marie! However, the issue I described, is not related to implicit or explicit labeling of input fields, I'm afraid. It's not a macOS issue either, but only occurs on iOS devices using the native soft keyboard.

Roel

> On 9 Sep 2017, at 00:31, Anna Marie Golden < <EMAIL REMOVED> > wrote:
>
>> 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
>> >
>
> Hi Roel!
>
> When I looked at the form, I noted that it uses implicit labeling- the
> label elements are wrapped around the inputs. This can sometimes cause
> undesirable behavior with some Apple/Mac systems. I'm curious to know if
> you would experience the same behavior if you use explicit labeling
> instead. That is to pull those inputs out of the labels and instead create
> the relationship between them using the "for" attribute in the label, the
> "id" attribute in the input, and providing the same value for both.
>
> --Anna Marie
> (First name = "Anna Marie")
>
> --
>
> *Anna Marie Golden, MHCID*
>
>
> *Master of Human-Computer Interaction + Design, Class of 2014*
>
> *IT Accessibility Specialist*
>
>
> *Accessible Technology Services, UW-IT(206) 221-4164*
>
>
>
>
> *Mailing Address:Box 354842University of Washington*
>
>
> *Seattle, WA 98195-4842*
>
> *Street Address:*
>
> *4545 Building*
>
> *4545 - 15th Avenue NE, Suite 100*
>
>
>
> *Seattle, Washington 98105http://www.washington.edu/accessibility/
> <http://www.washington.edu/accessibility/>;*
> > > >