E-mail List Archives

Search E-mail List Archives for

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

From: Detlev Fischer
Date: Fri, Sep 23 2022 1:42AM
Subject: Native Apps: dealing with auto-updating conten in webviews
No previous message | Next message →

In an audit of a native public transport app employing auto-updating
webviews, I am wondering how to deal with the issue that screen reader
users, having moved down a scolling list of available transport services
(blocks with departure time, station, service), suddenly lose their
focus when the webview content updates (every minute). Focus seems to be
reset not to the top of the webview, but to some other service located
at the approximate offset of prior (scrolled) location in the list and
upper viewport edge. (Whether this is determined by the OS or default
behaviour of VoiceOver or some behavior defined by the app, I don't
know.) The result: the screen reader output of the service the user has
moved to is suddenly interrupted by the output of some other service
higher up in the list.

The blind tester does not think it a good idea to have a control to stop
auto-updating (wanting to have the current info as anyone else) - so it
feels odd to fail such content for violation of 2.2.1 "Timing
adjustable" (and demand a control to pause auto-updating). In a sense,
this can be seen as a focus management issue (focus is not restored to
previous location) and thus may be seen to fail 2.4.3 "Focus order", but
I wonder whether in the given implementation it would actually be
possible to restore the focus precisely after the auto-update of content
in a webview. And then, since it is the SR focus that is lost, it may
rather fall under 1.3.2 "Meaningful sequence" - only that the sequence
itself is not the issue here. It actually resembles issues falling under
3.2.1 "On Focus" due to the disorienting behavior, but what happens has
nothing to do with the user activity of focussing.

It may be a behaviour that currently fails nothing and has to be
accepted. It could point to a need for something like 3.2.7 "On
Auto-update", with a draft SC text of "When content is updated
automatically, it does not initiate a change of context."  - but I am
not sure whether there would be practical and reliable ways of securing
that (especially in a design context using web views).

So is this behavior a WCAG (or rather EN 301 549 clause 11) failure? (I
know WCAG is for web, not native.) An if so, what SC do you see failing?

Any input would be greatly appreciated.

--
Detlev Fischer
DIAS GmbH
(Testkreis is now part of DIAS GmbH)

Mobil +49 (0)157 57 57 57 45

http://www.dias.de
Beratung, Tests und Schulungen für barrierefreie Websites

From: Patrick H. Lauke
Date: Tue, Sep 27 2022 6:46AM
Subject: Re: Native Apps: dealing with auto-updating conten in webviews
← Previous message | No next message

On 23/09/2022 08:42, Detlev Fischer wrote:
> In an audit of a native public transport app employing auto-updating
> webviews, I am wondering how to deal with the issue that screen reader
> users, having moved down a scolling list of available transport services
> (blocks with departure time, station, service), suddenly lose their
> focus when the webview content updates (every minute). Focus seems to be
> reset not to the top of the webview, but to some other service located
> at the approximate offset of prior (scrolled) location in the list and
> upper viewport edge. (Whether this is determined by the OS or default
> behaviour of VoiceOver or some behavior defined by the app, I don't
> know.)

I believe this is webkit/VoiceOver's default error handling...if the
currently focused element disappears, it will hunt for, and focus on,
any element that is close enough to the last known good focus location
(see it happen often on badly implemented modal dialogs ... when the
modal is closed without handling focus, you land on some
arbitrary-looking element that happens to be roughly at the same
coordinates as the close or ok button you just pressed).

The result: the screen reader output of the service the user has
> moved to is suddenly interrupted by the output of some other service
> higher up in the list.
>
> The blind tester does not think it a good idea to have a control to stop
> auto-updating (wanting to have the current info as anyone else) - so it
> feels odd to fail such content for violation of 2.2.1 "Timing
> adjustable" (and demand a control to pause auto-updating).

However, regardless of the personal preference of the blind tester, this
does sound exactly like the scenario that 2.2.1 tries to cover. So
having a "don't autorefresh and instead use pull-to-refresh and an
explicit refresh button" control or option available seems the correct
first step here. I'd also wonder, beyond SR users, what the impact on
non-SR users / COGA users might be - while they're in the middle of
reading something, the webview is refreshed and possibly loses their place.

> In a sense,
> this can be seen as a focus management issue (focus is not restored to
> previous location) and thus may be seen to fail 2.4.3 "Focus order", but
> I wonder whether in the given implementation it would actually be
> possible to restore the focus precisely after the auto-update of content
> in a webview.

Depending how it's been done, it may be tricky indeed. Just before the
refresh, you'd need to work out the current focus position (and this may
not be the actual focus, but wherever the reading cursor for VO was),
and after the refresh explicitly try and set focus back (but if it was
reading cursor, don't believe you have any control over that).

It'd probably be easier to an extent if the approach switched to
dynamically updating the same webview/page using JS, rather than a full
refresh.

And then, since it is the SR focus that is lost, it may
> rather fall under 1.3.2 "Meaningful sequence" - only that the sequence
> itself is not the issue here. It actually resembles issues falling under
> 3.2.1 "On Focus" due to the disorienting behavior, but what happens has
> nothing to do with the user activity of focussing.

Not quite sure I'd drag 1.3.2 into this. It does feel mostly like a mix
of 2.2.1 Timing adjustable and 2.4.3 Focus Order for not handling lost
focus properly.

P
--
Patrick H. Lauke

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