Re: timeouts

 Originally it was all about saving the user data, but it got cut and cut...

All the best

Lisa Seeman

LinkedIn, Twitter





---- On Tue, 28 Nov 2017 01:37:14 +0200 John Foliot<john.foliot@deque.com> wrote ---- 

Hi Rachel,


Looking at your use-case of shopping: again, the time-out issue is only once you are authenticated (Checking out). 


You can test this today: go to Amazon and place something in your shopping cart. Even if you close your browser, when you return to Amazon (using the same browser) the items you previously placed in the shopping cart are still there (I'm not sure, but I suspect it is dropping a cookie of sorts). The only time you will encounter a timeout issue at Amazon is when you are authenticated and adding credit-card & shipping information... there, if you wait too long to finish filling in the required data, Amazon's server will disconnect you from the e-commerce server for security reasons.


Thus, the timeout 'timer' doesn't start at the beginning of the process, *ONLY* at the beginning of the authenticated session. 


While I have not verified this at every e-commerce site I visit, knowing what I do about online sales retention and lost sales, I suspect that online retailers have already got this one figure out :-)


*****


For multi-page forms, again, to be able to hold all of the information "in state" will either require a similar "cookie" solution to what I suspect Amazon is doing, or some type of logging in - and for complex forms, I suspect the later rather than the former.


So... you start by authenticating onto the site (think Quicken Online - you log in with User and PW), and you go through the first page. You hit the "Continue" button which actually posts the data already collected via the page 1 form to a session on the remote server, but halfway through page 2 you leave the process halfway through filling out page 2's form. After a period of inactivity, the Quicken server would terminate the connection, for both security and privacy (but also keeping open a direct session like that has an overhead cost at scale: web servers aren't really designed for prolonged connectivity like that). 


In that scenario, you'd have saved all of Page 1's data, but Page 2's data would be lost (unless Quicken helpfully added a "Save what I have provided" button for partially completed pages). 


