HTTP status messages tell the user what happened when their computer tried to connect to the web server. Generally, the user never sees these status messages because generally, whatever is supposed to happen, does.
On occasion though the server may respond back with a message that the user cannot access whatever they were looking for.
If the assumption is that the client (either the user themselves or their machine) caused the error, then the message is one of a numbered set in the 400 range. Of these, HTTP 404 (file not found) is the most well-known. HTTP 418 (I’m a teapot), however, remains the funniest.
If the assumption is that the server failed to handle a request that appeared to be valid, the message is one of a numbered set in the 500 range. Examples include situations where the server is likely overloaded (503), the server failed to get a response from the server it needed information from in a timely manner (504) and the dreaded “internal server error” (500) which stands in for every type of error that doesn’t have its own code.
Why this is important
Users are very likely to come across at least one type of error message during their time using the internet, and how well a site handles them says more about the site’s service to its users than the error message writers might intend.
For example, it has become quite popular to make cute, funny, or interactive 404 error messages. The user is most likely to invoke a 404 message by typing in a URL incorrectly — although these days with the ubiquity of Google search and others, it may not be that the user typed in the bad url, but that they followed a link to a page that no longer exists.
When you’re looking for information, especially if you are “just following a link” and didn’t cause the 404 error yourself, you want to know what happened and how to get back to the information you were looking for. The best thing that a web designer can do is ensure that the user does exactly that, by going to the homepage or a related page, or possibly by visiting one of a set of suggested links.
They do not generally want to see something obnoxious, cute, sarcastic, or interactive. They’re on a mission to do something, after all, and your 404 message was never on the list of things to do.
All of the accessibility rules that apply to other pages also apply to your HTTP errors. Users need to know what to do when they encounter an error.
Use when…
- HTTP error message pages should be used for HTTP errors and not other errors.
Do not use when…
- The error is at the page level or field level. Use Page-level validation and error messaging or Field-level validation and error messaging respectively.
- The error is not an HTTP error. While you can follow similar best practices for other server errors, make sure that the user can easily tell the cause of the error and what to do about it.
Examples and counter-examples
How to make an ineffective 404 page by Eric W. Bailey explains a scenario that he experienced working on the Boston.com website.
In that article, Eric explains what a good 404 page does for the user, in clear and simple language.
He also describes the consequences that befell Boston.com when they chose not to implement a good 404 page and opted for a “funny” one instead.
Learn from Boston.com’s example.
How to create a usable and accessible HTTP error page
Use clear, concise language.
Most users on most sites don’t know what a 404 error is or what they should do about it. They don’t know if they’re to blame or how to avoid them in the future. Use context that will address the problem accurately and try to keep it to a single sentence.
Ensure that the message is noticeable.
A single sentence in the top left corner of the page that says “An error has occurred. Go back to the home page.” is likely to be missed by the user or mistaken as posted in error itself. It could even be mistaken as a phishing attack or similar security problem.
Using larger type and imagery to attract the user’s attention. Make it clear that the imagery and message aligns with the website brand. This can help reassure users that they are still on your website and not in danger.
Provide the users a clear call to action.
Unless the user really did make a spelling error while typing in a URL, there’s a really good chance the user can’t do anything to fix the underlying problem that causes an HTTP error.
Ensure that the error message tells the user what to do next. For HTTP 404 messages, this could be an invitation to use a search field on the page that searches site content, or a list of links related to the page they thought they were going to.
For 500 errors or other types of 400 range errors, you may instruct the user to try again later or contact support (with a link to how to contact support).