RE: session timeouts - Re: Guideline 2.2 Issue Summary

WCAG Team,

	I apologize in advance if I haven't followed this topic in-depth
and hope you forgive me if I've missed scanning anything scanning the
last emails on this topic. There will be times where users will not,
under any circumstances, be able to request more time.

	Going with the concept of WCAG 2.0 success criteria, I would
see:

	Level 1: Users must be notified of the time allotted before
beginning use of the content. Users must be notified a timeout has
occurred.
	Level 2: Users must be allowed to request more time. The user is
allowed to adjust the time-out over the default setting. User allowed to
extend the time-out with the keyboard input (or equivalent).
	Level 3: User is allowed to deactivate the time-out. Users can
reauthenicate and the application should restore the session from point
of last access with all data submitted.

	I hope this is of use to you. I appreciate any off-list pointers
that guide my understanding such that my input is more useful.

	Regards,

	Norman B. Robinson

	

-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of David MacDonald
Sent: Tuesday, October 11, 2005 1:33 PM
To: 'Gregg Vanderheiden'; 'Gez Lemon'; 'WCAG WG mailing list';
public-wcag-teama@w3.org
Subject: RE: session timeouts - Re: Guideline 2.2 Issue Summary




Hi Gregg

I see your point. We may get some push back from some institutions who
may
argue that there is an increased risk of successful hacking even with a
limited number of extensions, but I think the extensions are a necessary
and
small compromise they should be willing to make, and I withdraw my
proposed
added bullet.

I'm not sure if our line about a maximum of 5 extensions (of which each
is
at least 10 times the original allowable time) should go in the Guide
Doc or
the SC of the Guidelines. Perhaps we can talk about that for a couple of
minutes today.

.Access empowers people
            .barriers disable them.

 www.eramp.com


-----Original Message-----
From: public-wcag-teama-request@w3.org
[mailto:public-wcag-teama-request@w3.org] On Behalf Of Gregg
Vanderheiden
Sent: Tuesday, October 11, 2005 1:22 PM
To: 'David MacDonald'; 'Gez Lemon'; 'WCAG WG mailing list';
public-wcag-teama@w3.org
Subject: RE: session timeouts - Re: Guideline 2.2 Issue Summary


Thanks David,

I don't see the need for the extra line -- and I see problems. 

Security is the primary reason that ATMs time out -- and those timeouts
(if
no extension is allowed) prevents any use by some people.   Allowing
extension of time does not hurt security but does make it accessible.


On the other hand - allowing a security exception would result in them
not
providing the extension.

So the question is "How does the current set of choices not meet the
needs?"
Only one I can see is if people asked for an indefinite number of
extensions.  So maybe we just change that one by adding "(for up to 5
extensions)" so that it reads  


-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 (for up to 5 extensions), or 


is there another problem we are trying to prevent? 
 
Gregg
 


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


-----Original Message-----
From: public-wcag-teama-request@w3.org
[mailto:public-wcag-teama-request@w3.org] On Behalf Of David MacDonald
Sent: Tuesday, October 11, 2005 11:50 AM
To: 'Gregg Vanderheiden'; 'Gez Lemon'; 'WCAG WG mailing list';
public-wcag-teama@w3.org
Subject: 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 19:53:42 UTC