W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2002

Re: Client-Side Redirects Using HTTP-EQUIV="refresh"

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Tue, 22 Jan 2002 09:46:38 -0600
To: "Ian B. Jacobs" <ij@w3.org>
Cc: "Matt Nuttall" <mnuttall@ca.ibm.com>, w3c-wai-ua@w3.org, w3c-wai-ua-request@w3.org
Message-ID: <OF8381D4D0.EC9AC3F0-ON86256B49.00564A55@raleigh.ibm.com>
You can provide a URL parameter to cause a browser redirect to a different
location as part of the refresh. I have seen this done on sites.


Rich Schwerdtfeger
Senior Technical Staff Member
IBM Accessibility Center
Research Division
EMail/web: schwer@us.ibm.com

"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.",

                      "Ian B. Jacobs"                                                                         
                      <ij@w3.org>              To:       Matt Nuttall/CanWest/IBM@IBMCA                       
                      Sent by:                 cc:       w3c-wai-ua@w3.org                                    
                      w3c-wai-ua-reques        Subject:  Re: Client-Side Redirects Using HTTP-EQUIV="refresh" 
                      01/22/2002 09:28                                                                        

Matt Nuttall/CanWest/IBM wrote:

> Hi Folks;
>      Sorry to be bothering you with this question, but
> I've been looking for a solution to a condition related to
> your Client-Side Redirects Using HTTP-EQUIV="refresh"
> checkpoint 3.6.

This sounds more like content refresh (3.5) than
client-side redirects (3.6).

>      Here is my problem: I use HTTP-EQUIV refresh
> constantly to refresh a page for an internal company
> website.  Since some of these users are half the world
> away, network delays/problems can cause the refresh
> to fail.
>      Here is my question: what mechanism exists
> to give the client control over the failure to refresh?

The reload button.

> Preferably so that a JavaScript alert window could be
> opened to inform the client via pop-up window that the
> refresh has failed.

Your question is related to checkpoint 3.5, but
from a different perspective. Checkpoint 3.5 is about
making the automatic refresh behavior into a manual
refresh behavior. Points 1 and 2 of checkpoint 3.5
apply. I could imagine the following behavior:

  - The user agent uses a time-out to detect failed
  - When a request fails, the user is informed, and the
    user is given the option of going to manual mode
    or leaving in automatic mode.
  - In manual mode, a persistent message lets the user
    know that manual mode is on, and the user can always
    refresh content by hand.
  - Make the alert to the user on failed GET optional,
    so the user can choose to not be bothered for each
    failure to get a resource, but auto mode continues
    to silently fail.
  - When in manual mode, let the user explicitly request
    to return to auto refresh mode.

I'm not aware of this type of explicit mechanism
available in user agents today. If you implement
this (or something similar), please let us know!
We welcome your implementation input on how you get
the best user experience.

This is an interesting question because it shows
that the ability to toggle between auto and manual
mode may have non-accessibility uses.

   - Ian

> Thanks for your time and my apologies if this question
> is inappropriate.
> Matthew E. Nuttall
> IBM Global Services
> 4601 Canada Way
> Burnaby, BC  V5G 4X3
> phone: 604-297-2336    fax: 604-297-2800
> mnuttall@ca.ibm.com

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447
Received on Tuesday, 22 January 2002 10:46:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:31 UTC