-
Notifications
You must be signed in to change notification settings - Fork 17
WTimeoutWarning
WTimeoutWarning provides a means to indicate to a user if there session is about to end due to a timeout.
If there is a limit on the time allocated to a user to read and interact with a page between submission events then the user must be allowed to extend this time or be provided with a warning when the time limit is at least 20 seconds in the future and this warning should include simple instructions as to how to extend the limit. There are certain exemptions to this which can be seen in Guideline 2.2. An application session timeout is the most common of this type of event in WComponent based applications.
The timeout message must be displayed to the user no later than the timeout of the shortest session within your application architecture. It must also be displayed at a time such that, if the user instigates an action immediately before the warning is replaced by the expiry message that the interaction will be honoured. This means you must show the session timeout expiry message in time that an action instigated at the time the message is displayed will reach the server (allowing for network time) before the real session timeout.
A timeout warning must be shown to the user at least 20 seconds before the session expiry message. This time will be overridden if it is less than 20.
The timeout period and warning period are both defined in seconds. In WTimeoutWarning there are default for both of these which can then be overridden per-application or per-user. The warning period cannot be less than 20.
The session timeout message is a guide for users. It is not directly connected to the actual application timeout(s). It is a direct consequence of complying with WCAG 2.0 guidelines that an application should show an expiry message a short time before a session is actually expired.
It is incumbent upon the application specification and implementation to ensure that if a user's session can timeout that a timeout warning message is shown no less than 20 seconds before the shortest timeout. It is, therefore, incumbent upon the application design and implementation to ensure that the shortest timeout within the application architecture is known and is used as a basis for determining the constraints around the session timeout message and that these contraints are close to the actual session timeout period but not so close that the user can find themselves delivering data to an expired session by invoking an action immediately before the expiry message is displayed.
It is entirely possible that a user interaction may occur after the display of the expiry message but before the actual session expiry. This will result in the session being reset and the application will continue as normal. This is not deemed to be defective behaviour as it is preferable to the alternate scenario of information being inadvertently lost by delivering to an expired session because the expiry message occurred too late.