RE: Follow up from the meeting on Issue 14: timeouts

This is a pretty substantial change to the proposal, I’ll try to unpack it some.
[Steve] In language perhaps, but the idea is the same and I tried to address various concerns.

You are suggesting:

  1.  that we need to indicate not only the duration of the time limit, but also what type of time limit (inactivity vs. set amount of time starting immediately).
     *   AWK: this seems possible to incorporate, I think that this has been mentioned before but didn’t get in
[Steve] Yes, all it says now is “about the time limit”… well, what about it?  Seems reasonable that the 2 important pieces are the length and what I’m actually being timed on.


  1.  that the amount of time remaining needs to be continuously displayed/updated
     *   AWK: I feel like this is a “nice to have” but might also be a distraction for the user, and certainly will often be scrolled off-screen for long forms. Is this necessary?
[Steve] No, it is just one of the options.  I’d expect the vast majority of developers to implement the first option which is much simpler.  But for complicated timings or as an alternative, displaying the countdown may work better.


  1.  that if there is a time limit that is not set by the content that the user needs to be advised of that also
     *   AWK: I think that this is out of scope since the unknown time limits won’t be set by the content.
[Steve] No, the SC starts by saying limits “set by the content” just like every other proposal.  The author always will know if they are applying a time limit, otherwise how can it be applied?  What they may not know is the length.


  1.  that if the time limit is long that no notification is needed
     *   AWK: This is different from the current “save the data” approach for 24 hours. I could go along with this but it needs to match 2.2.1 (by changing one or the other)
[Steve] I agree and didn’t like it either… maybe I just don’t understand what the 24 hour exception is supposed to absolve the author of doing.  So it’s okay to time me out without telling me so long as you keep my data for 24 hours?  I certainly don’t read it that way.

AWK


I have to agree with Andrew here and go a slight step further.  The criterion is about notification of timers and not about manipulating them, so any full exception needs to make the case that users can neither be notified of the limit length nor the scope of its existence.  Not warning users of the length of a limit is one thing, but not notifying them of its presence and effect is another.  Real-time events can be excluded from 2.2.1 because time cannot be extended, but far from all real-time events have unknown limits and I fail to see a case where the author wouldn’t know it exists.  Going back to my suggestion, we might exclude cases where the actual time is unknown as follows:

Timing Notification: For each time limit that is set by the content, at least one of the following is true:

·       On Change: the user is advised at the start of the process about the length and scope of the timer, and additional notifications are provided whenever the timer is changed (e.g. reset, paused, or time is added or subtracted).

·       Continuous: the user is advised at the start of the process about the length and scope of the timer, and the time remaining is continuously displayed throughout the process and is updated in at least 1 minute intervals.

·       Unknown Length: The time length is unknown, and the user is advised at the start of the process about the scope of the timer.

·       24 Hour Exception: The time limit is longer than 24 hours.

Again, the final exception seems to be a bit petty and miss the point of the criterion to provide notification, but if it’s necessary then that should cover it.

Steve

From: Andrew Kirkpatrick [mailto:akirkpat@adobe.com]
Sent: Friday, May 12, 2017 10:31 AM
To: White, Jason J <jjwhite@ets.org<mailto:jjwhite@ets.org>>; Gregg C Vanderheiden <greggvan@umd.edu<mailto:greggvan@umd.edu>>; Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>
Cc: David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>>; Katie Haritos-Shea <ryladog@gmail.com<mailto:ryladog@gmail.com>>; w3c-waI-gl@w3. org <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: Follow up from the meeting on Issue 14: timeouts

As a further follow-up, my goal (in addition to getting good SC through) is to keep the language as tight and clean as possible. For 2.2.1 in the understanding document we have:

"In an auction, there is a time limit on the amount of time a user has to submit a bid. Since the time limit applies to all users who want to bid on a particular item, it would be unfair to extend the time limit for any one particular user. Therefore, a time limit is required for this type of activity and no extension, adjustment, or deactivation of the time limit is required by this Success Criteria.”

For the new SC, if this same situation came up, we would want to convey the limit and if we put in the exception then it won’t be necessary to do so, and I think that is not what the intent of the SC is.

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe

akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fawkawk&data=02%7C01%7C%7Cff4c992fc1ea45dc2c8d08d499558af5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636302040074071175&sdata=2m5jwsr8p4n01eo2yfOeQNJAZkBRYKvCr4qHci%2B4elU%3D&reserved=0>

From: Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>>
Date: Friday, May 12, 2017 at 10:18
To: "White, Jason J" <jjwhite@ets.org<mailto:jjwhite@ets.org>>, Gregg Vanderheiden <greggvan@umd.edu<mailto:greggvan@umd.edu>>, Stefan Schnabel <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>
Cc: David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>>, Katie GMAIL <ryladog@gmail.com<mailto:ryladog@gmail.com>>, WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: Follow up from the meeting on Issue 14: timeouts
Resent-From: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Resent-Date: Friday, May 12, 2017 at 10:19

[Jason] 2.2.1 uses the phrase “time limit that is set by the content”. Real-time events and “essential” exceptions are then handled as exceptions (i.e., special cases). This treatment makes it clear that such cases are indeed instances of “time limits set by the content” as this phrase is used in WCAG, contrary to your assertion above.
If you want to exclude them from any proposal, it has to be done explicitly.

The difference is that 2.2.1 is about adjusting the timing for a limit, and there are three exceptions for making that happen – one is that the limit is essential, another is that the limit is long (more than 20 hours), and finally if it is part of the real-time event. It feels very "chicken and egg”-ish to me – are the time limits for a real-time event set by the web site or by the (for example) auctioneer? I suppose theoretically a time-limit for a real-time event could be controlled by a web site, but then the time limit is known by the web site and can be communicated. If the limit is based on seat availability and how many other people in the world buy tickets, then that is real time but not controlled by the content.

If it made people more comfortable I wouldn’t have a concern about adding:

Time Limits: For each time limit set by the content where user-entered data can be lost, the user is advised about the length of the time limit at the start of the process, unless any user-entered data is preserved for at least 24 hours after the limit is reached.

·       Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and the length of the time limit is not known.

How’s that sound?
AWK