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

+1 on this Andrew

The only outstanding thing for me is the determine whether the the
notification for the amount of time available to the user is the default
value or the extended value required in 2.2.1.

But deciding on that can be be later and is not a blocker for the next
draft for me.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Wed, May 10, 2017 at 6:12 PM, Andrew Kirkpatrick <akirkpat@adobe.com>
wrote:

> 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
>       1. 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
>       1. 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>
> Date: Wednesday, May 10, 2017 at 12:41
> To: David MacDonald <david100@sympatico.ca>, Gregg Vanderheiden <
> greggvan@umd.edu>
> Cc: Katie GMAIL <ryladog@gmail.com>, Andrew Kirkpatrick <
> akirkpat@adobe.com>, WCAG <w3c-wai-gl@w3.org>
> Subject: RE: Follow up from the meeting on Issue 14: timeouts
>
>
>
>
>
> *From:* David MacDonald [mailto:david100@sympatico.ca
> <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.
> ------------------------------
>

Received on Thursday, 11 May 2017 00:28:03 UTC