WCAG 2.4.2 Page Titled (Level A) requires that every web page has a <title> that describes its topic or purpose. The official wording is brief: “Web pages have titles that describe topic or purpose.” The title must exist and be meaningful — blank, generic, or duplicated titles fail. It is one of the easiest criteria to meet and one of the most common to get wrong.

What WCAG 2.4.2 actually requires

The success criterion has two parts, and you have to satisfy both:

  1. The page has a title. There must be a non-empty <title> element in the document <head>.
  2. The title describes the page’s topic or purpose. A title that exists but says nothing useful still fails.

That second clause is what trips people up. Per the W3C Understanding document, the title’s job is to let users identify the page and orient themselves without reading the body content. The title is the first thing a screen reader announces when a page loads, and it’s what appears in the browser tab, the bookmark, the browser history, and the search-results snippet. If your title is Untitled Document or identical across 400 pages, none of that works.

This is a Level A criterion — the most basic tier of conformance. Failing a Level A item means the page doesn’t even clear the lowest bar.

Who it affects

Page titles are quietly load-bearing for several groups. The W3C Understanding 2.4.2 document names them specifically:

  • Screen reader users (JAWS, NVDA, VoiceOver). The title is announced on page load and is the primary cue for telling pages apart. A blind user with ten tabs open relies on the title — read aloud from the tab — to find the right one. Identical titles make those tabs indistinguishable.
  • People with cognitive limitations and limited short-term memory. A clear title helps them confirm they’re in the right place and keep their bearings as they move between pages.
  • People with reading disabilities. A concise, descriptive title is far easier to process than scanning the whole page to work out where they are.
  • Users with severe mobility impairments who navigate by audio. The Understanding document calls out people “whose mode of operation relies on audio when navigating between web pages” — for them the spoken title is the signpost.
  • Everyone, really. Sighted users scan tabs, bookmarks, and search results by title too. Good titles are pure usability that happens to also be required.

Concrete failures (and how to fix each)

The W3C failure technique for this criterion is F25: “Failure of Success Criterion 2.4.2 due to the title of a Web page not identifying the contents.” Here are the patterns that trigger it.

No <title> at all, or an empty one. Some JavaScript frameworks render the shell without ever setting a document title. The fix is technique H25 — a real <title> in the <head>:

<head>
  <title>Returns &amp; Refunds Policy — Maple Street Bakery</title>
</head>

Authoring-tool defaults. F25 explicitly lists Untitled Document and New Page 1. These ship from page builders and never get changed:

<!-- Fails 2.4.2 — default placeholder -->
<title>Untitled Document</title>

<!-- Passes — describes topic and purpose -->
<title>Gluten-Free Menu — Maple Street Bakery</title>

Non-descriptive filenames as titles. F25 calls out titles like report.html or spk12.html. A title that’s just a URL fragment tells the user nothing.

Identical titles across a templated site. This is the failure we see most often. A WordPress, Shopify, or Wix template stamps the same string on every page:

<!-- Every page on the site fails — none can be told apart -->
<title>Home | Acme Plumbing</title>   <!-- on the About page -->
<title>Home | Acme Plumbing</title>   <!-- on the Services page -->
<title>Home | Acme Plumbing</title>   <!-- on the Contact page -->

The fix is unique, page-specific titles, usually {Page topic} — {Site name}:

<title>Emergency Drain Cleaning — Acme Plumbing</title>
<title>Service Areas in Cook County — Acme Plumbing</title>

Single-page apps that never update the title. In a React, Vue, or Angular app, the browser doesn’t reload between “pages,” so the <title> can stay frozen on the first view. The Understanding document is explicit that for single-page applications the title must change to reflect the current view. Set it on each route change:

// React Router example — run on navigation
useEffect(() => {
  document.title = "Checkout — Maple Street Bakery";
}, []);

