RE: refresh

The lack of time to disable refresh is exactly what we can change at a
protocol level.

We can allow for a non refresh alternate and define a scope for what
content to be refreshed 

Then at a browser lever (read - user agent guidelines) we give the user
the option to always use the "no refresh"  option


Hence this is a coordination issue between WAI working groups
AT, User agents, PF and the WCAG.
 
Then WCAG would merely have "provide non refresh functional equivalents"
The user who likes refresh would get them, the user who is bothered by
refresh could always have a non refresh equivalent as a browser setting
And the Author gets freedom, flexibility and to service the disabled
community with maximum usability.

( note if the  "no -refresh" equivalent is not provided there can be a
user agent default like a button or link that reads "refresh" and
executes refresh only on user command)
All the best
Lisa Seeman
 
Visit us at the UB Access website
UB Access - Moving internet accessibility
 


-----Original Message-----
From: Jens Meiert [mailto:jens.meiert@erde3.com] 
Sent: Tuesday, July 22, 2003 9:14 AM
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 Wednesday, 23 July 2003 02:55:28 UTC