RE: Redirect (Re: Request for review: updated HTML Techniques draft)

I agree with you on this.  It's not a good policy to use definitions like
"banned", after all the final document is a recommendation.  It's just not
good to shut off options if sometimes it may be the only way for someone to
manage such scenarios.

I feel it is good to clearly state the pros and cons of any particular
strategy.  I think you can also take WCAG and read it as a series of
checkpoints that will help any developer check their development strategy
for basic problems.

Just take this one example for instance.  A lot of people have third party
software working with or on top of user agents, specifically IE, and turning
off refreshes is one of the options.  Why does the average web user want
this?  Mostly to prevent URL hijacking.  It could be done on the server
side, but mostly it isn't.  Unfortunately URL redirection  has become common
practice on the clients side.  It's not a good option technically.  It is
much better to do via the server configuration or .htaccess files (which is
still the server), than with PHP scripting.

When it is done via the server the full HTTP header information is passed to
the user agent.  But PHP or server side scripting is better than client side
scripting, but still often lacks the information in the HTTP dialog between
the server and the user agent.  It can be done if you write the header
information, but not by plain redirect.

What most people fail to realise is that

* Search engine spiders will not crawl client side redirects (at least most
of them).  The get to the redirect, there was a document at that URL before,
but now that it is a clientside redirect, they generally won't follow it and
often delete the old URL from the database.  This is not a desired outcome.
* If you put in server side redirects in the server config/.htaccess you can
tell the user agent which type they are (ie Server Status codes;
301,302,303,307)
* If you tell them it is "permanent" (301) the user agent "should/is meant
to" update the URL if it is bookmarked (I know probably none of them do, but
they are meant too).  Also, a search engine will update the listing with the
new URL.
* If you manager your server properly, then the side benefit is you can move
URLs around and know that there are not going to be broken links, because
all old URLs are being redirected correctly, and you have your server config
files as a good document change log, if you are an efficient webmaster and
treat it like that.

So there is far more benefit from managing the server properly, because the
server actually tells other user agent the "real" status of that documents
URI.

Oh, yeah,  I am meant to be working on the Server Techniques Draft for
WCAG2.  I have done a fair bit of work on it, but this has prompted me to
get back in the saddle.

Geoff

-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]On Behalf
Of Jens Meiert
Sent: Friday, 24 October 2003 8:38 PM
To: w3c-wai-gl@w3.org
Subject: Redirect (Re: Request for review: updated HTML Techniques draft)


Just a remark and some thoughts again related to the redirect problem
(Uncategorized techniques: Meta redirect), although of course previously
discussed
[1]; first of all, if you think about referring to .htaccess or other
server-side redirects, don't forget to rename this issue, and maybe it's
even now
useful to simply call it 'Redirect'.

I don't agree to this flat banning of redirects since they can be used
reasonably (except related to auto-refreshing mechanisms almost causing
Usability
as well as Accessibility problems, and 'abuse' of meta elements). So I'd
prefer to recommend server-side redirects (via PHP or .htaccess) when they
are
really unavoidable (!), as it might be the case when an important resource
has
moved (I sometimes encountered this problem when having restructured a site
while there is huge traffic on it).

Normally there will be no alternative for a redirect in this case
(especially in business use), and I again rather see massive problems when
sending
users into the nirvana, since only a small amount of users will either go
ahead
and follow a link to the new file location or even take the trouble to
search
for this resource, and so they will mostly leave the site; also imagine
telling companies not to use redirects (even in sensible cases) -- that's
absolutely unrealistic (and imagine what effort it might be to create even
dynamic
pages referring to new file locations).

I don't want to protect anyone who misapplies redirect mechanisms, I only
want the WAI to offer realistic, fair, and acceptable mechanisms, rather
appealing to 'common sense' than banning everything which 'might' entail
problems.
Otherwise, if you are that convinced that redirects are absolutely
unnessecary and only causing problems, persuade Apache or PHP developers or
even the
responsible W3C working groups to chuck out all redirect opportunities.

And, last but not least, almost no user of screen reader or voice browser
technology won't even notice if he's redirected via a server-side
technology;
and do you notice it using a Web browser? Are you that struck when being
redirected (try [2])? And don't you see Usability and/or Accessibility
problems
when landing on 'Error 404' pages? -- But I'm only repeating what I said
before, so I guess you understand what this post was about to express, and I
hope
the WG will only recommend server-side redirects in cases where it's
inevitable.


All the best,
 Jens.


[1] http://lists.w3.org/Archives/Public/w3c-wai-gl/2003JulSep/0131.html
[2] http://meiert.com/lib/documentation/var/selfhtml80.zip


--
Jens Meiert
Interface Architect

http://meiert.com

Received on Saturday, 25 October 2003 15:24:27 UTC