Re: meta refresh (3.7.5.3. Pragma directives)

I would like the editors to consult with WCAG when they review this
part of the specification.

I'd personally prefer meta@refresh be deprecated. In my work I'm bound
by WCAG so it essentially is deprecated (for me) anyway (and maybe
many of you feel that is sufficient - it isn't, imo). I'd prefer HTML
5 be aligned with WCAG (it almost always is). In lieu of this, a
simple acknowledgement would go a long way: how about a Note
referencing WCAG checkpoints 7.4 and 7.5. (I still think a more
well-rounded outcome will come from consulting the WCAG group. They
wrote the accessibility guidelines so they'll know more about it than
I do!)


In regards to all the comments … meta@refresh doesn't impact me
personally as a user. Authoring is a different matter, and if you were
doing any work for me I would make you replace such functionality with
HTTP 3xx redirections or 410 Gone messages (with a link to the new
content in the HTML), with no timed redirection. That's me (and others
like me who are bound by - or choose to comply with  - WCAG). I don't
pretend this represents the views of the entire world.



On 8/8/07, Jason White <jason@jasonjgw.net> wrote:
>
> 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 09:06:56 UTC