What does your page announce itself as?

The title is read in six places, and none of them is the page

This is the whole reason SC 2.4.2 fails quietly. Every other accessibility defect is at least theoretically visible: a contrast problem is on the screen, a missing label is next to an empty box, an unnamed button is something you can point at. A wrong title changes nothing you can see. The page renders perfectly, the design review passes, the screenshot in the ticket looks right, and the defect ships.

announced on load    "React App"           ← the first thing a blind visitor hears
browser tab          React App             ← on all forty of your routes
bookmark name        React App
history row          React App
task switcher        React App — Chrome
search result        React App             ← if it is indexed at all
shared link          React App

And the fix is one line in one layout file. That ratio — the cheapest fix in accessibility, sitting in the place nobody looks — is why this checker exists as its own page.

What WCAG actually says about titles

Less than you would expect, which is why this tool is careful about what it calls a failure. SC 2.4.2 Page Titled at Level A is one sentence: web pages have titles that describe topic or purpose. That gives a checker exactly two decidable things — whether a title exists, and whether it is one of the strings that identifies nothing. Everything after that is a judgement about your words, and an automated tool that pretends to make it is guessing on a stranger’s behalf.

So four shapes here are called a Level A failure: no <title>, an empty one, a scaffold placeholder, and a template token that never rendered. Everything else — brand-only titles, brand-first ordering, over-long titles, duplicate elements, an og:title that disagrees — is reported in a review band that says plainly it is not a conformance failure. That split is pinned by the tool’s own test fixtures: a classification cannot be marked as a failure unless it names the criterion it breaks.

Seventeen sites, read live on 23 September 2026

Run against real pages, this checker is quiet — which is the correct result and worth showing rather than hiding. Large sites title their pages; the title problem lives in app shells and in generated routes.

gov.uk/browse/benefits     "Benefits - GOV.UK"                          pass
apple.com/shop/bag         "Bag - Apple"                                pass
news.ycombinator.com       "New Links | Hacker News"                    pass
vercel.com/pricing         "Vercel Pricing: Hobby, Pro, and Enterpri…"  pass
react.dev                  "React"                                      pass

app.netlify.com            "Netlify"                                    verify
figma.com/files            "Login | Figma"                              verify
excalidraw.com             "Excalidraw Whiteboard"                      verify
                           → shells. The route title is set after boot.

tldraw.com                 "tldraw • very good free whiteboard"         review
                           → brand first: every tab reads "tldraw •…"

example.com                "Example Domain"                             fail

Three of the eleven shown are client-rendered applications serving a boot title, and that is the shape to check on your own site: the page your framework serves before its bundle runs is the page a crawler stores and a cold visitor is announced.

Everything this checker reports

Four failures, six things to look at, one thing it will not guess about. Each one is decided from the markup your server sends.

• The page has no <title> at all

  Level A failure

  WCAG 2.1 SC 2.4.2 Page Titled (Level A)

  There is no <title> element in this page's head. A screen reader announces the page on load by reading its title; with none, it falls back to the URL and reads the address out — slug, hyphens, query string and all. The tab strip shows the same URL, so a person with ten tabs open has no way to tell this page from any other on the site, and every bookmark and history entry made from it is unreadable. This is one of the few Level A failures a checker can call without interpreting anything.

  The fix: Add one element: <title>Pricing — Acme Bakery</title>. Put the page's own subject first and the site name last. If this is a single-page app, set document.title on every route change as well — the initial HTML is what a crawler and a cold load see.

• The <title> is present and empty

  Level A failure

  WCAG 2.1 SC 2.4.2 Page Titled (Level A)

  The element is there and there is nothing in it — either <title></title> or a title of only spaces and non-breaking spaces. This is worse than a missing title, because every code review, every template check and every glance at the head sees a title element and moves on. The reader gets exactly what a missing title gives them: the URL, read out loud.

  The fix: Put the page's subject in it. If it is being set from a variable, the variable is empty — check the branch that renders when the value is missing and give it a real fallback rather than an empty string.

