WebAIM - Web Accessibility In Mind

E-mail List Archives

WebAIM-Forum Digest, Vol 150, Issue 7

for

From: Anna Marie Golden
Date: Sep 8, 2017 4:31PM

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