A useful ordering tip: lead with the unique part. Returns Policy — Maple Street Bakery beats Maple Street Bakery — Returns Policy, because a screen reader user with several tabs hears the distinguishing word first instead of the same site name every time.

How to test WCAG 2.4.2

This is one of the fastest criteria to audit, and you don’t need special software for the spot checks.

  1. Look at the browser tab. Open the page. Is the tab label descriptive and specific to this page? If it says “Untitled,” “Home” on a non-home page, or your site name on every page, it fails.
  2. View source and find the <title>. Confirm there’s exactly one non-empty <title> in the <head>, and that it actually describes the page. That’s the two-step H25 test: the element exists, and it’s meaningful.
  3. Crawl the whole site. Title problems are systemic — they come from templates, so they repeat. Run a crawler (an automated scan or an SEO crawler) to list every page’s title and sort for blanks and duplicates. Most sites discover dozens of identical titles this way.
  4. Test single-page-app routes. Click through each in-app view and watch the tab. If the title never changes, the SPA fails on every view but the first.
  5. Listen with a screen reader. Load the page in NVDA or VoiceOver — the title is the first thing announced. If what you hear doesn’t tell you where you are, neither do your users.

Automated tools reliably catch missing and duplicate titles, but a human still has to judge whether a present title is genuinely descriptive — a machine can’t tell that “Page 3” is unhelpful. That’s the line between a scanner and real manual remediation.

Of all the WCAG criteria, 2.4.2 is one of the most likely to appear verbatim in a demand letter, for a specific procedural reason: it is the very first thing a tester records. A WCAG-EM audit and almost every plaintiff-side screen-reader walkthrough begins by loading the page — and the document title is the first thing JAWS or NVDA announces. A blank, default, or duplicated <title> is therefore captured in the opening seconds of testing, with no interaction required, which makes it cheap evidence: the tester doesn’t have to operate a single control to log the failure. It also fails in bulk. Because titles are emitted by templates, one unfixed Untitled Document or Home | Acme string becomes the same F25 failure on every URL the template renders, so a single root cause inflates the violation count across hundreds of pages in the complaint’s exhibit list.

That bulk-failure quality matters because the volume of litigation keeps rising and reaches small operators, not just enterprises. Over 4,000 digital ADA lawsuits were filed in 2024 (UsableNet 2024 report). Roughly two-thirds of those defendants had under $25 million in annual revenue — UsableNet’s 2024 year-end data put the share of sued companies above that threshold at about 33%, leaving the rest below it. And buying a quick fix is no shield: UsableNet reports that in 2024 more than 1,000 businesses — over 25% of cases — were sued despite already running an accessibility widget. That is exactly the failure mode for a title, which is why we stay anti-overlay: an overlay injected at runtime can rewrite ARIA in the live DOM, but a screen reader still reads the original <title> from the served <head>, and a source-of-truth audit still sees the unfixed tag. The only durable fix is correcting the <title> in the template that emits it.

Courts and the DOJ treat WCAG 2.1 AA as the practical benchmark for an accessible ADA-compliant website, and 2.4.2 sits at Level A — below even that bar, so a missing title is a failure of the most basic tier of conformance. A descriptive title is also part of the Operable principle in the POUR framework: it’s a navigation mechanism that helps users find and orient within content. This is general information, not legal advice; consult a qualified attorney about your specific exposure.

Where it fits in a full audit

Page titles are a five-minute fix per page and a high-confidence win, which makes them a smart starting point — but they’re one criterion among dozens. They pair naturally with 2.4.6 Headings and Labels (make your H1 and <title> consistent) and with a sound heading and landmark structure so the page is navigable beyond its title. Because good titles serve search engines too, fixing them is also one of the clearest overlaps between accessibility and SEO.

Curbcut handles titles the way we handle everything — as hands-on code work, fixed at the template level so they stay fixed, not patched by an overlay a user has to trigger. Scan your titles free and we’ll show you every blank, default, and duplicate across your site, then remediate them for you.