RE: session timeouts - Re: Guideline 2.2 Issue Summary

I had an action item to do complete the end to end for 2.2 L1 SC1

And that was also an issue that I wanted to bring to our TEAM A meeting. The
security issues in saying "no timed events."

In light of Gregg's suggestion below I would like to suggest the following
bullet to be added to 2.2 L1 SC1 where it says:

"Content is designed so that time-outs are not an essential part of
interaction, or at least one of the following is true for each time-out that
is a function of the content:

-the user is allowed to deactivate the time-out or; 
-the user is allowed to adjust the time-out over a wide range which is at
least ten times the length of the default setting or; 
-the user is warned before time expires, allowed to extend the time-out with
a simple action (for example, "hit any key") and given at least 20 seconds
to respond or; 
-the time-out is an important part of a real-time event (for example, an
auction), and no alternative to the time-out is possible or; 
- the time-out is part of an activity where timing is essential (for
example, competitive gaming or time-based testing) and time limits can not
be extended further without invalidating the activity.

<proposed>
- the time-out is an essential security issue (for example, online banking)
</proposed>


And then in the guide doc I could add: 

<proposed> in situations where time-outs are an essential security issue, a
function allows the user to extent the time-out to at least 10 times the
timeout period. This would allow the site to drop people who left the
process but keep most people who are just slower.
</proposed>



.Access empowers people
            .barriers disable them.

 www.eramp.com


-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Gregg Vanderheiden
Sent: Monday, October 10, 2005 2:59 PM
To: 'Gez Lemon'; w3c-wai-gl@w3.org
Subject: RE: session timeouts - Re: Guideline 2.2 Issue Summary


Yes

How about "at least 10 times the timeout period".  That would allow you to
drop people who left the process but keep most all people who are just
slower. 


 
Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 


-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Gez Lemon
Sent: Monday, October 10, 2005 1:47 PM
To: w3c-wai-gl@w3.org
Subject: Re: session timeouts - Re: Guideline 2.2 Issue Summary


On 10/10/05, Isofarro <lists@isofarro.uklinux.net> wrote:
> Be a little wary of the practical implications of these ideas (both 
> ideas). Server session timeouts are typically there as a means of a 
> server reclaiming unused memory. In the UK there's also the Data 
> Protection Act to consider, which, in terms of financial websites and 
> its related webapplications, its not advisable to keep a session open 
> indefinitely, nor is it advisable to store potentially private 
> information in a cookie.

Good points, Mike. The only other technique I can think of would be to offer
registration and keep the transaction in a database, which would allow them
a reasonable amount of time (however much the administrator could afford for
a transaction table) to complete the form.

Best regards,

Gez

--
_____________________________
Supplement your vitamins
http://juicystudio.com

Received on Tuesday, 11 October 2005 16:51:20 UTC