Jul 18, 2026

The 404 Page Everyone Forgets: Making Error Screens Work for Every Visitor

Here is a page you almost certainly have on your website but have never really looked at: your 404 page. It is the screen visitors see when they click a broken link, mistype a URL, or land on a page you deleted last spring. Most business owners have never seen their own 404 page. Fewer still have thought about whether someone using a screen reader can actually recover from it.

That is a problem, because error pages are not rare edge cases. Links rot. Search engines index pages that later move. People share old URLs on social media. Marketing campaigns point to landing pages that get taken down. On a busy site, a meaningful slice of visitors hit an error page every single day. When that page fails a person with a disability, it does not just cost you a pageview — it can end their visit entirely, and in a compliance context it counts as a barrier just like any other page on your site.

The good news: error pages are one of the easiest accessibility wins there is. They are usually simple, they rarely change, and fixing them once fixes them forever. Let’s walk through what goes wrong and what “good” looks like — in plain language, no code required.

Why error pages matter more than they look

When a sighted visitor hits a 404, they glance at the screen, notice something is off, spot a “go home” link or a search box, and carry on. The whole recovery takes two seconds because their eyes do the work of scanning the page and finding the way out.

Now imagine you cannot see the screen. You clicked a link expecting a product page and instead your screen reader starts reading… something. Is this the product page? An error? A blank page? If the error page does not clearly announce that something went wrong, you may not even realise you have hit a dead end. You might sit there waiting for content that will never load, or assume the whole site is broken and leave.

This is the core accessibility failure of most error pages: they communicate the problem visually — a big “404” graphic, a sad-robot illustration, a giant number — but they do not communicate it semantically, in a way assistive technology can convey. The information is on the screen but not in the code.

There is also a legal dimension. Under the Americans with Disabilities Act (ADA) in the US and the European Accessibility Act (EAA) in the EU, the expectation is that your whole digital service is usable by people with disabilities — not just your homepage and your checkout. An error page that traps or strands a screen reader user is a genuine barrier. It is exactly the kind of thing an accessibility audit or a demand letter can flag, and it is far cheaper to fix than to defend.

What goes wrong on a typical 404 page

Before we get to the fixes, let’s name the usual suspects. If your error page has any of these, you are not alone — they are extremely common, even on otherwise polished sites.

The error is only shown as a picture or a giant number. A 300-pixel “404” rendered as an image or decorative text tells a screen reader user nothing. If the alt text is empty or the number is purely visual, the single most important fact on the page — that this is an error — is invisible.

There is no real heading. Sighted users can tell the “Oops, page not found” text is a title because it is big and bold. But if it is not marked up as an actual heading, screen reader users who navigate by headings (a very common habit) will skip right past it or never find the page’s main message.

The page dumps you somewhere with no clear way back. Some error pages strip out the normal navigation and search, leaving a lonely graphic and nothing else. For someone who cannot visually scan for an exit, a dead end with no links is a genuine trap.

Focus is lost. When a broken link loads the error page, keyboard and screen reader users often find their “cursor” (the focus point) sitting in a weird place — or nowhere at all. They have to tab blindly through the whole page to figure out where they are.

Low-contrast, cutesy design. Error pages are where brands like to get playful: light grey text on white, tiny type, a joke that only makes sense if you can see the illustration. Playful is fine; unreadable is not.

A search box with no label. Many error pages offer a search box as the escape hatch — great idea — but the box is often just a placeholder with no proper label, so a screen reader announces “edit text, blank” and the user has no idea what it is for.

What a good error page does instead

You do not need to redesign anything dramatic. An accessible error page does a handful of quiet, boring things well.

It states the problem in real text. Somewhere near the top, in actual selectable text (not baked into an image), the page should say something clear like “Page not found” or “This page doesn’t exist.” If you keep the big decorative “404” graphic, that is fine — just make sure the plain-language message exists as text too, and give the decorative graphic empty alt text so it is politely ignored by screen readers rather than read as a meaningless “404 dot png.”

It uses a proper top-level heading. The main message should be the page’s primary heading (an <h1> if you or your developer are checking the code). This does two things: screen reader users who jump between headings land right on it, and everyone gets a clear, scannable title. The heading text should describe the situation — “Page not found” beats a generic “Oops!” that means nothing out of context.

It offers clear, labelled ways out. Give people at least two escape routes: a link back to the homepage and, ideally, a working site search. Make the link text descriptive — “Return to the homepage” rather than “Click here.” If you include search, make sure the search field has a visible, persistent label (not just placeholder text) so everyone knows what it does.

It keeps your normal navigation. Unless you have a strong reason not to, leave your usual header, menu, and footer in place on the error page. Those are familiar, tested paths your visitors already know how to use. Stripping them away to make the error page “clean” removes the very tools people need to recover.

It reads clearly and meets contrast. Body text should hit the standard WCAG contrast ratio of at least 4.5 to 1 against its background. If your error page uses a faded, low-contrast “artistic” style, that is the first thing to fix. Keep the joke if you love it — just make sure the words are readable and the actual instructions are not the part you have to squint at.

It manages focus sensibly. This one is more technical, but worth raising with whoever maintains your site: when the error page loads, the keyboard focus should land somewhere logical — typically the main heading or the top of the main content — so keyboard and screen reader users are oriented immediately instead of having to hunt for where they are.

A 60-second test you can run yourself

You do not need special tools to sanity-check your error page. Here is a quick, no-code test any business owner can do today.

Find your 404 page. In your browser’s address bar, type your website address followed by a nonsense path — for example yoursite.com/this-page-does-not-exist — and hit enter. Whatever loads is your error page.
Read only the text. Ignore the graphics. Is it obvious in words that something went wrong? If the only thing telling you “error” is a picture or a giant number, that is a gap.
Try the keyboard. Put your mouse away. Press the Tab key repeatedly. Can you reach the homepage link and the search box? Does a visible outline show you where you are as you go? If focus vanishes or you cannot tell what is selected, note it.
Turn on your built-in screen reader. On a Mac, VoiceOver (Command + F5); on Windows, Narrator (Windows key + Control + Enter). Listen to your error page from the top. Does it announce that this is an error? Can you find the way out by listening alone?
Check the search box. If there is one, does your screen reader tell you it is a search field, or does it just say “edit text, blank”? A blank, unlabelled field is a fix waiting to happen.

If any step leaves you confused, imagine how it feels for someone who relies on that channel every day. Each gap you find is a small, contained fix — and because error pages rarely change, you will likely only ever have to fix them once.

The bigger point

Error pages are a tidy little microcosm of web accessibility as a whole. The failures are almost never malicious — nobody sets out to trap a screen reader user on a 404. They happen because the page communicates everything visually and no one ever checked the other channels: the text, the keyboard, the screen reader, the contrast.

That is also why they are so satisfying to fix. A few clear sentences, a real heading, labelled links and search, readable contrast, and sensible focus, and you have turned a dead end into a graceful recovery for every visitor. Do the same thinking across the rest of your site and you are most of the way to genuine compliance — with the EAA, the ADA, and, more importantly, with the actual humans trying to use your site.

So go type a nonsense URL into your own website right now. Meet the page everyone forgets. Then make it work for everyone.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.