- From: Jason White <jason@jasonjgw.net>
- Date: Wed, 8 Aug 2007 12:57:09 +1000
- To: public-html@w3.org
On Wed, Aug 08, 2007 at 12:29:35AM +0200, Sander Tekelenburg wrote: > The problem is that you're making an assumption about how long the user needs > to consume your advice -- yet you cannot know this as an author. (The user > may be a slow reader; may be a slow reader in your language; plenty of other > cases to imagine, when you stop to think about it.) Thus your Refresh defeats > your own stated purpose of advising the user. > > When there is a good reason for such advice, it's best to leave it to the > user to decide how quick or how slow to follow you along. Using a refresh in > such cases is like giving someone a book and dictate at what speed he must > read it. This is exactly the nature of the problem which WCAG seeks to address: people with motor, cognitive or sensory disabilities, users of voice browsers, etc., who cannot read the document quickly enough will have it changed unexpectedly as the result of the refresh, without having had an opportunity to read it in its entirety. The algorithm in section 3.7.5.1, step 22, does not allow for the possibility that refresh may be disabled entirely, that it may be presented as a link activatable by the user for example, or that a minimum time-out may have been established in the user agent's configuration. The only possibility accounted for is that the user may interactively cancel the refresh before the time-out has elapsed. For these reasons, step 22 needs to be modified so as to allow for alternative UA actions in response to refresh requests. At a minimum, step 22 should be conditional upon UA configuration parameters.
Received on Wednesday, 8 August 2007 02:57:20 UTC