• The title is a starter-template placeholder

  Level A failure

  WCAG 2.1 SC 2.4.2 Page Titled (Level A)

  The title is one of the strings a scaffold ships with — "React App", "Document", "Untitled Page", "My Site". It identifies nothing: it does not describe the page's topic or purpose, which is what SC 2.4.2 asks for, and every page on the site carries the same one. It is also the single most common way this criterion fails, because the placeholder is valid HTML, renders invisibly and never breaks anything a developer would notice.

  The fix: Replace it with the page's actual subject. Search the codebase for the exact string — it is almost always in one layout file, and fixing it there fixes every page at once.

• The title is a template expression that never ran

  Level A failure

  WCAG 2.1 SC 2.4.2 Page Titled (Level A)

  The title contains unrendered template syntax — {{ page.title }}, %%title%%, <%= … %> or ${…}. The templating layer did not substitute it, so the page is announcing its own source code. A reader hears punctuation and a variable name; a search engine indexes the same.

  The fix: Find which layer was meant to render it. This is usually a title set in a file the template engine does not process, or an SEO plugin's token pasted into a static field that does not expand tokens.

• The title is the page's own address

  Not a failure — worth reading

  WCAG 2.1 SC 2.4.2 Page Titled (Level A)

  The title is the URL, or the domain and the path. That is what a reader already gets when there is no title at all, so it adds nothing — a screen reader announces the address, and a tab shows a truncated slug. It usually means a CMS filled the field with the permalink because nobody typed one.

  The fix: Write the title as you would say the page out loud to somebody on the phone, then add the site name.

• The title is the site name, with nothing about this page

  Not a failure — worth reading

  WCAG 2.1 SC 2.4.2 Page Titled (Level A)

  The whole title is the brand, and this is not the homepage. It is not an automatic failure — the title does identify something — but it cannot do the job SC 2.4.2 describes, which is to describe the topic or purpose of THIS page. Practically: every tab in the strip reads the same word, browser history is a column of identical rows, and a screen reader announces the same three syllables on every route.

  The fix: Lead with the page and keep the brand as a suffix: “Pricing — Acme Bakery”, “Contact — Acme Bakery”. The site name is worth keeping; it just belongs second.

• More than one <title> in the head

  Not a failure — worth reading

  HTML allows exactly one. Browsers take the first and ignore the rest, but testing tools disagree with each other about which one they read, and so do crawlers — which means the title you verified may not be the title being announced. It is nearly always two layers both setting a title: a layout and a page, or a CMS field and an SEO plugin.

  The fix: Remove one. Decide which layer owns the title and make the other pass its value up, rather than emitting a second element.

• The brand comes first and the page comes last

  Not a failure — worth reading

  The unique part of this title is at the end, behind the site name. Nothing about that violates a success criterion, and it is listed here because of where titles are read: a tab shows roughly the first thirty characters, so every tab reads the brand; browser history and the bookmark list truncate the same way; and a screen reader reads left to right, so the listener waits through the site name on every single page before hearing which page they are on.

  The fix: Reverse it. Page first, brand last, one separator between them — the order every style guide and every search engine's own documentation recommends, for the same reason.

• The title is longer than anywhere it appears can show

  Not a failure — worth reading

  This title is over 70 characters. It is not a conformance problem — a long title is still a title — but the tail is invisible in the tab strip, cut off in a search result and cut off in a share card, while a screen reader reads every character of it before the page begins. Whatever is past the cut is being written for nobody.

  The fix: Put everything that identifies the page in the first sixty characters and let the rest fall off. If the extra length is keywords, they are not helping: search engines have rewritten over-long titles for years.

• og:title and the page title say different things

  Not a failure — worth reading

  The Open Graph title used by every share card is materially different from the title in the head. Not a failure, and sometimes deliberate — but it means the page has two names, and the one a person clicked in a message is not the one announced when they arrive. That mismatch is exactly what a reader checks when they are unsure they landed on the right page.

  The fix: Make one the source of the other. If the share card needs different copy, keep the subject the same in both and vary only the framing.

• The real title is set after the page loads

  Verify by hand

  The HTML this page serves is a near-empty shell with a script in it — an app that builds itself in the browser. The title read here is the one in the shell, and the route's real title is set in JavaScript afterwards. That matters more for titles than for most things: the shell title is what a crawler stores, what a cold load announces, and what appears in the tab for as long as the bundle takes to boot.

  The fix: Check what the shell serves, not just what the tab reads after hydration — view source rather than the element inspector. Then run the full scan, which renders each page in a real browser and reads the title that ends up there.

