WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Native Apps: dealing with auto-updating conten in webviews

for

From: Patrick H. Lauke
Date: Sep 27, 2022 6:46AM

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