Again however, the only time Quicken could proactively warn you of the timeout function would be when you are logging in - any other time would either be overly intrusive (Lisa's 'every 5 minutes distraction' concern, which is totally legitimate), or the "Warning we're about to close the session" dialog which happens after you've walked away from the desk (more often than not).


The bottom line is this: for every instance of being "timed-out", you first had to "time-in" (aka log in) - you cannot be kicked of a server that you have never entered into. 


The current SC has (I suspect) missed a more critical 'ask', which is that authenticated sites SHOULD (MUST?) provide the helpful "Save what I have already provided, even if it is incomplete" button that I alluded to (and FWIW, I'm not sure that Quicken has that button, but it would be an awesome feature - cc'ing Ted Drake from Intuit to see if any of their products have that or similar today).


JF


On Mon, Nov 27, 2017 at 4:56 PM, Bradley Montgomery, Rachael L. <rbradley@mitre.org> wrote:
   Hello,
  
 I am going to chime with my understanding of the conversation so far.  With the current wording, notifying the user of a timeout at the beginning of the process, at session login, or the beginning of a multipage form would be “before the timer starts”.  These should all be included in the examples.
  
 The scenario that is causing difficulty in getting alternate wordings through is shopping. I am browsing a web site and select an item. It would be difficult to tell the user about the timeout at entry into the site which is the start of the process of shopping and before any data entry (aka selecting an item). From a design standpoint, it is easiest and most effective to tell them when they add something to the cart or start filling in data that would be lost.  
  
 The intent of the new wording is to allow designers flexibility in when they notify users in scenarios other than a clear process or session login. 
  
 Mike G. recommended that we include failure techniques to cover some of the worse edge cases that could result from misinterpreting this SC.
  
 Regards,
  
 Rachael 
  
 From: John Foliot [mailto:john.foliot@deque.com] 
 Sent: Monday, November 27, 2017 5:01 PM
 To: lisa.seeman <lisa.seeman@zoho.com>
 Cc: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>; Bradley Montgomery, Rachael L. <rbradley@mitre.org>
 Subject: Re: timeouts
  
   Hi Lisa,
 
   
 
  > 
  ​ ​
 
 The clearest way to conform will be to have a message each time a timer starts and I think that has more disadvantages then advantages for the user. 
   It has been my experience over the past 2 decades​ that timeout warnings are generated based upon user inactivity... if you pause multiple times throughout a process, the server has no idea if you are still there or not, and so it starts the countdown. Every time the countdown starts, it advises you - if you take 6 pauses that each last 4 minutes, but spaced out over the course of an hour, then yes, you will get 6 'warnings'. That cannot be helped, nor modified that I can see. 
 
   
 
  In other words, you could be on page 1 of 8, 4 of 8, or 8 of 8 of a lengthy web-form process (but not yet fully submitted), and if at any point the server detects a period of time of inactivity, THEN the countdown starts towards severing the connection. Having a message pop-up 2 minutes after you've walked away from your desk stating "Warning, you will be logged out in 5 minutes" helps no-one, and is actually something we want to avoid, but must remain there for other security/usability reasons.
 
   
 
  Thus, the only time a page author can proactively warn the user of this timeout possibility is at the start: after that, it's a time function managed by the authenticated server. (And being connected to an authenticated session on the server is pretty much the only time that you will be "logged off" or timed-out - because you first had to "log on" - so, again, posting a proactive warning at the login phase will be the simplest means of meeting this SC.) 
 
   
 
  Logging on is the true start of the activity timer being set, however that is but one part of the condition for triggering the timeout - the other is inactivity. What I think is happening is that you are not recognizing the role that the server is playing here: machines can't think, so they can only be programmed to react to specific conditions (such as "IF inactivity >= x minutes, THEN run routine that generates timeout warning").
 
   
 
  Please review my example: it clearly states that the timeout (if you choose to proceed) will happen at *any* point of the process if you stop interacting with the process - which is about the best you can hope for - nobody can say for sure when you (or any user) will need a break, or where in a process that user may be when needing that break. I believe the current draft language is accurate then:
 
   
 
   ​
 
 Where data can be lost due to user inactivity, users are warned before an activity timer is set about the estimated length of inactivity that generates the data loss, unless the data is preserved for a minimum of 20 hours of user inactivity.​
 
  
   
  ​> ​
 
 iE it is not the "best being the enimy of the good" rather that this SC wording drops below the mark of providing a clear benefit for the user and in some cases may even be a disadvatage.
   ​Such as?...​
 
   
 
  JF
 
  
 
   
  On Mon, Nov 27, 2017 at 2:24 PM, lisa.seeman <lisa.seeman@zoho.com> wrote:
      So far we have John who thinks it is worth keeping it with the proposed wording. Does anybody else agree?
 
   
 
  Another issue to me will be the continuous reminder of how long I have will adds stress ("you have 5 minuets to finish this section"). knowing it at the start of the process is much better
  All the best
 
 Lisa Seeman
 
 LinkedIn, Twitter
 
 
 
  
   
 ---- On Mon, 27 Nov 2017 21:13:27 +0200 lisa.seeman<lisa.seeman@zoho.com> wrote ---- 
 
      The clearest way to conform will be to have a message each time a timer starts and I think that has more disadvantages then advantages for the user. iE it is not the "best being the enimy of the good" rather that this SC wording drops below the mark of providing a clear benefit for the user and in some cases may even be a disadvatage.
   
 
  But that is just my opinion. If more COGA experts disagree and prefer this to be in then have nothing  then of course we should go for it. 
   
  All the best
 
 Lisa Seeman
 
 LinkedIn, Twitter
 
 
 
  
   
 ---- On Mon, 27 Nov 2017 20:13:53 +0200 John Foliot<john.foliot@deque.com> wrote ---- 
 
    Hi Lisa,
  > some people might warn the user on every page that a timer starts, and not at the beginning of the process.
  
 Could we not address this in the Understanding document?
  ​ For all of our new Success Criteria in WCAG 2.1, it goes without saying that there is an educational component to all of them​, and so I'd ensure that "user-story" examples associated to the understanding document here will be critical. 
 
    
 
 
   (Also, I've never seen a page-by-page timeout mechanism; it is usually associated to an authenticated state and general inactivity at the site, irrespective of which 'page' you may be on... as I've tried to explain numerous time, the timeout is activated by the authenticated host server and not individual pages: this isn't done via client-side scripting, so this is a pure-play editorial requirement in WCAG 2.1.)
 
   
  > Do we still see value in pushing for this SC if we can only get in the wording above
  ​ 
 
 (JF: below)​
  ​
 
 ?
    ​
 
    ​
 
 Where data can be lost due to user inactivity, users are warned before an activity timer is set about the estimated length of inactivity that generates the data loss, unless the data is preserved for a minimum of 20 hours of user inactivity.​
    
  
 Seems to me that something is better than nothing. As an old boss of mine used to say, "Don't let perfect be the enemy of good"
  ​. 
 
 
    
 
 
   I think this current wording gets us to close enough for most use-cases, recognizing that there will always be edge-cases and corner-cases that may fall outside of the current language. This SC could be met simply by adding timeout information at login time (which, if I was the developer, would be what I'd likely do, almost like a Terms of Service notice):
 
 
   
 
 
     N​ame:_______________​
 
 
       ​Password: ____________
 
   
 
 
       [ ] I understand that I will be logged out of this site after 15 minutes of inactivity.
 
   
 
 
                  [ SUBMIT ]​
 
 
     
 
   JF
 
 
 
   
  On Mon, Nov 27, 2017 at 11:45 AM, lisa.seeman <lisa.seeman@zoho.com> wrote:
    Hi Folks
 
 We may only be able to get the following wording on time outs in WCAG:
   Where data can be lost due to user inactivity, users are warned before an activity timer is set about the estimated length of inactivity that generates the data loss, unless the data is preserved for a minimum of 20 hours of user inactivity.
 
   
 
  With the wording above, some people might warn the user on every page that a timer starts, and not at the beginning of the process. SO i wont be able to know, at the start of a process, that this process times out to fast for me to complete the task and just gives me more to read.
 
   
 
  Do we still see value in pushing for this SC if we can only get in the wording above?
 
   
 
  (note the original wording is here: https://www.w3.org/TR/WCAG21/#timeouts
 
  comment summary is here: https://www.w3.org/2002/09/wbs/35422/Resolving_Timeouts/?)
 
   
 
  
 All the best
 
 Lisa Seeman
 
 LinkedIn, Twitter
 
 
 
 
 
  
  
   
 
 -- 
                  John Foliot
 
 
 Principal Accessibility Strategist
 
 Deque Systems Inc.
 
 john.foliot@deque.com
 
 
   
 
  Advancing the mission of digital accessibility and inclusion
 
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
  
 
 
 
 
   
 
 
 
  
 
 
 
 
  
 
 
 
   
 
 -- 
                  John Foliot
 
 
 Principal Accessibility Strategist
 
 Deque Systems Inc.
 
 john.foliot@deque.com
 
 
   
 
  Advancing the mission of digital accessibility and inclusion
 
 
 
 
 
 
 
 
 
 
 
 
 
 


 
 




-- 
John Foliot


Principal Accessibility Strategist

Deque Systems Inc.

john.foliot@deque.com



Advancing the mission of digital accessibility and inclusion