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

Hi Stefan

A very important point you raise. It looks like notification of time limit is one of the vert many things that it should be possible to customize. For people on the autism spectrum it might be best to disable any available timeout notifications (someone could probably set that option up in their user profile) whereas for those users that need to take regular breaks but who are not stressed by knowing there is a time-limit would really benefit from being notified in advance.

I think a lot of people may have experience the situation where they take a break, during which a notification that the session will timeout is issued (but not read because you are not there). To arrive back, to see that notice and to discover that the session has been terminated, with all your input lost, certainly creates stress in everyone (with or without a cognitive or learning disability). Whereas that can be seen as a usability issue, I think that it is likely that people with certain cognitive disabilities will encounter this infuriating situation much more commonly.

Given that what is currently proposed may create rather than solve problems for some people with cognitive disabilities, I’m not sure what we should do. We could try to tie it to personalization, but then it would succeed or fail according to whether we manage to get any personalization SCs in WCAG 2.1.

Best regards

Mike

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

Hello!
I am new as an invited expert so I am not familiar with the procedures but I have something to say in this discussion.


  *   For many people it is a good thing to declare that there is a time limit (especially for people who by any reason work slow or need coffee brakes)
  *   For many people the knowledge of an existing time limit is very stressful and it will make them perform bad just by knowing that a limit is presence (especially for people with some cognitive difficulties)

If a time limit is set properly, let’s say 99 % of the user will never be affected by the limit. If no information is given in advance they will never know there was a limit. The people who really need to know about the time limit is the one approaching close/closer to the limit. Then it will be a useful information even for people who will get stressed about knowing about the limit. So I think a good solution is to display the information when a certain amount of time has passed. If you ask me for the formula for figuring out what time that should be I don’t know.

I recently did a test where people in my research group (25 persons with different cognitive disabilities) tested booking seats on a theatre. An information was given that they had 100 seconds to finish the reservation of the specific seat they wanted. Two users directly stopped and declared that they could not go on due to stress (two persons within the autism spectrum). The rest easily finished the task under 20 seconds. With no information about the time limit I think all users would have finished the task within 20-30 seconds. So in this case a better solution would be to display the time limit information after say 45 seconds combined with an option to prolong the 100 second time limit.

So I think the context where the time limit is used is very important. Mikes example of working on something for an hour and then loose information due to inactivity for 10 minutes is perhaps another type of time limit related problem. In that case information upfront maybe would not be so stressful. But I have not tested that scenario. All I can say is that probably not all people with cognitive disabilities will benefit from knowing that there is a time limit.

Best regards
Stefan

Stefan Johansson | Ideolog

+46 708 23 10 64
stefan.johansson@funka.com<mailto:stefan.johansson@funka.com>

Funka Nu AB
Tegnérgatan 23
111 40 Stockholm
Växel: +46 8 555 770 60
www.funka.com<http://www.funka.com/>

Prenumerera på Funkas nyhetsbrev<http://www.funka.com/om-funka/nyheter/nyhetsbrev/prenumerera/>

[Logo för Funka]

Från: Katie Haritos-Shea GMAIL [mailto:ryladog@gmail.com]
Skickat: den 11 maj 2017 16:20
Till: alands289@gmail.com<mailto:alands289@gmail.com>; 'Michael Pluke'; 'David MacDonald'
Kopia: 'Andrew Kirkpatrick'; 'WCAG'
Ämne: RE: Follow up from the meeting on Issue 14: timeouts

Again I have seen this several times now, the last time yesterday when I was signing up for an Awards Ceremony that Knowbility is holding – the notice in advance to how much time you will have to complete the activity, when you start the activity. The ability to extend that time if needed, falls under 2.2.1.

​​​​​* katie *

Katie Haritos-Shea
Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)

Cell: 703-371-5545 | ryladog@gmail.com<mailto:ryladog@gmail.com> | Oakton, VA | LinkedIn Profile<http://www.linkedin.com/in/katieharitosshea/> | Office: 703-371-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: alands289@gmail.com<mailto:alands289@gmail.com> [mailto:alands289@gmail.com]
Sent: Thursday, May 11, 2017 10:16 AM
To: Michael Pluke <Mike.Pluke@castle-consult.com<mailto:Mike.Pluke@castle-consult.com>>; David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>>; Katie Haritos-Shea GMAIL <ryladog@gmail.com<mailto:ryladog@gmail.com>>
Cc: 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

+1

Alan Smith

From: Michael Pluke<mailto:Mike.Pluke@castle-consult.com>
Sent: Thursday, May 11, 2017 9:57 AM
To: alands289@gmail.com<mailto:alands289@gmail.com>; David MacDonald<mailto:david100@sympatico.ca>; Katie Haritos-Shea GMAIL<mailto:ryladog@gmail.com>
Cc: Andrew Kirkpatrick<mailto:akirkpat@adobe.com>; WCAG<mailto:w3c-wai-gl@w3.org>
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> [mailto:alands289@gmail.com]
Sent: 11 May 2017 14:31
To: Michael Pluke <Mike.Pluke@castle-consult.com<mailto:Mike.Pluke@castle-consult.com>>; David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>>; Katie Haritos-Shea GMAIL <ryladog@gmail.com<mailto:ryladog@gmail.com>>
Cc: 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

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<mailto:Mike.Pluke@castle-consult.com>
Sent: Thursday, May 11, 2017 9:03 AM
To: alands289@gmail.com<mailto:alands289@gmail.com>; David MacDonald<mailto:david100@sympatico.ca>; Katie Haritos-Shea GMAIL<mailto:ryladog@gmail.com>
Cc: Andrew Kirkpatrick<mailto:akirkpat@adobe.com>; WCAG<mailto:w3c-wai-gl@w3.org>
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> [mailto:alands289@gmail.com]
Sent: 09 May 2017 20:27
To: David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>>; Katie Haritos-Shea GMAIL <ryladog@gmail.com<mailto:ryladog@gmail.com>>
Cc: 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

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<mailto:david100@sympatico.ca>
Sent: Tuesday, May 9, 2017 3:19 PM
To: Katie Haritos-Shea GMAIL<mailto:ryladog@gmail.com>
Cc: Andrew Kirkpatrick<mailto:akirkpat@adobe.com>; WCAG<mailto:w3c-wai-gl@w3.org>
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
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd<http://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<mailto: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<tel:(613)%20235-4902>

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

twitter.com/davidmacd<http://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<mailto: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<tel:(703)%20371-5545> | ryladog@gmail.com<mailto:ryladog@gmail.com> | Oakton, VA | LinkedIn Profile<http://www.linkedin.com/in/katieharitosshea/> | Office: 703-371-5545<tel:(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<mailto:akirkpat@adobe.com>]
Sent: Tuesday, May 9, 2017 1:30 PM
To: WCAG <w3c-wai-gl@w3.org<mailto: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





________________________________