Error pages get built once, early, by whoever is nearest, and then nobody looks at them again. The person who lands on one is already frustrated, arrived by following something broken, and has no context except the page in front of them. For a screen reader user a badly built one is a dead end rather than a detour.
The Title Does the Most Work
A screen reader announces the page title on load, before the reader has done anything. That makes the title the only part of an error page guaranteed to reach somebody, and a title carrying only the site name leaves them hunting through content that is not there.
Put Page not found at the front and they know in the first two seconds. The rule underneath is 2.4.2 Page Titled, and the criterion asks for less than people assume. Titles that describe topic or purpose, and nothing about ordering. What actually tells you to put the important words first is the technique, which places the most important identifying information first and asks that the title make sense read out of context, which is precisely the situation somebody is in when they arrive here. A title that identifies nothing is its own named failure.
Say it in the heading too
The h1 should say the same thing in plain words, so somebody navigating by headings finds it. This is not our house style, it is a published technique. W3C's worked strings for a form that came back with problems are a title reading 3 Errors, Billing Address and an h1 reading the same, and the stated reason is that screen reader users benefit particularly from title updates because the feedback arrives immediately on page load.
Do Not Strand People
An error page with a graphic and an apology is a full stop. Give somebody somewhere to go.
- A search field, which in our experience is the most useful single control on a 404.
- Links to the main sections, so the page is a junction rather than a wall.
- A link to contact somebody, because the person who found the broken link is the person who can tell you about it.
- Keep the site's normal navigation. Stripping the page down leaves fewer routes out, not more.
The Other Error Pages
| Page | The thing people miss |
|---|---|
| 404 | Say so in the title, and offer search |
| 500 | Say it is us rather than them, and say whether retrying is worth it |
| 403 | Say whether signing in would help, since the reader cannot tell forbidden from not-signed-in |
| Maintenance | Say when it will be back, in words rather than in a graphic. And say when it is back |
| Empty state | Say why it is empty and what to do next |
Most of that column is content design rather than conformance, and it is worth saying which parts are which, because a report that mixes them gets argued with. The title advice is a published technique. What a 403 should say is our judgment. And the last two rows have a criterion behind them that is narrower than it first looks.
Empty States, and What the Status Rule Actually Requires
A results list with nothing in it needs to say so in text a screen reader announces, and 4.1.3 Status Messages is the criterion people cite for it. Two precisions keep that citation standing.
First, the criterion does not force you to write messages. W3C says so twice. Its purpose is not to make authors generate new status messages, only to make the ones they do show reachable. So an empty state with no message passes 4.1.3 trivially and fails the reader completely. Write the message because a page that says nothing is useless, and do not report its absence as a criterion failure.
Second, the message is the status message and the results are not. W3C draws that line explicitly, and its own worked examples are Searching, 18 results returned, and no results returned. Wrap the short sentence in a status region. Do not wrap the results container, or every result gets announced and you have built the chatty failure the criterion warns about. Five things can carry a status message, which are the HTML output element, role="status", role="alert", role="log", and aria-live set to polite or assertive, and the absence of all five is the documented failure.
There is a third case nobody handles, and the maintenance row is where it bites. A status message disappearing is itself information. A banner saying the service is down vanishes when the service comes back, and a sighted user reads the vanishing as the news while a screen reader user hears nothing, because a removal is not announced by default. Change the visible text to say it is back, or put those words in a hidden status region.
Where Focus Goes
On a full page load the browser handles it, and the title carries the message. In a single-page app the error replaces the content without a navigation, focus stays wherever it was, and nothing is announced at all.
The cheaper of the two fixes there is the one our page used to skip. Change the document title. W3C says outright that in web applications and single-page apps, titles should be changed dynamically to reflect the content of the current view, and that is one line of JavaScript that gets you the same benefit a real page load gave you for free.
Then, for the announcement, move focus to the error heading deliberately or announce it through a live region. That or is load-bearing rather than stylistic. Moving focus is a change of context, and a change of context is excluded from the definition of a status message, so a flow that moves focus needs no live region and adding one produces a double announcement. A tester expecting both will file a finding against a form that is already correct.
Whether Any of This Is Actually Required
The question owners ask is whether a 404 has to meet WCAG at all, and the reasoning matters as much as the answer, because the wrong reasoning gets knocked out.
An error page is a web page. Any conformance claim naming it has to include it, and any legal duty covering the site reaches it. The rule people reach for, that conformance is for full pages and cannot be achieved with part of a page excluded, is about not carving a region out of one page rather than about which pages a claim covers.
The rule with actual force here is a different one, and it is the one with money attached. Complete processes says that where a page is one of a series presenting a process, every page in that process has to conform at the claimed level. A payment failure page is a step in checkout. So a 500 that appears between the card details and the confirmation is not a peripheral page you forgot about, it is inside the flow your claim covers.
One honest complication. A 500 is often served by a CDN or a hosting platform rather than by your application, and the markup may genuinely not be yours. There is a statement of partial conformance for content outside an author's control, and a client will find it, so it is worth knowing what it covers before somebody leans on it. It is aimed at content you did not choose and cannot change, and an accessibility statement is the right place to be honest about it rather than quietly relying on it.
Test It Deliberately
Type a nonsense URL on your own site and listen to what a screen reader says on load. Then trigger an empty search and listen again. Both take about thirty seconds and almost nobody does either.
There is a duller reason than exhortation for testing this by hand. The status message rule has no automated test rule written for it at all, and the rules that exist for page titles check whether a title is present and non-empty rather than whether it describes anything. So a scanner will pass a 404 whose title is your company name and whose empty state says nothing.