RE: refresh

Sorry to chime in so late in the game, but is the issue the 'page
refresh' itself, or the lack of warning of this behavior?

A warning allows the user to take corrective action. It also informs the
user as to why the page changes, or why a voice browser keeps jumping
back to the top of the page.

We could put it upon the author to provide a non-refreshing alternative,
or a button to control refresh. Banning refresh does not appear to be
the solution.

I don't have experience as to why server-side refresh is better than
client-side? I think both can cause confusion.

Chris Brainerd
Instructional Designer
Real Choices ACCESS
Center on Disability Studies
University of Hawaii
Chris.brainerd@cds.hawaii.edu
808-956-9356


-----Original Message-----
From: Jens Meiert [mailto:jens.meiert@erde3.com] 
Sent: Monday, July 21, 2003 12:59 AM
To: lisa seeman
Cc: w3c-wai-gl@w3.org
Subject: Re: refresh



> We all totally agree that refreshing pages messes up users on 
> Assistive technologies, and that they should not have to put up with 
> it.
>  
> That is not the question and never was.

I think the most important is to find out where refresh mechanisms are
really necessary, and to clarify all situations where they may be
indispensable, from a company and private Web site to any application.

Thus I don't see any composition of prioritized refresh uses, I first
propose to create one. And maybe the result is that the WG could only
recommend a common sense and reduced use of these mechanisms, maybe it
can recommend them to be completely banned.

In my opinion (and as I wrote before), server-side redirects are
definitely more elegant than client-side redirects. But sometimes
client-side redirects are okay, too, see situations where authors have
to reference to the new document source (e.g. when a search engine links
to the old source), but don't have any server access (to e.g. configure
the .htaccess). 

By the way, I guess the refresh to shifted document versions is the most
popular use -- and even legitimate. What is more sore, to be (301)
redirected to the 'real' document, or to get a nice '404 - File Not
Found' message...? -- I prefer the first variant, regardless of which
redirect used -- I only want to get the information needed, using
assistive technologies or not. So maybe the suggested refresh listing
might be helpful.


Regards,
 Jens.



>  
> We are confusing issues hear
>  
> We all totally agree that refreshing pages messes up users on 
> Assistive technologies, and that they should not have to put up with 
> it.
>  
> That is not the question and never was.
>  
> The question is also not whether we personally like an affect or find 
> it annoying.
>  
> The question is: Where is the best place to solve this issue
>  
> Assistive technologies are already starting to address it by blocking 
> the refresh. This is easily done at the user end. Protocols could cope

> with refresh better as described in the previous email.
>  
> >From what I have seen working on the guidelines  so far,  we  try to 
> >put
> as few restrictions on the web content as we can. If we can easily 
> solve things as a user agent end we do. We are not forming guidelines 
> to help create pages that we like, or restrict the web designer when 
> we can avoid it. We try to move protocols to provide for device 
> independence and hand control of presentation and form of content to 
> the user. In this case that would imply allowing refresh for users who

> want it and functional alterative when they do not want it.
>  
> Note: Some applications need refresh (and the % does not, in my 
> opinion,
> matter) 
>  
> I request again for Michel to ping coordination on this
> 
> All the best
> 
> Lisa Seeman
> 
>  
> 
> Visit us at the UB  <http://www.ubaccess.com/> Access website
> 
> UB Access - Moving internet accessibility
> 
>  
> 
>  
> 


-- 
Jens Meiert

Steubenstr. 28
D-26123 Oldenburg

Mobil +49 (0)175 78 4146 5
Telefon +49 (0)441 99 86 147
Telefax +49 (0)89 1488 2325 91

Mail <jens@meiert.com>
Internet <http://meiert.com>

Received on Monday, 21 July 2003 18:08:56 UTC