RE: timeouts

I think we would need the WG commitment  that they will pass such a failure technique for us to be ok with it.

All the best

Lisa Seeman

LinkedIn, Twitter





---- On Wed, 29 Nov 2017 02:53:23 +0200  Bradley Montgomery<rbradley@mitre.org> wrote ---- 

    Hello,
  
 I agree with John that the language does not require multiple reminders and I believe we can include a failure technique on multiple reminders as well as discussing working techniques in the understanding document to make it clear that this is not OK. 
  
 Best regards,
  
 Rachael 
  
 From: John Foliot [mailto:john.foliot@deque.com] 
 Sent: Tuesday, November 28, 2017 4:03 PM
 To: EA Draffan <ead@ecs.soton.ac.uk>
 Cc: lisa.seeman <lisa.seeman@zoho.com>; Milliken <neil.milliken@atos.net>; public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>; Bradley Montgomery, Rachael L. <rbradley@mitre.org>
 Subject: Re: timeouts
  
   Hi All,
 
   
 
  > I have to agree if there are constant reminders they will tend to exasperate the problem rather than solve it.
   ​...except, I do not see anywhere where this proposed SC language even suggests that this would be a suitable technique​, and we can certainly address any misconception around repeated warnings during a persistent session being a problem in the Understanding document. 
 
   
 
  I get that this isn't what Lisa originally envisioned or wanted, but, is there a problem with the language? 
 
   
 
    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.
 
  
 Unpacking this...
 
   
 
    Where data can be lost due to user inactivity...
 
  
  ​
 
  This can only happen during an authenticated session​, or if the end-user closes their browser mid-form: a non-authenticated form can stay open on your desktop for weeks, and as long as you do not disrupt the browser, it will retain the content you have entered into the fields. The only time data would be lost is mid-session in an authenticated session, due to the server (not the page author) terminating the session.
 
  
   ​...
 
 users are warned before an activity timer is set​
  ​...
 
      
 
 
 (Emphasis - underlining - mine) 
 The activity timer is set at the start of an authenticated session, but it is user *inactivity* that really starts the the clock ticking. The counting-down is a function of the server, and not under the control of the Web Content author. That said, since the warning comes BEFORE the activity timer is set, it happens at the start of the authentication process as the SC states: *Before*.
 
    
 
 
    ...
 
 about the estimated length of inactivity that generates the data loss
  ​
 
 ...
 
    
 
 
   ​E
 
 stimated
  ​,​
 
 as
  ​ there is no expectation that the warning is accurate to the millisecond - rather it gives the end user a sense of time (rather than a specific stop-watch function). The reality however is that while the countdown function that leads up to the termination of the authenticated session is a fixed amount of time, the 'definition' of inactivity will also factor in, so that the actual time will be the combination of what is set programmatically as the interval of time prior to registering "inactivity" + the actual countdown time before session termination. This language keeps it simple - "After approximately 5 minutes of inactivity, your session will be closed".
 
  
    
 
 
    ...
 
 unless the data is preserved for a minimum of 20 hours of user inactivity.
 
  
 The only way to preserve data
  ​ in an authenticated session is to submit. Sites *SHOULD* provide a means​ for users to save partially completed forms while "in session", and we should determine if there are any sites out there that do that today.
 
    
 
 
   However...
 
 
    
 
 
   I do not see anything in the language that suggests that repeated warnings are necessary here, nor even being asked for. This again will require that we are explicit and clear in the Understanding document that the the page author really only has two choices: Warn at the beginning of an authenticated session of any time-out constraints, OR, provide a means to partially save forms. In a perfect world, we'd get both.
 
 
    
 
 
   Thoughts?
 
 JF
 
 
 
   
  On Tue, Nov 28, 2017 at 2:00 PM, EA Draffan <ead@ecs.soton.ac.uk> wrote:
    I have to agree if there are constant reminders they will tend to exasperate the problem rather than solve it.   It could turn into a situation of more haste - less speed with an increased number of errors occurring. 
  
  Best wishes
 E.A. 
  
 Mrs E.A. Draffan
 WAIS, ECS , University of Southampton
 Mobile +44 (0)7976 289103
 https://www.outlook.soton.ac.uk/owa/redir.aspx?C=69b1RzNTDwem3wbm4pLRmuYfTLt16YjcghtEpZBsF5Sebx78I2DUCA..&URL=http%3a%2f%2faccess.ecs.soton.ac.uk%2f
 UK AAATE rep https://www.outlook.soton.ac.uk/owa/redir.aspx?C=WUwOCw_4FszLSzcUbkoFdDkad8-Q_GrRfPYUJ_ol5l2ebx78I2DUCA..&URL=http%3a%2f%2fwww.aaate.net%2f
 
  
   From: lisa.seeman [mailto:lisa.seeman@zoho.com] 
 Sent: 28 November 2017 19:11
 To: Milliken <neil.milliken@atos.net>
 Cc: John Foliot <john.foliot@deque.com>; public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>; Bradley Montgomery <rbradley@mitre.org>
 Subject: RE: timeouts
 
 
    
   Does anyone think it is better to just not have this SC at all then have it with the proposed wording?
 
   
 
   
  All the best
 
 Lisa Seeman
 
 LinkedIn, Twitter
 
  
   
 ---- On Tue, 28 Nov 2017 14:43:07 +0200 Milliken<neil.milliken@atos.net> wrote ---- 
 
    I agree that the revised proposal is likely to cause greater stress.  The warning should be frontloaded if we want people to be sure that they can participate before starting and abandoning the process.
  
  Kind regards,
  
 Neil Milliken
 Head of Accessibility & Digital Inclusion
 Atos 
 T: +442036180957 
 M: 07812325386
 E: Neil.Milliken@atos.net
 www: http://atos.net/iux 
 Twitter:@neilmilliken
 Assistant Monika Tomczak 
 E: Monika.Tomczak@atos.net
 M: +48517727304 
  
 
  
   From: lisa.seeman [mailto:lisa.seeman@zoho.com] 
 Sent: Monday, November 27, 2017 8:25 PM
 To: lisa.seeman <lisa.seeman@zoho.com>
 Cc: John Foliot <john.foliot@deque.com>; public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>; Bradley Montgomery <rbradley@mitre.org>
 Subject: Re: timeouts
 
 
  
    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
 
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
  
 
 
 
 
   
 
  
 
 
 
 
 Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading names used by the Atos group. The following trading entities are registered in England and Wales: Atos IT Services UK Limited (registered number 01245534), Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud Company Limited (registration number 08011902). The registered office for each is at 4 Triton Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983. 
 
 This e-mail and the documents attached are confidential and intended solely for the addressee, and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email.
 
   
 
  
 
 
 
 
 
 
  
 
 
 
   
 
 -- 
                  John Foliot
 
 
 Principal Accessibility Strategist
 
 Deque Systems Inc.
 
 john.foliot@deque.com
 
 
   
 
  Advancing the mission of digital accessibility and inclusion
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Received on Wednesday, 29 November 2017 06:20:20 UTC