RE: 2.2.6 Timeouts versus 2.2.1 Timing Adjustable

Michael,

I went through 2.2.1 and 2.2.6 after the call on Tuesday as well.  I agree your assessment of the value of 2.2.6. In particular the post-TPAC wording which was lost about notifying a user before they start an activity is a key value. It is not explicit in the current wording but is captured in the understanding document.

One question from the call was for an example that passes 2.2.1 but fail 2.2.6.  Sites that have a real time exception or essential exception but fail to notify the user of the time limit of inactivity would be one example of this.  While it is a bit of a stretch, I would argue Xoom falls into this category (at least it did a few months ago). If you want to use it to send money overseas, you have 48 hours to verify your bank account or credit card based on US regulations. This is a real time exception so passes 2.2.1. You have to send the most current account statement within that time but you are not warned of this time limit.  If you do not act before the time limit expires, all future transactions will be cancelled with no opportunity to correct the mistake.  It is a stretch because 1) technically your data is retained but it becomes obsolete since it can’t be used and 2) 48 hours is a much longer inactivity time than we typically expect though the task is a more difficult one than typically is needed.

Because of the importance of knowing about a time limit be before investing time and because the understanding documents still explain the intent of the SC as notifying the user beforehand, I would support a wording change to better capture the intent behind 2.2.6. That said, I do not have a suggested wording and recognize the current wording is the best consensus we could come up with after hours of discussion. I would rather have it included in 2.1 with the benefits Michael outlines than not included.

Best regards,

Rachael

From: Michael Gower [mailto:michael.gower@ca.ibm.com]
Sent: Tuesday, February 27, 2018 4:32 PM
To: w3c-wai-gl@w3.org
Cc: Lisa Seeman-Kestenbaum <lisa.seeman@zoho.com>; Bradley Montgomery, Rachael L. <rbradley@mitre.org>
Subject: 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 whenusers 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<https://www.w3.org/TR/WCAG21/#dfn-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<https://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-required-behaviors.html#essentialdef> 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<mailto:gowerm@ca.ibm.com>
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034



From:        Katie Haritos-Shea <ryladog@gmail.com<mailto:ryladog@gmail.com>>
To:        Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>
Cc:        "lisa.seeman" <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>>, John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>>, WCAG <w3c-wai-gl@w3.org<mailto: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<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.accessibilityassociation.org_cpwacertificants&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc&m=m0AlEbCXHzai0lGYWCK6JKumMNh2zfoSbISBqLsEikM&s=Wg2VlOFA8D8HG9XOsH8R5SOYcDGqy24R8aGy0RelPxg&e=>

Cell: 703-371-5545<tel:703-371-5545> | ryladog@gmail.com<mailto:ryladog@gmail.com> | Oakton, VA | LinkedIn Profile<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in_katieharitosshea_&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc&m=m0AlEbCXHzai0lGYWCK6JKumMNh2zfoSbISBqLsEikM&s=biuOXYOZ0Pg64hwrwDlrkhPfuXBz3calLfSpMyc1JyI&e=>


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<mailto: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<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.accessibilityassociation.org_cpwacertificants&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc&m=m0AlEbCXHzai0lGYWCK6JKumMNh2zfoSbISBqLsEikM&s=Wg2VlOFA8D8HG9XOsH8R5SOYcDGqy24R8aGy0RelPxg&e=>

Cell: 703-371-5545<tel:703-371-5545> | ryladog@gmail.com<mailto:ryladog@gmail.com> | Oakton, VA | LinkedIn Profile<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in_katieharitosshea_&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc&m=m0AlEbCXHzai0lGYWCK6JKumMNh2zfoSbISBqLsEikM&s=biuOXYOZ0Pg64hwrwDlrkhPfuXBz3calLfSpMyc1JyI&e=>


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<mailto: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