Re: timeouts

Hi Lisa,

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


​I think that this would be an uncontroversial ask.

*However*... most sites today will offer a pop-up warning if you are at
your desktop and inactive before they close the session​. This is in fact
already a requirement of WCAG 2.0:

*2.2.1 Timing Adjustable:* For each time limit that is set by the content,
at least one of the following is true: (Level A)


   - *Extend: *The user is warned before time expires and given at least 20
   seconds to extend the time limit with a simple action (for example, "press
   the space bar"), and the user is allowed to extend the time limit at least
   ten times;

​Imagine then... if you are sitting at your desk, working on a form, and
the system detects the programmed amount of time of *user inactivity*, it
will offer you that exception. If you accept that offer to extend your
session, *and then do no more actions*, then yes, after a specific period
of time, the inaction warning will re-appear. There is a specific and
linked relationship here between the user and the site, one that the user
initiated by logging onto the server to begin with.

So... the Failure Technique would need to be clear that sites must avoid
repeated warnings of a timeout period while the user is *actively engaged
in filling out the form* (and thus would be distracted), but if you are not
at your desk when the "Extend" warning appears, or the end user constantly
extends their session but does no other activity, then that is out of
scope, as the current SC already allows for up-to 10 "Extend" warnings.

JF

On Wed, Nov 29, 2017 at 12:19 AM, lisa.seeman <lisa.seeman@zoho.com> wrote:

> 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 <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>
>
> ---- On Wed, 29 Nov 2017 02:53:23 +0200 * Bradley
> Montgomery<rbradley@mitre.org <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 <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>
>
> ---- On Tue, 28 Nov 2017 14:43:07 +0200 *Milliken<*
> <neil.milliken@atos.net>*neil.milliken@atos.net <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 <https://twitter.com/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 <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
>
>
>
>
>
>
>
>
>
> 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
>
>
>
>


-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion