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

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 |  <mailto:ryladog@gmail.com> ryladog@gmail.com | Oakton, VA |  <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | Office: 703-371-5545 |  <https://twitter.com/Ryladog> @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 <mailto:akirkpat@adobe.com> 

http://twitter.com/awkawk