Manage a session timeout

[michaelcattell]

Hello, we'd like to use this open discussion on the use of the Manage a session timeout:

Some discussion points to get things going:
Have you used or know where this component has been used?
Do you know if there's been any research or testing done on it or around it?
Do you agree with the user need?
Things we don’t know enough?

[ladine-cook]

New Style ESA had a Digital Accessibility Centre (DAC) audit on 25 June 2021 and this was reported:

Time Out (AAA)
Users are not warned of the duration in which inactivity could cause data loss and data is not preserved.

WCAG Reference:
2.2.6 Timeouts
Understanding Timeouts | How to Meet Timeouts
Issue ID: DAC_Time_Out_Issue1

Users are not warned of the duration in which inactivity will result in their session expiring. Timeouts can be difficult for some people with disabilities because these users may need more time to read and understand page content or complete forms online.

Solution:
Ensure that users are warned of the duration of inactivity that will cause the page to timeout and result in a loss of data.

[leahsmith1104]

We have this implemented on health assessments:

Our service is an internal facing agent service for handling a referral through an assessment, so from receiving the application, reviewing, gathering more medical evidence if necessary and then deciding if/what type of assessment is necessary before booking. It's currently in its infancy and is gradually being iterated and improved. There is currently only one area where timeout is applicable and that's where a manager assigns a referral to a list. If this is left then it will timeout. There is currently no notification as we've been informed this is currently too difficult to configure on the service/in the timeframe needed. We've accepted that it's such an unlikely scenario for now, and the impact is very little (user is informed they have timed out). Content is vague for now so that it can be reused if necessary before being iterated and improved properly in future.

[RintoC]

We are implementing the accessible timeout function on DWP Login and Identity Verification service. DWP digital design system does not specify where to put the non-js banner in the page.

My question is, should it come before the <main> tag, or first thing in the <main> tag?

See the prototype screenshot:

[mitz-lad]

@RintoC according to the notification banner guidance it states

Position a notification banner immediately before the page h1. The notification banner should be the same width as the page’s other content, such as components, headings and body text.

Based on that I would suggest it goes in the <main> tag immediately before the <h1> as guided.

[tom-napier]

Hey all, during recent testing on a product that implements this pattern, a team found some issues with the text in the modal dialog that forms the warning for the impending timeout.

The visible text that contains the updating time countdown is hidden from assistive software using aria-hidden="true". There's some visually-hidden text that updates less frequently. This is beneficial for screen-reader users, who will receive fewer interruptions. Screen-readers announce the visually hidden text and ignore the visible text.

However, zoom on macOS has "Hover Text", where someone can use the Command key (or other modifier) to zoom specific text on the screen. This function stops working when visible text stops being exposed to assistive software through use of aria-hidden. The following screenshot illustrates the hover text function - it works on the heading text (as demoed) and the button in the modal, but not the updating paragraph text.

Possible solutions

• Just use the text that's provided for screen-readers and don't hide any content from assistive software (i.e., just have the content that updates less frequently).
• Don't use updating text at all - it would also be interesting to see what considerations have been afforded to neuro-diversity. Perhaps this updating content is quite distracting for some users?
• Split the updating text from the other key parts of the content, so at least some of the key information is still available to a zoom user in the scenario described.

This is a bit of a niche issue in a sense (I'd imagine most zoom users don't use the hover text function, although I have no basis for saying that!), and arguably not a significant barrier to use, as a screen-magnifier user will still being able to use more typical screen-magnification functions. It probably is worth raising though, as the wider issue of hiding visible text from assistive software might cause other unforeseen consequences.