Search topics
Page titles that are the same on every page
The site's layout sets one title for every page, and the router never changes it, so every tab, bookmark and history entry reads the same.
The problem
People with several tabs open, and screen reader users, cannot tell which page they are on or which tab to return to.
Someone shopping at a garden centre's online shop opens a few pages in new tabs to compare them: spring bulbs, the basket and the contact page. Every tab reads "Fernway Garden". To find the basket, they click through the tabs one by one. A screen reader user who switches windows hears "Fernway Garden" each time and has to read into the page to learn where they are. Their browser history and bookmarks fill with the same name, so going back to a page they saw yesterday means opening each entry.
The shop is a single-page app, and this is the most common way such apps fail 2.4.2. The browser loads one HTML file, whose shared layout sets <title>Fernway Garden</title>. After that, the router swaps the content on the client without loading a new page, so nothing ever replaces the title unless the app's own code does. Sites rendered on the server rarely fail this way, since each page arrives with its own <title>; in a single-page app, a fresh project starts with this failure until someone wires titles into the router. Each page loads with a title, so the page is "titled" in the narrowest sense, but the title does not describe it. WCAG 2.4.2 asks that each page has a title that describes its topic or purpose. A title that is the same on the basket and on a product list describes neither.
The failure grows with each page open at once: one tab is easy to keep track of, five identical ones are not. Narrow tabs on a laptop or a phone's tab switcher show only the first few words of a title, so a title that starts with the site name fails in the same way even when the rest of it differs.
3 of 10 groups affected
- No vision (affected)
- Low vision (affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (not affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Without vision A screen reader reads the title first when a page loads and when someone switches windows. When every title is the same, it gives them nothing to go on, and they must read into the page to find where they are.
- Limited language, cognitive and learning abilities People who rely on tabs, history and bookmarks to keep their place, instead of remembering it, find a list of identical names that tells them nothing.
- Limited vision People using magnification see only part of the screen. The tab title is a quick check of where they are, and an identical one sends them scanning the page instead.
A page-level check such as axe's document-title looks at one page at a time and asks only whether the title exists and is not empty, so every page here passes. Site crawlers, many of them built for search engine work, do report titles repeated across URLs; run one, since it finds this failure across a whole site. Neither kind of tool judges whether a title describes its page: "Page 2" or a route name like "basket-view" passes both. A crawler also loads each URL fresh, so it does not see a title that goes stale after moving through the app, for example one that stays on the previous view after Back. A suggested fix needs the same check: a title set in the shared layout only repeats the failure. Check the titles after you move through the app, not only on the page you opened.
Try it
Find the tab with your basket in it.
Each tab shows its page’s title. Use the shop’s links to change page, and watch the tab.
Broken Can you fix this?
Screen reader, on switching to this tab: “Fernway Garden”
Set by: <title>Fernway Garden</title>
A recreated demo. The broken version is intentionally inaccessible.
The fix
Name each page in its title, page first and site name last, and update the title whenever the view changes.
- 1Every page has a title, and no two different pages share one.
- 2The page's own name comes first, the site name last.
- 3When the view changes without a page load, the title changes with it.
<!-- app.html, the shared layout --><head> <title>Fernway Garden</title></head>Every view, from a product list to the basket, has the same title. Nothing tells a tab, a bookmark or a screen reader which page this is.
Each page sends its own title in its HTML, so it is there before any script runs and in every browser. The page's name comes first, so it stays visible in a narrow tab and is the first thing a screen reader says.
Both pass 2.4.2. A title in each template is the simplest when the server renders each page: there is no script to fail and nothing to keep in step. A single-page app that swaps views on the client has no new HTML to carry a title, so it needs the router to set one; most frameworks offer a head component (<svelte:head>, Next.js metadata, Angular's title on a route) that does this and renders it on the server as well. Use whichever matches how your pages are built; many sites use both.
Put the page first and the site name last, separated by a dash or a bar: "Basket – Fernway Garden". People recognise the site already; what they need is which page. For a page inside a section, go from the most specific to the least: "Tulip mix – Spring bulbs – Fernway Garden".
Pages that share one template need something that tells them apart. Some ways to do that.
- search results include the query and, if it helps, the count: "Results for tulips (24) – Fernway Garden";
- each step of a checkout says which step it is: "Delivery, step 2 of 4 – Fernway Garden";
- a form returned with errors starts with "Error:", so people hear it before anything else.
Keep the title short: the first 30 or so characters do most of the work in tabs and search results. Don't stuff it with keywords; that helps nobody find the page. Write it in the page's language, and translate it with the rest of the page.
A dialog or a panel that opens inside a page does not need its own title; a view with its own URL does. Changing the title does not by itself tell a screen reader user that the view changed; announcing the new view and moving focus is a separate task, covered under page changes.
Fixing this with an AI coding assistant? Get this guide as Markdown
Verify the fix
5 checks, no mouse.
Test with: Screen reader
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat when routes or templates are added.
Limits
This is a starting pattern, not a guarantee for every application. Whether a title describes a page is a judgement no tool makes; read the titles as a visitor would. Apps that open content in iframes or new windows need titles there too. Test the complete journey on your real pages.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.