- From: Robinson, Norman B - Washington, DC <Norman.B.Robinson@usps.gov>
- Date: Tue, 11 Oct 2005 15:53:28 -0400
- To: "David MacDonald" <befree@magma.ca>, "Gregg Vanderheiden" <gv@trace.wisc.edu>, "Gez Lemon" <gez.lemon@gmail.com>, "WCAG WG mailing list" <w3c-wai-gl@w3.org>, <public-wcag-teama@w3.org>
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