RE: refresh

We should be conerned that .NET causes a lot of page refreshes. While
this can provide improved functionality to some users, it can be
disorienting to others. Features such as stock tickers, sports tickers,
and chat use constant refresh. Without some kind of warning, the user
has no idea why the voice browser is repeating the top of the page
(other than from previous bad experiences).

Accessible chat programs allow the user to stop the refresh, and to
manually activate the refresh when desired. To me, this is a reasonable
equivalent to 'real time' chat.

I believe that authors bear the responsiblity to provide a mechanism
where the user can turn off and control page refresh, or provide a
non-refreshing alternative.

As for redirects, a voice browser can still be reading a previous page
after the redirect occurs. The original page should warn the user that
they are being redirected. Whether the redirect is fast or slow I think
is incidental. Visual users 'know' where they are going. Non-visual
users deserve the same consideration.

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 9:14 PM
To: Chris Brainerd
Cc: seeman@netvision.net.il; w3c-wai-gl@w3.org
Subject: 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 21:46:12 UTC