Re: How can we effectively evaluate failures of SC 2.1.1 Timing Adjustable on a large number of pages?

Hi Peter,

We grappled with this problem when operationalising SC 2.2.1 into a test step and came up with this (which I translate quickly from German without making sure that the terms are exactly those used in relevant WCAG techniques:)


[1. Applicability of checkpoint]
(...)
[2. Check]
[2.1 Check for auto-refresh]
(...)
[2.2 Check for auto-forwarding]
(...)

2.3. Check whether time limits can be turned off or extended

2.3.1. Case A: The time limit is displayed

Pages with transactions can show time limits in different ways:

• The remaining time span (session duration) of a transaction is displayed. Each interaction automatically re-sets the session duration.
• In time before the expiry of the session, a dialogue to extend the time limit appears
• a control element allows the user to turn off or extend the time limit. Users have sufficient time to find the control element before the expiry of the time limit.


2.3.2. Case B: The time limit is not immediately displayed

In cases where it can be expected that a transaction offered on the page has a time limit, but there is no time limit displayed and no control element to turn off / extend the time limit:

• Open pages with transactions that typically have a limited session duration (e.g., online banking, online payments) in a browser that is currently not used for evaluation and put in data.
• Don't use that browser for 20 minutes.
• Check after 20 minutes if the page is still available and data can be submitted successfully
• If after 20 mins the page is found to notify the user that the transaction has expired and the session has been terminated, reload page and wait to check whether a dialogue appears that offers *before* the expiry (with sufficient time avaiable, at least 20 secs) an option to extend the time limit

3. Hints
3.1 This checkpoint only applies to time limits caused by the page content (server-side as well as client-side). External time limits, for example those caused by user agents, are outside the scope of influence of the page author and therefore are not subject of this evaluation.

3.2 If pages have time limits can often not be gleaned from the source code of the page - a time limit may be set by the server.


On 15 Jun 2013, at 01:25, Peter Korn wrote:

> Hi gang,
> 
> I recently encountered a page that had a multi-hour timeout, whose timeout wasn't adjustable, couldn't be turned off by the user, wasn't real-time, and was less than 20 hours.  I'm hard pressed to say the timeout was "essential".  But basically, after a few hours of logging into to this site, without warning, the user was logged out.
> 
> This appears to me to be a technical violation of SC 2.2.1 Timing Adjustable.
> 
> First off, I'm curious if my colleagues on this mailing list agree that this is a violation of SC 2.2.1.  
> 
> Second off - and assuming you read it as a violation - I'm curious how SC 2.2.1 can be effectively tested on a large site.  If you decide that the appropriate sample size for a large site is 50 pages, does that mean we could potentially need to spend up to 1,000 hours to test the site just for this SC?  (that's 125 person-days, and doesn't deal with the fact that you might need a human being to discern when the change happened, or are there tools for this we can use?)
> 
> 
> Peter
> -- 
> <oracle_sig_logo.gif>
> Peter Korn | Accessibility Principal
> Phone: +1 650 5069522 
> 500 Oracle Parkway | Redwood City, CA 94064 
> <green-for-email-sig_0.gif> Oracle is committed to developing practices and products that help protect the environment

-- 
Detlev Fischer
testkreis - das Accessibility-Team von feld.wald.wiese
c/o feld.wald.wiese
Thedestraße 2
22767 Hamburg

Tel   +49 (0)40 439 10 68-3
Mobil +49 (0)1577 170 73 84
Fax   +49 (0)40 439 10 68-5

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites

Received on Sunday, 16 June 2013 07:37:12 UTC