Monitoring the Accessibility of Your 404 and Error Pages

Your 404 and server error pages need the same treatment as any other page: a real heading that says what happened, a search box and links back to the store, and no keyboard traps. Add them to the monitoring schedule, because a broken link is how most shoppers meet them.

The page your audit skips

Every accessibility audit starts at the homepage, walks the product pages, and ends at checkout. The 404 page never makes the list, because nobody plans to visit it. But shoppers land on it constantly: a mistyped URL, a deleted product, a link from an old email, a search result that points at a page you removed last season. A screen reader user who lands on a 404 with no heading hears the navigation, then silence, then the footer. There is no announcement that the page does not exist, no search box to try again, and no link back to anything useful. They leave, and your analytics records a bounce, not a barrier.

The fix is not a redesign. It is a checklist applied to a page that already exists: one H1 that says the page was not found, in plain words; a search field with a real label; links to the homepage, the main collections, and contact; and the same header, footer, and skip link as every other page. That is a morning of work, and it turns a dead end into a recovery path.

Why this belongs in monitoring, not in a one-off audit

Error pages drift more than any other page, because they are built once and forgotten. A theme update replaces the 404 template and drops the heading. A redesign changes the navigation and the error page keeps the old one. A new app injects a script that traps focus on the search box. None of that shows up in the weekly scan, because the scan checks the URLs in the sitemap, and a 404 is by definition not in the sitemap.

So monitor it directly. Once a month, request a URL that does not exist and run the same checks you run everywhere else: heading structure, labels, keyboard path, contrast, and whether the skip link works. Alert on any regression the same way you would for the homepage. The cost is one scheduled check. The return is that the shoppers who arrive by mistake, the ones already frustrated, are not met by a page that gives them nothing to do next. The monitoring side of this is where to set the Axe threshold in CI and the focus order your scanner misses in single-page apps.

Frequently asked questions

What should a 404 page contain for accessibility?

One H1 that says the page was not found, a labeled search field, links to the homepage and main collections, and the same header, footer, and skip link as the rest of the site. That is the whole list.

Why is a 404 an accessibility problem and not just bad UX?

Because a screen reader user who lands on a page with no heading and no way forward cannot tell what happened or what to do next. The barrier is the missing information, and it hits assistive technology users hardest.

How do you monitor a page that is not in the sitemap?

Request a URL that does not exist on purpose, once a month, and run the same checks as any other page: headings, labels, keyboard path, contrast. The check is a scheduled request, not a crawl.

Our 404 is a joke page with a funny image. Is that a problem?

Only if the joke replaces the information. Keep the humor, but keep the H1, the search box, and the links. A funny dead end is still a dead end.