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?

I understand this as a general discussion on a refresh mechanism itself, and
I don't think it's inevitably necessary to warn users if there is a refresh
(e.g. when taken to a 'correct' URI).

> 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.

Not implicitly. Maybe he has 'two seconds' to disable JavaScript
(client-side redirect), maybe there is no possibility (and even no warning) to stop when
redirected e.g. via server-side redirect (correct me if there are reasonable
exceptions). -- I think redirects are rather an usability than an
accessibility problem, but when used with 'common sense', I've no problem with them.

> 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 fully agree, like suggested before. A WG recommendation should look like
a) normally avoid redirects, b) use them with care (preferably server-side)
when really necessary, and c) provide alternatives (e.g. via refresh/update
buttons).

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

Maybe this is rather a development advantage since they cannot be blocked
(CMIIW); and you don't need to create a special page performing the refresh. In
other words: they are definitely working. (...)

Regards,
 Jens.



> 
> 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>
> 
> 


-- 
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 Tuesday, 22 July 2003 03:14:08 UTC