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

Jason/Katie/David/Gregg/others,

This SC proposal relates to the user needs document for Entering data, error prevention & recovery (https://rawgit.com/w3c/coga/master/gap-analysis/#table-3-entering-data-error-prevention-recovery). The most applicable user need is “I need enough time, and not lose my work”. Unfortunately, we can’t expect that all sites will be able to offer unlimited time on a task, so SC 2.2.1 has requirements related to the user being able to remove, adjust, or extend the limit, with a few exceptions.

What we have heard from the COGA TF is that part of the barrier is not knowing whether a task can be completed in the time allowed. If the user knows that there is a 10 minute / 60 minute / no limit they can decide whether to make sure that they collect all of the needed information first or just go ahead and start work.

A site can pass 2.2.1 this by (not including a limit, notifying the user about the time limit in advance, or remembering information for the user).

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.
  2.  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.

What do people think about that?

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe

akirkpat@adobe.com
http://twitter.com/awkawk


From: "White, Jason J" <jjwhite@ets.org<mailto:jjwhite@ets.org>>
Date: Wednesday, May 10, 2017 at 12:41
To: David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>>, Gregg Vanderheiden <greggvan@umd.edu<mailto:greggvan@umd.edu>>
Cc: Katie GMAIL <ryladog@gmail.com<mailto:ryladog@gmail.com>>, Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>>, WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: RE: Follow up from the meeting on Issue 14: timeouts



From: David MacDonald [mailto:david100@sympatico.ca]
Sent: Wednesday, May 10, 2017 7:29 AM

I think the SC requiring advance warning for time limits which states the amount of time available (if this time limit is known by the author) is a viable SC (or viable addition to 2.2.1)

[Jason] It’s viable, but I’m not enthusiastic about it, as it doesn’t solve the user’s problem. Could we better confine the use of options 2 and 3 in SC 2.2.1?
That is, can we state the circumstances in which it’s acceptable to use option 2 or 3? At the moment, it’s entirely at the author’s discretion, whereas from the user’s point of view, either the first option (the time limit can be removed) or the last option (it’s more than 20 hours in duration) is far preferable. The exceptions are outside the content author’s control and so would remain in any case.

________________________________

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.

________________________________