E-mail List Archives

Search E-mail List Archives for

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

From: Anna Marie Golden
Date: Fri, Sep 08 2017 4:31PM
Subject: WebAIM-Forum Digest, Vol 150, Issue 7
No previous message | Next message →

> 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
>
>
> > > 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/>;*

From: Roel Van Gils
Date: Mon, Sep 11 2017 6:17AM
Subject: Re: WebAIM-Forum Digest, Vol 150, Issue 7
← Previous message | No next message

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 ADDRESS REMOVED = > wrote:
>
>> 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
>>
>>
>> >> >> 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/>;*
> > > >