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

+1

Alan Smith

From: Michael Pluke
Sent: Thursday, May 11, 2017 9:57 AM
To: alands289@gmail.com; David MacDonald; Katie Haritos-Shea GMAIL
Cc: Andrew Kirkpatrick; WCAG
Subject: RE: Follow up from the meeting on Issue 14: timeouts

Valuable for all, sure, but probably essential for those people whose cognitive impairment may make it stressful for them to concentrate on a task for an extended period of time.

Best regards

Mike

From: alands289@gmail.com [mailto:alands289@gmail.com] 
Sent: 11 May 2017 14:31
To: Michael Pluke <Mike.Pluke@castle-consult.com>; David MacDonald <david100@sympatico.ca>; Katie Haritos-Shea GMAIL <ryladog@gmail.com>
Cc: Andrew Kirkpatrick <akirkpat@adobe.com>; WCAG <w3c-wai-gl@w3.org>
Subject: RE: Follow up from the meeting on Issue 14: timeouts

Mike,

I appreciate you contacting me on this.

>From your experience I can see how this will be a valuable enhancement for all users.

Alan Smith

From: Michael Pluke
Sent: Thursday, May 11, 2017 9:03 AM
To: alands289@gmail.com; David MacDonald; Katie Haritos-Shea GMAIL
Cc: Andrew Kirkpatrick; WCAG
Subject: RE: Follow up from the meeting on Issue 14: timeouts

Alan

I too have not seen this, but I was one of the people who proposed the idea. The logic is that it is of no value to me to be told that I will be timed out if I don’t do anything in the next 5 minutes if I have already taken a 10 minute break! This has happened to me on more than one occasion! If I knew this in advance, then I wouldn’t have taken a 10 minute break and lost maybe an hour’s work.

Mike

From: alands289@gmail.com [mailto:alands289@gmail.com] 
Sent: 09 May 2017 20:27
To: David MacDonald <david100@sympatico.ca>; Katie Haritos-Shea GMAIL <ryladog@gmail.com>
Cc: Andrew Kirkpatrick <akirkpat@adobe.com>; WCAG <w3c-wai-gl@w3.org>
Subject: RE: Follow up from the meeting on Issue 14: timeouts

David,

I’ve seen time limits announced that they were going to expire or the user will be logged out due to inactivity, but I have never seen anyone have it such that the time duration is advised or provided to a user before they start a process.

That may be a challenge.

Alan Smith

From: David MacDonald
Sent: Tuesday, May 9, 2017 3:19 PM
To: Katie Haritos-Shea GMAIL
Cc: Andrew Kirkpatrick; WCAG
Subject: Re: Follow up from the meeting on Issue 14: timeouts

Here's another draft of it addressing Alix Li's issue and also that the proposed wording above does not require notification of how much lime is in the time limit. Only that there is one.

======
For each time limit set by the content where user-entered data can be lost and the time limit is known, the user is advised about the time limit and how long it is at the start of the process.
=====


Cheers,
David MacDonald
 
CanAdapt Solutions Inc.
Tel:  613.235.4902
LinkedIn 

twitter.com/davidmacd
GitHub
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

On Tue, May 9, 2017 at 2:57 PM, David MacDonald <david100@sympatico.ca> wrote:
Hi Katie

Wouldn't the second SC add an additional requirement to authors that is not currently in the SC? It requires the user data to be preserved for 24 hours. Currently the 24 hour requirement is an OR statement in the SC ... if the time is announced at the start there is NOT a requirement to preserve the data for 24 hours. The new SC turns the 2 requirements into 'AND' statements. They both have to be done to pass the WCAG, and this raises the concerns mentioned on the previous call about privacy, and security if authors are forced to preserve data

So I could live with this:

Identify Time Limits: For each time limit set by the content where user-entered data can be lost, the user is advised about the time limit at the start of the process.

OR this

For each time limit set by the content where user-entered data can be lost, the user is advised about 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.”

But not splitting them up into two separate 'AND' requirements.

I think the shorter one might be better, because it sidesteps the security requirements completely.

We could also fix another concern mentioned by Alex on the call by leveraging the language from 3.3.3 "... are known"

Identify Time Limits: For each time limit set by the content where user-entered data can be lost and the time limit is known, the user is advised about the time limit at the start of the process.


Cheers,
David MacDonald
 
