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



*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 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
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902 <(613)%20235-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 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 <(703)%20371-5545> **|* *ryladog@gmail.com*
>> <ryladog@gmail.com> *|* *Oakton, VA **|* *LinkedIn Profile*
>> <http://www.linkedin.com/in/katieharitosshea/> *|* *Office: 703-371-5545
>> <(703)%20371-5545> **|* *@ryladog* <https://twitter.com/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
>>
>
>