Re: WCAG-ISSUE-42 (Timing Adjustable): Should we fail timing-adjustable when a session times out from inactivity [HTML & ARIA Techniques TF]

Hello, David and all.

For me the main problem is: how can we ensure that the user is really 
"inactive"? There are several situations where keyboard-based (or 
mouse-based) monitoring could lead to false positives:

1. The user is reading text passively. For example, a user with low 
vision or slow reading speed could invest more time reading without 
touching the keyboard or scrolling with the mouse wheel. Blind users 
might be using Ins + Down arrow shortcut in JAWS. Of course, this kind 
of things would probably happen only with long texts, but we should be 
very carefull when monitoring "activity".

2. The user is reading instructions/policies/privacy statements in a 
seaparate tab/window. Our monitoring would be unable to detect any 
keystroke or mouse activity that occurs in the new tab.

3. The user is looking for "offline" information, such as a credit card 
or a phone number, a leaflet with information of a product he wants to 
add to the shopping cart, making a call to ask a friend about the name 
of that fancy restaurant...


That said, from my experience in most situations that come from expiring 
sessions, the type of activity falls into the "essential" category 
(booking flights/hotels/tickets), or the session status can be recovered 
from a re-auteenthication or similar mechanism, which IMO would be 
enough to pass 2.2.1, since the task can be completed without depeding 
on time.

Cheers!
Ramón.


Vivienne said:

> I faced this same situation in a recent test.  Firstly, the user was not informed that inactivity would result in a time-out.  Secondly, when using the screen reader and associated keyboard controls such as tab and shift-tab to move around the page, this did not stop the time-out.  It seemed to be limited to alpha/numeric keys only.  We failed them on 2.2.1, but the client could not figure out how to deal with it as they were using telerik controls they couldn't alter.  We had suggested a modal box with a suggestion to press a numeric key, however as the user would be in a form, pressing an alpha/numeric key would cause that key stroke to be entered into the form.  User testers prefer well in excel of the 20 second warning, and users with anxiety-disorder find the whole thing of time-out warnings causes problems.  I'll be interested to hear others thoughts.
 >
>> WCAG-ISSUE-42 (Timing Adjustable): Should we fail timing-adjustable when a session times out from inactivity [HTML & ARIA Techniques TF]
>> 
>> http://www.w3.org/WAI/GL/track/issues/42
>> 
>> Raised by: David MacDonald
>> On product: HTML & ARIA Techniques TF
>> 
>> Many sites fail 2.2.1 for timing not adjustable because sessions time out without warning. For remediation, I generally suggest they provide a modal dialogue box with "do you need more time" with Yes/no buttons. However, thinking this through I'm wondering if we should perhaps provide a bit of guidance that this not be a failure in *all* situations. It is one thing to have a time limit on a task... that should have a requirement on 2.2.1.  but a time out from inactivity, perhaps should be treated differently. If the timing is measured on the back end it could be a problem because the person might be working away and the application doesn't know it, then times them out...but if the application is listening to activity in the DOM on the client side, any activity should keep the connection open...Maybe we could consider 2.2.1 met automatically if the listening is happening on the front end, and it keeps the session active as long as there is a reasonable amount of activity..
.. wondering what other think.

Received on Sunday, 23 November 2014 10:47:30 UTC