SC2.2.6 (Timouts) should be for all websites

[michael-n-cooper]

From @guyhickling on April 9, 2018 15:33

The Timeouts SC about giving advance warning of timeouts in a data input process is at Level AAA. But it would be so helpful to users on all websites. It is a basic need of disabled users on all websites, if their disability makes it difficult to complete forms or complex processes quickly; it should not be a nice extra just on those few websites willing to go to AAA level.

There is nothing worse than being distracted from your screen temporarily and returning to find a timeout message appeared and the process was then aborted while you were away, and all your input has been lost! (True, most websites use the "Extend" option of SC2.2.1, but that is of no use if the user is distracted by something else when it appears.)

It isn't as if the development solution is difficult. Giving advance warning just asks the designer to display a single sentence of text at the start of any input process that contains a timeout. So why has it been made AAA level - is that because it was originally connected with the existing AAA SC2.2.5 on the similar subject? But the solution to that is difficult, whereas the solution to this Timeouts SC is so simple it doesn't need to be at AAA level.

Please can this SC be moved to level A so everyone (it would even help non-disabled users) can potentially benefit from it on all websites?

Copied from original issue: w3c/wcag21#855

[michael-n-cooper]

From @alastc on April 23, 2018 15:20

Hi Guy,

(Unofficial response)
In terms of timings & process, the window for changing SCs (text, scope or levels) has past.

From memory (I can ask around for more) I think it was considered AAA because it isn't always possible to do (i.e. applicability across content/sites).

If you think about online games, or even things like Facebook or Flickr the 'input' can be at pretty much any time and notifications would be overwhelming. There were lots of details to consider on this one, but that was what I remember as the sticking point - applicability.

If that aspect can be resolved/solved we could consider a new SC for 2.2. Would you be ok with this being marked as something for future versions?

[guyhickling]

Ok, to meet that difficulty maybe we maybe just need to word it to be more specific about what type of time limit we are talking about. We are targeting timeouts in a data input process (which the SC already says), and they are timeouts done for security reasons - they are always for that reason, I think, basically a security precaution to hide the data entered in the event of someone walking away from their PC and forgetting they are still logged in and mid-way in the data entry. Banks do this all the time and are the most usual situation where it happens. So if we add that into the SC that should cover it.

How about:

Users are warned of the duration of any user inactivity that could cause data loss, when the duration is limited for reasons of data security to clear the screen of data and/or log the user out of the system, unless the data is preserved.....[etc]

I would be happy for something like that to be included in 2.2 if it happens (or Silver) at Level A.

[alastc]

Ok, marked as a 2.2 thing (which is now starting).

Something to bear in mind though, every interaction which sends data back to the server is a 'data input', even clicking an image to full-screen it is then 'state' which could be lost. It is really hard to define a reasonable level to require developers to save.

[scha14]

@guyhickling considering the above comments, could we close this for consideration as part of 3.0/ Silver?

[guyhickling]

Yes, if it can be put forward for serious consideration in 3.0, that would be good. (I take it there is no likelihood now of a 2.3 release?) This really is a serious problem for disabled people, and so easy for developers to solve if the WCAG included it.

But just for the record, the last objection raised above, the idea that just clicking an image counts as data input that must be saved, doesn't count in this at all. I'm sure it is not outside our capabilities to arrive at a clear enough wording to specify that we are talking about data from input forms, where the user may have spent time entering data in fields or controls. For instance, we can revise my suggested wording above to something like:

.....that could cause loss of data, input by the user, that has not been saved.....

The secret for overcoming obstacles is not to give up each time an obstacle is encountered, but to look for ways to overcome it!

[scha14]

Thank you @guyhickling. Input forms and data loss are being considered in Silver, especially in the errors subgroup. Will close this so we can address the progress of timeouts and data loss in the context of 3.0.