- From: Ben Caldwell <caldwell@trace.wisc.edu>
- Date: Wed, 11 Jan 2006 15:08:19 -0600
- To: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>
- CC: w3c-wai-gl@w3.org
Long post warning. Unfortunately, I don't have specific proposals to offer at this time, but the following is a series of questions about server/session timeouts and what it means for them to be "a function of the content" vs. an exception to 2.2.1. --------------------------------------------------------------------- I think one of the concerns we should be able to cover at level 1 here is a situation where the default session timeouts have been set to unreasonably low values. For example, imagine a session time out for our WBS surveys of less than 10 minutes. If the consequence of a time out was data loss rather than a request to re-authenticate, I think we'd all like to see this covered at level 1. Even though there are cases where an author may not have control over the session time out setting on the server from which their content is served, they still (I believe) have a responsibility to ensure that the user can interact with their content in an accessible manner. (i.e. if need be, either request a change to the timeout from their sysadmin or move to a different host.) I did a little bit of digging on default settings for various server configurations: Apache: 30 minutes Zope: 20 minutes Tomcat: 30 minutes ASP Server: 20 minutes IIS: 10 minutes PHP: 3 hrs. What if the server configurations mentioned above were set to 2 minutes or less? Are we saying that, because the timeout is set on the server, it's not an accessibility barrier? I think we also have some ambiguity around the terms "session timeout" vs. "server timeout." The intent section of How to meet 2.2.1 currently talks about server timeouts: [snip] Notes Regarding Server Timeouts * Timed server redirects can be found below under Common Failures. * Server timeouts like login expiration are dealt with in success criterion 2.2.6. * Non-timed server redirects (e.g., 3xx response codes) are not applicable because there is no timeout: they work instantly. [end snip] A note at the end of the Optional techniques section reads: [snip] * Using a script to poll the server and notify a user if a timeout is present. Note: Where the author has no control over the server, the timeout is not a function of the content. [end snip] We also have a failure for 2.2.1 that is titled: [snip] Failure due to using server-side techniques to automatically redirect pages after a timeout. [end snip] Now I'm confused... In many cases, the consequences of a session time out occurring aren't a significant barrier (ex. you have to log in again). Are there specific situations where they are (ex. when data loss occurs) and we think they should be covered at level 1? Are we saying that timeouts set by a script (ex. PHP) are somehow different than timeouts that are set by a default configuration file in the server software? If content interacts with or adjusts the default timeout setting, is it considered a function of the content? What if the technology in use could easily adjust the default, but doesn't because the use of the default setting (theoretically not in their control) gives them the option to do nothing with regard to conformance to SC 2.2.1? -- Ben Caldwell | <caldwell@trace.wisc.edu> Trace Research and Development Center <http://trace.wisc.edu>
Received on Wednesday, 11 January 2006 21:08:29 UTC