RE: Follow up from the meeting on Issue 14: timeouts

From: Andrew Kirkpatrick []
Sent: Wednesday, May 10, 2017 6:12 PM

This seems to be the version that most people are happy with:
For each time limit set by the content where user-entered data can be lost, the user is advised about the length of the time limit at the start of the process, unless any user-entered data is preserved for at least 24 hours after the limit is reached.

The outstanding issues seems to be:

  1.  Jason is concerned that this SC isn’t addressing the user need

     *   For this, I think that the COGA group is saying that it does, even if it is not as broad as the original proposal.
[Jason] This is where the disagreement lies, indeed. I think the proposal constitutes a marginal improvement over 2.2.1. If the user knows there is a time limit and has the ability to estimate how long the intended task will require, then, as you indicate, preparatory steps may be able to be taken – depending on whether the user has viable strategies for fitting the required work into the time limit.
Your example of collecting all required information in advance only works if the user is good at anticipating what information is needed. Lisa’s example of simply not using the Web application if the user judges that the intended task can’t be completed within the time limit actually demonstrates the need for a stronger requirement, since there may be no alternative means available to the user to complete the task that would otherwise be performed online, and our underlying objective is to make the Web application accessible, not to help users avoid it if it’s inaccessible. In this case, of course, the usefulness of the warning also depends on the user’s ability to estimate how long it will take to perform a task. If they haven’t used the given Web application before, then it’s hard to estimate time demands; and nothing in the proposal requires the application to inform the user of what they will be expected to do, and what information is needed, before they begin a task.
Thus, there are reasons to doubt the claimed extent of the benefits of this proposal.

  1.  Katie is concerned that the retention time is needed

     *   For this, it seems the only way that this would make sense is if there was authentication for the user (that is, time limits are in place for a reason, whether security or privacy, etc so sites that use time limits will typically have a good reason). If we are talking about data retention for authenticated sites, that is SC 2.2.5 (AAA). "When an authenticated session expires, the user can continue the activity without loss of data after re-authenticating”.
One approach would be to accept the new SC at AA and to discuss promoting 2.2.5 to AA.
[Jason] 2.2.5 doesn’t allow for a time limit on re-authenticating and continuing the activity, thus it may need a “real-time exception” and an “essential exception”, if promoted, similar to 2.2.1.
Another possibility would be a proposal based on 2.2.1 at Level AA that omits the second option (“adjust”) and the third option (“extend”), but leaves the remaining options as is. If there is concern about security issues (e.g., denial of service attacks), then this proposal could also be restricted to authenticated sessions. It would also be possible to require a warning to be issued in advance if a real-time exception or an essential exception applies, although I’m not sure that this would help the user very much, other than to say, in effect, “give this your undivided attention and hurry along”.
Thus we have significantly better options than the proposal which is currently under discussion. I think those options address the underlying problem more effectively.


This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.


Received on Thursday, 11 May 2017 13:40:00 UTC