CanAdapt Solutions Inc.
Tel:  613.235.4902
LinkedIn 

twitter.com/davidmacd
GitHub
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

On Tue, May 9, 2017 at 2:36 PM, Katie Haritos-Shea GMAIL <ryladog@gmail.com> wrote:
Andrew,
 
I think you are correct, the Inactivity Timeout could/would be covered by 2.2.1 Timing Adjustable or the new proposed SC(s).
 
To expand on my suggestion for 3 separate SCs (and I do *not* see a downside for very finite distinct testable SCs), using others language suggestions:
 
1.       Identify Time Limits: For each time limit set by the content where user-entered data can be lost, the user is advised about the time limit at the start of the process.
2.       Save Data 24 Hours: For each instance where user-entered data can be lost due to a time out, the user is given the option to preserve the data for at least 24 hours.
3.       Inactivity Timeout: For each timeout set by the content due to inactivity, where user-entered data can be lost, the user is given the option to preserve the data for at least 24 hours.
 
But, as I said above, I think my #3 is already covered by 2.2.1.
 
To respond to your 3 options:
 
For #1, I don’t like it because it is an either/or outcome, when I think notifying the user in advance should always be provided when defined by the content.
Your text "For each time limit set by the content where user-entered data can be lost, the user is advised about 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.”
 
However, if you wanted to combine advance notice and 24 data saved then I suggest:
Identify Data Time Limits: "For each time limit set by the content where user-entered data can be lost, the user is advised about the time limit at the start of the process, and if a timeout occurs, the user is given the option to preserve the data for at least 24 hours.”
 
But honestly, I really don’t think we need Identify Data Time Limits above, as Jason pointed out, if a timeout occurs, then 2.2.1 Timing Adjustable would come into play.
 
So I vote for #2, Advance notice is vital, purely and simply.
 
In summary, I would like, plain and simple:
Identify Time Limits: For each time limit set by the content where user-entered data can be lost, the user is advised about the time limit at the start of the process.
 
And if others like the Save Data 24 Hours as another SC, that is fine.
 
 
​​​​​* katie *
 
Katie Haritos-Shea 
Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)
 
Cell: 703-371-5545 | ryladog@gmail.com | Oakton, VA | LinkedIn Profile | Office: 703-371-5545 | @ryladog

NOTE: The content of this email should be construed to always be an expression of my own personal independent opinion, unless I identify that I am speaking on behalf of Knowbility, as their AC Rep at the W3C - and - that my personal email never expresses the opinion of my employer, Deque Systems.
 
From: Andrew Kirkpatrick [mailto:akirkpat@adobe.com] 
Sent: Tuesday, May 9, 2017 1:30 PM
To: WCAG <w3c-wai-gl@w3.org>
Subject: Follow up from the meeting on Issue 14: timeouts
 
We had vigorous discussion on the Timeouts SC proposal on the last call.
 
The bottom line as I was hearing it on the call is that people recognize that there is value in the idea that users should have advance notice of time limits that the content imposes on the users. The challenge is in how we make this happen.
 
There was also a question raised by Jason about how this fits with 2.2.1 and that it might be confusing because it is separate. This is potentially true, but also a decision that we decided to defer until we see more of the SC that we accept and can decide whether to only add SC or if we can modify existing SC. This one might fit within a modified SC 2.2.1 but at least for now it is separate.
 
It seems that there are a few options being discussed:
1. advance notice, with an exception for sites that retain user-entered data for a day.
2. Advance notice, pure and simple.
3. Break apart into 3 SC – one to provide advance notice of any time limit, one to save data for a day, and one to address inactivity time limits
Here are a few options:
Relates to option 1: 
"For each time limit set by the content where user-entered data can be lost, the user is advised about 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.”
 
Relates to option 2 (suggested by mike gower and Steve Repser, edited into the same form as above): 
"For each time limit set by the content where user-entered data can be lost, the user is advised about the time limit at the start of the process."
 
Relates to option 3 – it would seem that the shorter version proposed by mike/steve would address the first SC, but I’m not sure what the “24 hour data retention” SC would look like, nor how the “inactivity time limit” SC would differ from the mike/steve version.
 
What do people think? Option 1, 2, 3, or something else?
 
Thanks,
AWK
 
Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe 
 
akirkpat@adobe.com
http://twitter.com/awkawk