W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2006

RE: User friendly 404s reconsidered

From: Patrick H. Lauke <redux@splintered.co.uk>
Date: Thu, 20 Jul 2006 11:36:57 +0100
Message-ID: <20060720113657.k3j5ecptdligo4ok@www.splintered.co.uk>
To: Jesper Tverskov <jesper@tverskov.dk>
Cc: w3c-wai-ig@w3.org

Quoting Jesper Tverskov <jesper@tverskov.dk>:

> If we add /vista an error message is not returned but the URL is
> automatically corrected to /windowsvista.
> This is misuse of the error message turning it into some sort of search
> engine not even notifying the user. The longer we remove ourselves from web
> server 404 defaults we get a million different concepts of what an error 404
> is supposed to be. To follow the standards just a little would do also in
> this case.

So, just to recap: 404s should never attempt to help the user actually  
achieve their goal? If an error can reasonably be corrected, the  
application should not attempt to do that, but rather give a STBU  
I'd say that when there is an *obvious* way to correct an error,  
usability would suggest that it's a good thing to actually do so. How  
do you feel about Apache's mod_speling, for instance?

And, to repeat what I wrote over on the Accessifyforum:

if you see users typing an outdated/wrong URL (or, stretching it even  
further, following a broken link i.e. feed erroneous/outdated  
information into the system that is your web server) as an "input  
error", then providing a list of possible matches or any other  
information that may help the user is actually recommended, based on  
WCAG 2 current draft

"2.5.2 If an input error is detected and suggestions for correction  
are known and can be provided without jeopardizing the security or  
purpose of the content, the suggestions are provided to the user."

Patrick H. Lauke
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
Web Standards Project (WaSP) Accessibility Task Force
Received on Thursday, 20 July 2006 10:37:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:36:28 UTC