2.2.6 Timeouts versus 2.2.1 Timing Adjustable

I said I'd look into possible editorial changes to 2.2.6 to help contrast 
between it and the pre-existing 2.2.1, since the new one is difficult to 
differentiate.

The problem I'm finding with my testing is that there is no stricture in 
2.2.6 about when users are warned. So if authors meet 2.2.1 through 
"Extend", all they need do to meet 2.2.6 is to include the time remaining 
in the warning, and both SCs seem to be covered.

However, there are some differences between the two SCs, which still make 
the SC valuable:
1) The real-time and essential exceptions which exist in 2.2.1 do not 
exist in 2.2.6. Therefore, while it is possible to entirely bypass 2.2.1's 
turn off/adjust/extend requirements, 2.2.6 still requires a user be warned 
of data loss due to inactivity. This means that where business rules 
requiring a time-out could in 2.2.1 effectively result in a user losing 
data with no warning at all, 2.2.6 will now require the user to be warned 
in some way.
2) As mentioned, 2.2.6 requires the warning include the duration of user 
inactivity.  If any of the first three 2.2.1 options are used to meet the 
SC, they would each require a clear conveyance of duration to meet 2.2.6. 
So at the least vague terms such as "you are about to run out of time..." 
should be replaced by concrete information, such as "Your session will end 
in 5 minutes..."

Finally, there are also some meaningful philosophical differences between 
the two that can be covered in an Understanding document. I believe best 
practices can promote that the user should be warned before (or at the 
time) each timer is set, and that saving data needs to be discrete where 
multiple timers are imposed in a process. The current draft of the 
Understanding doc touches on this already to some degree.
Post-TPAC language produced the following wording.

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.

I have cc'ed Lisa, who objected to this phrase at the time of its 
rejection, and Rachael who managed the SC, to ensure they are aware of 
this discussion that their concerns are captured as part of the best 
practice wording.

For background, the wording of the two SCs are below.

2.2.6: 
Users are warned of the duration of any user inactivity that could cause 
data loss, unless the data is preserved for more than 20 hours when the 
user does not take any actions. 

2.2.1
For each time limit that is set by the content, at least one of the 
following is true: (Level A) 
Turn off: The user is allowed to turn off the time limit before 
encountering it; or 
Adjust: The user is allowed to adjust the time limit before encountering 
it over a wide range that is at least ten times the length of the default 
setting; or
Extend: The user is warned before time expires and given at least 20 
seconds to extend the time limit with a simple action (for example, "press 
the space bar"), and the user is allowed to extend the time limit at least 
ten times; or
Real-time Exception: The time limit is a required part of a real-time 
event (for example, an auction), and no alternative to the time limit is 
possible; or
Essential Exception: The time limit is essential and extending it would 
invalidate the activity; or 
20 Hour Exception: The time limit is longer than 20 hours. 



Michael Gower
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034



From:   Katie Haritos-Shea <ryladog@gmail.com>
To:     Alastair Campbell <acampbell@nomensa.com>
Cc:     "lisa.seeman" <lisa.seeman@zoho.com>, John Foliot 
<john.foliot@deque.com>, WCAG <w3c-wai-gl@w3.org>
Date:   2018-02-23 05:15 PM
Subject:        Re: SC 1.3.4 - to keep or not?



Typo in my email back several cycles:

I wrote:  
The COGA minutes seemed to say that 1.3.4 does not help personalization, 
so that SC should be identified as doing so.

It should have been:  
The COGA minutes seemed to say that 1.3.4 does not help personalization, 
so that SC should NOT be identified as doing so.

Thanks!









* katie * 
Katie Haritos-Shea 
Principal ICT Accessibility Architect 
WCAG/Section 508/ADA/AODA/QA/FinServ/FinTech/Privacy, IAAP CPACC+WAS = 
CPWA
Cell: 703-371-5545 | ryladog@gmail.com | Oakton, VA | LinkedIn Profile

People may forget exactly what it was that you said or did, 
but people will never forget how you made them feel.......

Our scars remind us of where we have been........they do not have to 
dictate where we are going.

On Fri, Feb 23, 2018 at 8:09 PM, Katie Haritos-Shea <ryladog@gmail.com> 
wrote:
Alastair,

Bottom line: I think you may be right....:-)

I am just concerned that we remain vigilant about the why, and keep that 
focus on the user need meant to be 
 addressed by this SC now....

* katie * 
Katie Haritos-Shea 
Principal ICT Accessibility Architect 
WCAG/Section 508/ADA/AODA/QA/FinServ/FinTech/Privacy, IAAP CPACC+WAS = 
CPWA
Cell: 703-371-5545 | ryladog@gmail.com | Oakton, VA | LinkedIn Profile

People may forget exactly what it was that you said or did, 
but people will never forget how you made them feel.......

Our scars remind us of where we have been........they do not have to 
dictate where we are going.

On Fri, Feb 23, 2018 at 12:31 PM, Alastair Campbell <acampbell@nomensa.com
> wrote:
> The context of use and necessity of this SC is very different - and 
therefore this should be rethought with that user context in mind. 
 
Only if the requirement for the content is different, in this case the 
requirement is the same (programmatic association for particular inputs).
 
 
> At the very least 'the meaning of' should be removed from the stem.
 
But that is what is needed to fulfil the requirement when specifying it in 
as technology-agnostic way as possible. (Which is admittedly difficult in 
this example due to the reliance on the HTML5 spec.)
 
 
> The text of the SC should reflect the intention of the requirement - 
that is, to assist users in populating commonly used form input data.
 
In which case we need to overhaul the rest of WCAG! Where (in the SC text) 
does 1.3.1 talk about headings? Or 1.1.1 talk about being able to see 
images? Or 2.1.1 talk about switch access? That info goes in the 
understanding doc.
 
Bottom line: If we were sitting down to start this SC from scratch, I 
think we’d get to the same place because that is the requirement for the 
content.
 
Cheers,
 
-Alastair