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

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>; Gregg C Vanderheiden <greggvan@umd.edu>; Schnabel, Stefan <stefan.schnabel@sap.com>
Cc: David MacDonald <david100@sympatico.ca>; Katie Haritos-Shea <ryladog@gmail.com>; w3c-waI-gl@w3. org <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


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