Re: timeouts

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 <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>
>
> ---- On Mon, 27 Nov 2017 21:13:27 +0200 *lisa.seeman<*
> *lisa.seeman@zoho.com* <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 <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>
>
> ---- On Mon, 27 Nov 2017 20:13:53 +0200 *John
> Foliot<john.foliot@deque.com <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