Re: timeouts

Hi Rachel,

I'm not opposed to that editorial addition. It may however introduce some
confusion about the existing SC I referenced previously, which explicitly
allows for up-to 10 Session extensions, and the only way you can extend the
session is to be advised that you have to do so (which will entail a
"warning" or alert of some kind).

As long as it is clear that we're talking about 2 different types of
warnings, then sure, let's propose it.

JF

On Wed, Nov 29, 2017 at 7:58 AM, Bradley Montgomery, Rachael L. <
rbradley@mitre.org> wrote:

> Would adding something to indicate a single warning resolve this? So
> wording like the following:
>
> * Where data can be lost due to user inactivity, users are warned once,
> 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.*
>
>
>
>
>
> *From:* lisa.seeman [mailto:lisa.seeman@zoho.com]
> *Sent:* Wednesday, November 29, 2017 1:20 AM
> *To:* Bradley Montgomery, Rachael L. <rbradley@mitre.org>
> *Cc:* John Foliot <john.foliot@deque.com>; EA Draffan <ead@ecs.soton.ac.uk>;
> Milliken <neil.milliken@atos.net>; public-cognitive-a11y-tf <
> public-cognitive-a11y-tf@w3.org>
> *Subject:* 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 <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 <+44%207976%20289103>
>
> 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>*>* 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
>
>
>
>
>



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

Advancing the mission of digital accessibility and inclusion