F25: When Page Titles Say Nothing at All

When Tim Berners-Lee's team drafted the earliest HTML specifications in the early 1990s, the <title> element was there from the beginning. Not as an afterthought — as a fundamental structural requirement. The web's architects understood that documents needed names. Three decades later, WCAG 2.2 Failure F25 (opens in new window) exists because we still ship pages titled "Untitled Document."

That gap between a 30-year-old design principle and current practice is worth examining carefully.

The Failure

F25 (opens in new window) describes a specific condition: a web page has a <title> element, but that title does not identify the contents or purpose of the page. The failure applies to all technologies — not just HTML. If your platform generates titles, this applies to you.

The W3C's own examples are remarkably direct. They fall into four categories:

Authoring tool defaults — titles that were never replaced:

• "Enter the title of your HTML document here"
• "Untitled Document"
• "No Title"
• "Untitled Page"
• "New Page 1"

Filenames used as titles — technically present, practically useless:

• report.html
• spk12.html

Empty or placeholder text — a <title> tag with nothing meaningful inside.

Template duplication — every page on a site carries the same title, making it impossible to distinguish one page from another.

This last pattern is particularly common in enterprise CMS deployments and government portals. A site generates pages dynamically, the template hardcodes "City of Springfield — Official Website" in the title slot, and every single page — the budget report, the permit application, the parks department contact form — announces itself identically.

The relevant success criterion is WCAG 2.4.2 Page Titled (opens in new window), a Level A requirement. Level A. The floor, not the ceiling.

Why This Matters

Page titles are the first thing a screen reader announces when a page loads. Before the user hears a single heading, before they navigate to the main content, they hear the title. For a screen reader user managing multiple browser tabs — a common workflow — the title is also how they distinguish one tab from another without navigating into each page.

When that title says "Untitled Document," the user has no orientation. They don't know if the page loaded correctly. They don't know if they're on the right page. They have to navigate into the content to establish basic context that a sighted user gets instantly from the browser tab.

For users with cognitive disabilities, clear page titles reduce cognitive load at a critical moment — the moment of arrival. A descriptive title confirms: you are where you intended to be. A generic title forces the user to do additional work to answer a question that should already be answered.

Keyboard users navigating between pages through browser history depend on meaningful titles to understand their navigation trail. Browser bookmarks become useless when every saved page is labeled the same thing.

The template duplication problem compounds across a site. One undescriptive title is an inconvenience. A hundred identical titles across a government portal is a systemic barrier to independent navigation.

The Fix

The failure pattern:

<!-- Authoring tool default — never replaced -->
<title>Untitled Document</title>
<!-- Filename used as title -->
<title>report.html</title>
<!-- Template duplication — same title on every page -->
<title>City of Springfield — Official Website</title>

The corrected pattern — titles that identify content and context:

<!-- Specific page content identified -->
<title>2024 Annual Budget Report — City of Springfield</title>
<!-- Form pages name the form -->
<title>Building Permit Application — City of Springfield</title>
<!-- Error states communicate clearly -->
<title>Error: Incomplete Submission — Building Permit Application — City of Springfield</title>
<!-- Search results identify the query -->
<title>Search Results for "park hours" — City of Springfield</title>

The established convention — [Page-Specific Content] — [Site Name] — serves multiple purposes simultaneously. It satisfies Success Criterion 2.4.2 (opens in new window), it provides orientation for screen reader users, and it distinguishes tabs in a multi-tab session. The page-specific content leads because that's the differentiating information.

Dynamic pages require dynamic titles. A CMS or web application that generates page content must also generate page titles. This is a template architecture decision, not a content authoring decision.

Applying This

F25 failures are detectable by automated tools — which is both good news and a reason they should never reach production. Any accessibility scanner will flag an empty <title>, a missing <title>, or in some cases a title that matches a known default string. That said, automated testing has real limits: a tool can confirm a title exists and is non-empty, but it cannot judge whether "Page 1" meaningfully identifies content. Human review catches the template duplication problem that automated tools routinely miss.

For development teams, the practical checklist:

• Template audit: Pull a list of unique <title> values across your site. How many are identical? How many match known default strings?
• CMS configuration: Verify that your CMS title field is required, not optional. Verify that the template inserts the page title dynamically, not a static string.
• State changes: Single-page applications must update the document title when the view changes. This is a common gap in SPA development.
• Error states: Pages that display errors should title themselves as error pages — users navigating back through history need to identify what they're returning to.
• Code review gate: Add <title> content review to your PR checklist. It takes ten seconds to check and prevents a Level A failure from shipping.

The investment is minimal. The barrier, when it exists, is real.

Our research on testing methodology reinforces a point relevant here: automated tools will catch the empty title, but the template duplication problem — where every page has a title that is technically non-empty — requires human judgment to identify as a failure. Building both into your QA process is the only way to catch the full range of F25 violations.

CORS Perspective

From a risk and legal priority standpoint, F25 is a Level A failure with near-zero remediation cost — which makes it legally indefensible when it appears in a complaint or audit. Title II entities facing DOJ scrutiny under the 2024 web accessibility final rule (opens in new window) cannot credibly claim resource constraints as a barrier to fixing <title> elements. The compliance framework pressures that create genuine organizational paralysis elsewhere simply do not apply here — this is a straightforward, automatable, high-visibility fix that belongs at the top of any remediation queue.