Page titles (WCAG 2.4.2): how to write them

A page title is the text inside the title element in a page's head. It is not the large heading on the page, which is the h1. The title shows in the browser tab and, in some browsers, the window title bar, and the HTML Standard says it should identify the page even when it is seen out of context, such as in history, bookmarks or search results. W3C's Easy Checks adds that a screen reader speaks the title first when someone arrives on a different page, and MDN notes that a common navigation technique for people using assistive technology is to read the title and infer what the page contains. The title tells people which page they are on. Headings, landmarks and skip links help them move around inside it.

The requirement is success criterion 2.4.2 Page Titled, Level A. It is not one of the nine criteria that are new in WCAG 2.2 (see what's new in WCAG 2.2). Level AA conformance includes every Level A criterion (see WCAG conformance levels), and the accessibility laws we cover usually name Level AA, so a page title is part of what they point to. Our laws guide shows which WCAG version each one names. This page explains a technical standard and is not legal advice.

What WCAG 2.4.2 requires

The criterion reads, in full: "Web pages have titles that describe topic or purpose." W3C's Understanding document names technique G88, descriptive titles, together with H25, a title written in the title element, as the sufficient approach for HTML, and PDF18 in place of H25 for PDF files. It documents one failure, F25, for a title that does not identify the page's contents or purpose. Technique G127, which puts a page in the context of a larger collection, is listed as advisory only.

W3C also publishes two ACT rules that testing tools and auditors can follow: HTML page has non-empty title and HTML page title is descriptive. Together with F25 they give a clear picture of what fails.

A page that avoids every row still needs a person to read its title next to the page: W3C's non-empty title rule says a pass means the criterion needs further testing. The criterion sets no length, format or order for a title. Those come from technique G88 and from practice.

Seven rules for writing a page title

1. Say what this page is about

Technique G88 says a title should identify the subject of the page and make sense when read out of context, for example by a screen reader or in a site map or list of search results. Ask whether the title would still tell a stranger what the page is if it were all they saw. "Returns and refunds" does. "Policy" and "Page 2" do not. For a document or a web application, the Understanding document says the name of the document or application can be enough. It also calls it good practice for a link's text and the title of the page it opens to agree or be very similar. Our guide to link text covers the link side.

2. Put the distinctive words first

Easy Checks advises putting the important, unique words at the start, and notes that a tab shows only the first part of a long title. MDN gives the same order: the page's primary purpose first, then the website's name, so a screen reader announces the purpose first. The example in the Understanding document does the same: a pattern page in the ARIA Authoring Practices Guide is titled with the pattern's name first, then the abbreviations for the guide, for WAI and for W3C. G88 also lists an example that begins with the organization's name, so WCAG does not forbid putting the site name first, but in GotAlt's reading it spends the most visible words on the part that never changes.

<title>Returns and refunds | Example Store</title>

That is the pattern we recommend: the page's subject, a separator, then the site name (Example Store is a placeholder for yours). Google also advises branding titles concisely, so a long site name is worth shortening. G127 notes that a title can also say which sub-site or collection a page belongs to, which helps people place the page, and our guide to breadcrumbs and navigation covers the on-page version of the same idea.

3. Keep it short

G88 says a title should be short, and WCAG sets no number. Google's documentation says a title element has no length limit, but a title link in its results is cut off as needed, typically to fit the device width, and MDN says important words should come early because search engines show only the start of a long title. Short does not mean one word: MDN advises against one- or two-word titles and asks for a descriptive phrase, and a single word rarely identifies a page out of context. In our reading, aim for the fewest words that still tell this page from every other page on the site, which is usually a short phrase.

4. Give every page its own title

Failure F25 includes a template-generated site whose pages all carry one title, because the title cannot then identify any page. Easy Checks asks that a title distinguishes the page from other pages on the website, and Google advises against repeated or boilerplate titles. When a CMS or a theme builds titles from a pattern, open a few pages of each type and confirm the pattern includes something unique, such as the product name, the article headline or the category.

5. Let the title stand alone, and keep it related to the h1

The HTML Standard notes that a title often differs from the document's first heading, because a heading may only make sense with the page around it. One of its examples pairs the title "Dances used during bee mating rituals" with the heading "The Dances". Easy Checks says the h1 is usually similar to the title, and Google says its title links draw on headings and other prominent text as well as the title element, and that it may change a title that does not match the page. So write both for the same page: the heading can lean on its surroundings and the title cannot. The heading also has to be marked up as a heading, which is what success criterion 1.3.1 asks (see our WCAG 1.3.1 page); our heading structure guide covers the outline.

6. Write plain text for people

The title element holds text only, and MDN says any tags inside it are treated as plain text, so leave markup out. A string of keywords is not a description: MDN says a title that is just a list of words often lowers a page's place in results, and Google says repeating the same words does not help users and can look spammy. Write the title in the page's language (Google advises using the page's primary language for the title), and see our guide to the html lang attribute for declaring it.

7. Name the state on search, error and step pages

A search results page titled with only the site name fails the ACT descriptive-title rule. Put the query in: "Search results for garden hose | Example Store". MDN's example for a form that has errors starts the title with the error count. In our reading, a multi-step flow such as checkout should name the step, so a person with several tabs open can tell which one is waiting for them.

Titles on pages that change without a reload

In a single page application, several views are served from one address. The Understanding document says the title should be changed dynamically to reflect the content or topic of the current view. In script, that is the document.title property, which the HTML Standard defines for reading and setting the title:

document.title = "Order summary | Example Store";

Setting the title does not make a screen reader speak it. MDN warns that a dynamically updated title is not automatically announced, and that ARIA live regions may be needed as well. In GotAlt's reading, treat a view change like a page load: update the title, decide where focus goes (see our guide to focus order and tabindex) and listen to the result with a screen reader. Our guide to how screen readers read a page explains what a listener hears.

PDFs need a title too. Technique PDF18 sets the Title entry in the document properties and turns on the viewer setting that shows it in the title bar. In Acrobat Pro both are in File, then Properties. Our accessible PDF guide covers the rest of the file, and the PDF checker checks the title.

Weak titles and their rewrites

Check it yourself

Start with what a visitor sees, then use tools for the mechanical failures:

1. Read the tab. Hover over the tab to see the full title, or open the Add Bookmark dialog, which shows it too, as Easy Checks suggests. You can also type document.title in the browser's console.
2. Open five pages in five tabs. Can you tell them apart from the first few words of each title? If not, the unique words are too far back.
3. Listen to it. Load a page with a screen reader running and note what is spoken on arrival. The title should tell you which page you reached.
4. List your titles. If you can export or crawl them, sort the list and look for repeats and for default text such as "Untitled". A repeat usually means a template that never fills in the page-specific part.
5. Compare the title with the outline. The heading checker draws a page's heading outline and flags a missing h1, more than one h1, skipped levels and empty headings. It does not read the title, so put the two side by side yourself.
6. Check the rendered page. The accessibility bookmarklet runs in your browser on the page as it is rendered, including pages behind a login and titles set by script, and reports a missing page title.
7. Scan my site for free to run 16 rule-based checks, one of which flags a missing or empty page title, on up to 3 pages.

None of these can say whether a title is accurate. Our criteria reference lists 2.4.2 as partly automated: a missing title is detectable, and whether it describes the page is a judgment. A title that says "Pricing" on a page about returns passes every tool here and fails the criterion. For the wider routine, see how to test website accessibility.

Keep it checked

A title that is right today can break with the next template change or batch of new pages. GotAlt checks the pages you monitor every week. It compares each image's alt text with the image itself (up to six images per page), runs its rule checks, opens monitored pages in a browser for contrast and other render-dependent checks (see what we check), and reports what changed. Plans are from $69 a month. Audit my whole site from $69/mo.