W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2017

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

From: Andrew Kirkpatrick <akirkpat@adobe.com>
Date: Fri, 12 May 2017 14:31:18 +0000
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>
Message-ID: <FED19303-E01B-4A1F-A70B-B8311810D9E0@adobe.com>
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.


Andrew Kirkpatrick
Group Product Manager, Accessibility


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?

Received on Friday, 12 May 2017 14:32:01 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:13 UTC