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 <+44%207976%20289103>
>
> http://access.ecs.soton.ac.uk
> <https://www.outlook.soton.ac.uk/owa/redir.aspx?C=69b1RzNTDwem3wbm4pLRmuYfTLt16YjcghtEpZBsF5Sebx78I2DUCA..&URL=http%3a%2f%2faccess.ecs.soton.ac.uk%2f>
>
> UK AAATE rep http://www.aaate.net/
> <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>*>* 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 <+44%2020%203618%200957>
>
> 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 <+48%20517%20727%20304>
>
>
>
>
>
> *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