Page Titled

Why it matters

The title is how a page identifies itself before anybody reads a word of it. It is what a browser tab shows, what a bookmark keeps, what a search result prints, and what tells somebody where they have landed without making them work it out from the content. W3C names four groups it helps, and the fourth is the one nobody expects. People with severe mobility impairments who work by audio while moving between pages depend on the title to know they arrived somewhere new. Ten tabs all named after the same brand are ten identical doors. A title that says which one it is saves everybody the guess, and the research W3C points to behind this rule is a study of watching people work with screen readers.

Who this rule protects

This affects screen-reader users orienting themselves on arrival, people with visual disabilities telling several open pages apart, people with cognitive disabilities, limited short-term memory or reading disabilities, people with severe mobility impairments who work by audio while moving between pages, and everyone scanning a page of search results.

How to check it yourself

1. 1Read the browser tab on every important page and ask whether the words describe that page's topic or its purpose. That is the whole test.
2. 2Open several pages in separate tabs and try to tell them apart from the titles alone.
3. 3Move around a single-page app and watch the tab. If the title holds still while the view changes, every view after the first is an untitled page.
4. 4Open every PDF on the site and read its document properties, not its filename. A PDF with no title recorded inside it fails this rule even when the file is named perfectly.
5. 5Compare the link somebody clicked with the title of the page it opened. Keeping the two close is what confirms to a reader that the click worked.

Failures we see most often

• Every page carrying the same title, such as 'Home' or the brand name alone, so nothing tells one from the next.
• A single-page app whose title is set once at boot and never changes as the user moves between views.
• Keywords stuffed ahead of the page name, which buries the useful part exactly where a narrow tab cuts it off.
• A PDF published with an empty title entry, so assistive technology reads out the filename instead.

Who this one is for

Read from this rule's own note above, so the grouping and the note cannot disagree.

• Blind and screen reader userspeople who cannot see the screen
• Motor and keyboard-onlypeople who cannot use a mouse, or cannot use one precisely
• Cognitive and learningpeople for whom the difficulty is understanding, remembering, or staying with it

How this one is tested

We list 2 ACT rules against 2.4.2. Each one defines exactly what a checker looks at, which is how automated tools decide what to flag. Each one also checks a slice, so passing every rule here is not the same as meeting the criterion, and a rule can be proposed rather than approved or need a person to finish it. The note beside each says which.

• HTML page has non-empty titleA tool can check this
• HTML page title is descriptiveA tool can check this

How to fix it

• Generate the title from the page's own data rather than writing it by hand, and put the page's name at the front. 'Order your audit | WCAGrules' survives a narrow tab. 'WCAGrules | Order your audit' does not.
• In a single-page app, set the title on every route change. Most frameworks carry per-route metadata for exactly this.
• Set the title inside every PDF you publish, in the document properties, and tell the file to display that title rather than its filename.
• Keep the link text and the destination title close to each other. It costs nothing, and it tells the reader they arrived where they aimed.

Passes vs. fails