Questions

Is a missing page title really a WCAG failure?

Yes, and at Level A. SC 2.4.2 Page Titled says web pages have titles that describe topic or purpose — it is one of the shortest success criteria in the specification and one of the few a checker can decide without interpreting anything. A page with no <title>, an empty one, or one still reading “React App” fails it. This tool calls those four shapes a failure and nothing else, because everything past them is a judgement about whether your words are descriptive, and no automated tool can make that call honestly.

Why does the title matter more than it looks like it should?

Because of where it is read, which is everywhere except the page you are looking at. A screen reader announces it on load, before the heading and before any content — it is the first thing a blind visitor is told about where they have arrived. It is the label in the tab strip, so a person with fifteen tabs open finds you by it. It is the text of the bookmark, the row in browser history, the entry in the back-button list, the name of the window in a task switcher, the headline of the search result and the fallback for a shared link. None of those are visible while you build the page, which is exactly why this breaks quietly.

My page has a title but every page on the site has the same one. Is that a fail?

Reported, not failed — it sits in the review band here. The criterion asks the title to describe the topic or purpose of the page, and a site name does describe something, so calling it a Level A failure would be a stretch a tool should not make on a stranger's behalf. Practically it still defeats the point: a tab strip of six identical words, a history list where every row reads the same, and a screen reader saying the same three syllables on every route. Put the page first and keep the brand as the suffix.

Does the order really matter — brand first or page first?

It matters in two specific places and nowhere else. A browser tab shows roughly thirty characters, so “Acme Corporation | Pricing” shows as “Acme Corporation | Pri…” on every page, and the differentiator is the part that got cut. And a screen reader reads left to right at a fixed rate, so a listener moving between pages hears the site name in full every single time before reaching the word they are waiting for. It is not a conformance requirement and this tool does not call it one. It is a real cost paid by the people who read the most pages.

How long should a title be?

Short enough that the part identifying the page survives every truncation. A tab cuts at around thirty characters, a search result at around sixty, a share card somewhere between. This tool flags over seventy as worth a look, and that number is a readability threshold, not a rule — there is no maximum length in WCAG and a long title is still a title. The useful test is the one the result panel runs for you: look at what your tab actually shows and check the page is still identifiable in it.

Why is my single-page app reported as “verify”?

Because this reads the HTML your server sends, which for an app built in the browser is a shell — a title set once at boot, a root div and a bundle. Your router sets the real title after hydration, and this tool never sees it. That gap is worth knowing rather than glossing: the shell title is what a crawler stores, what shows in the tab while the bundle loads, and what a cold load announces. It is also where the “React App” default survives for years, because no developer ever looks at a page in that state. The free scan renders each page in a real browser and reads the title that ends up there.

You ignored the <title> inside my icons. Why?

Because an SVG <title> is the accessible name of that graphic, not the name of the document — a completely different element that happens to share a tag name. Every icon set on the web ships them, so a checker that read them as document titles would report a title on pages that have none and report duplicates on pages that have one. Both directions are pinned in this tool's test fixtures.

My CMS puts two title tags on the page. Does it matter?

HTML allows exactly one, and browsers take the first. The reason it is reported is not the browser but everything else: testing tools disagree about which one they read, crawlers have behaved differently over the years, and it means the title you verified in one place may not be the one being announced. It is almost always two layers both claiming ownership — a theme layout and an SEO plugin. Pick one.

Is this an SEO tool?

The title is one of the rare things where the accessibility answer and the search answer are the same sentence, so it will help both — but the classifications here are written against SC 2.4.2 and screen-reader behaviour, not against ranking. That is why a seventy-character title is review rather than failure, and why this will never tell you to put a keyword in front.

Does this store my domain?

No. The check is an HTTP GET of the page you name, run inside the request and discarded when it answers. There is no account, no email field and no row written anywhere. If you go on to run the free scan, that one does keep a report so you can come back to it, which is the whole point of a report.