Functional title elements, part 2

An oversized browser tab with the text label "Page Title"

The title element is often one of the first elements covered when learning HTML. But because changing a page’s title is trivial, many website creators mistakenly view it as optional or purely decorative, leaving it neglected. But the truth is that the title is a functional element that aids users in a variety of situations.

This is part 2 of an article series on the title element. If you missed it, check out part 1 where I cover some functional uses of the title element. Here, we’ll review some best practices that give a title its meaning and usefulness.

Best practices

Now that we've seen some of the functional uses of the title element, let's jump into some best practices on how we can create great page titles to maximize their effectiveness.

Titles shouldn't be blank

Having no page title isn't a good start. If your title element doesn't contain a value, or if it's missing completely, the browser will use the page's url instead:

Browser interface displaying one tab labelled with a long url

That's not ideal. URLs can be messy and are less clear to read and understand than a descriptive title. Imagine glancing up there and trying to decipher which page you're on. And that's if the URL is even human-readable or reflective of the page name to begin with.

For screen reader users, instead of hearing the page title when a new page loads, they'll begin to hear a URL spelled out that they then have to piece together in their head. Not a great experience.

There's also the simple fact that lacking one of the most basic of HTML entities isn't a good signal to your users that you'll be providing a polished and well-crafted experience.

Titles should only contain text

The content you put inside of the title element should be text only. Regular punctuation use is perfectly fine, but avoid abusing it. For example, it's not uncommon for a personal or artistic site to create wavy lines or other effects by combining obscure punctuation characters.

Screen readers also announce most uncommon characters by their name. So if you get cute and add something like "o._.o" in an attempt to create a face, a screen reader user would hear "o dot underscore dot o", which is just needlessly confusing.

And on that same note, don't use emoji either. Emoji, at best, can be ambiguous and unclear – which goes against the spirit of creating clear page titles. Not to mention that emoji support across platforms and accessible technology is inconsistent. Save any symbols for the site favicon.

Title content should be informative

What we put inside of the title element is important, as it informs users where they are and what the page contains.

On the homepage of a site, typically the site name is great on its own. So, Darin's Shoe Company is a perfectly fine and informative title for our shoe company's homepage.

For inner pages of a site, it's a good practice to include both the page name and the site name. So on the Products page of our shoe website, we could use Products - Darin's Shoe Company. Users will easily know that this is the Products page on the Darin's Shoe Company website.

Imagine if we used the page name only. On the home page it's not an issue. But on other pages we could start to run into problems. Let's say we're pricing shoes on the Products page of three different websites that fail to use an informative title:

Browser interface with three tabs that are all labelled "Products".

It's difficult to know which tab is which site. Sure, the favicons give us a hint, but those are not always a guarantee to be recognized. Not to mention for screen reader users, hearing an announcement like "Products, web content" three times in a row while navigating tabs would be a very confusing experience.

But using both the page and site name allows users to differentiate between similarly-named tabs. So when they encounter Products - Darin's Shoe Company, there's no doubt which page and site they're on:

Browser interface with three tabs that are labelled "Products - Darin's Shoe Company", "Products - ShoeMart", and "Products - United Shoes"

Title content should be ordered correctly

In the last section, we introduced the idea of using both the page and site name in the title element. It's also important that we order these two bits of information correctly.

On inner pages if we keep the site name at the beginning, we're putting the redundant part of the title first and making the unique part more difficult to get to. Imagine if we had multiple tabs open from the same site:

Browser interface with three tabs whose labels all begin with "Darin's Shoe Company". The label text after that is obscured by the tab length.

We don't know which tab is which page because we can only see the site name. Instead of going right to the tab we want, we'd have to open each tab until we found the one we were looking for.

Screen reader users also experience a mild annoyance here, as they have to listen to "Darin's Shoe Company" over and over again to find out the page names.

So it's important to order the title content with the unique page name first, followed by the site name:

Browser interface with three tabs labelled "Products - Darin's Shoe Company", "New Releases - Darin's Shoe Company", and "Best Sellers - Darin's Shoe Company"

That allows for the tabs to be both scannable visually, and understood efficiently when announced.

A note about separators

Please use discretion on which character you use to separate the page and site names. I typically use a dash/hyphen, but it's normal to see a comma, period, vertical line, and other common punctuation. They're easy to visually identify, and screen readers will usually insert an appropriate short pause in their place while announcing.

But be aware that if you use an obscure character, screen readers may read it aloud and make your page title sound strange. For example, if you use a "greater than" symbol (>), most screen readers by default will announce its name while reading. So if the title was formatted Products > Darin's Shoe Company, you'd hear "Products greater than Darin's Shoe Company", an odd experience.

Titles should be unique

This practice expands on the points above. Using the page name followed by the site name is a great practice. However, some website creators don't take this far enough. Ideally, every page on your site has a unique page title, not just top-level category and landing pages.

In the case of the product pages for individual shoes, let's say we use a generic title like Shoe Page - Darin's Shoe Company.

Browser interface with three tabs labelled "Shoe Page - Darin's Shoe Company"

Sometimes titles like this get entered into a template during development as placeholders and never get replaced, other times these types of details are simply ignored or forgotten. Either way, they don't provide enough information about what's on that page.

In the case of the tabs in the image above, we can't tell the difference even though they each contain a different product page. What if we remember seeing a shoe we liked previously, so we look through our browser history to find it? It would be impossible to know which page was which, forcing us to go through one at a time or start completely over.

It would be way more beneficial to use the product name in the title. So using a title like SuperSole 3 Shoe - Darin's Shoe Company is immensely more informative:

Browser interface with three tabs with unique labels like "SuperSole 3 Shoe - Darin's Shoe Company"

Titles should be concise

In our quest to create informative and unique page titles, we should know that we want to also keep the title as concise as possible. While there's no technical limit on how long it can be, short and sweet is key here.

The title element isn't the place to insert a long-form description of the site or page. Leave that for the other meta elements or even Open Graph tag content. The title is a document name that users will glance at, skim, or listen to quickly to know what it contains. So the more unnecessary content you add, the less usable it becomes.

Taglines

A common practice in the wild is websites adding their brand tagline into the page title. While I don't personally love this practice, it's acceptable if done with discretion and caution, and probably only on the homepage.

For example, Darin's Shoe Company - We know shoes is fine for our homepage title. But New Releases - Darin's Shoe Company - We know shoes is visually a lot to scan, and for screen reader users is an earful to listen to while navigating around the site.

Long taglines should absolutely be avoided, as well as other unnecessary content like marketing info. If you were to use the title Darin's Shoe Company - The best shoe site on the internet with over 100,000 models of shoes to choose from in all of your favorite brands., that is absolutely excessive.

Site Hierarchy

It may also be tempting to use the full path of the current page in the page title. So if we were on a product page for an item called SuperSole 3 that is located in the Running Shoes section under the Men's category, we might think to use SuperSole 3 Shoe - Running Shoes - Men's Shoes - Darin's Shoe Company, reflecting the path from the site's homepage to the product page.

Again, that's a lot for a user to scan or listen to and only serves to add confusion where simplicity is needed. The title element isn't the place to inform users of the site's hierarchy: use breadcrumbs or other UI patterns to help orient users within the site as needed.

Titles should be dynamic

Most web pages are static. That is, they don't change once they're loaded. So it makes sense that the title remains static as well.

But some web pages are dynamic. They can change state or load new content in real-time without refreshing. Or sometimes they do refresh but contain different content. In these cases, the title should change to reflect the current page context.

Here's a few examples:

Templated pages

Templated pages, essentially static pages that have different content plugged into them on the server, also need their titles updated at the same time.

A good example of this is a Search Results page. The page has a set layout and structure, but the content depends on what the user had searched for. We can't simply use a title like Search Results - Darin's Shoe Company, as that doesn't describe the actual content nor differentiate it from other searches.

A better title would be something like 'Business casual shoes' Search Results - Darin's Shoe Company. Visually, it's much more clear. For screen reader users, it's also a confirmation that their query has gone through successfully. A user might submit several searches, and if they only hear "Search Results" after each submission, they may not know if their new query was successful or not.

Form validation

Sometimes, a page will reload itself with some new content for the user that may not be immediately clear. A user may fill out a contact form, causing the page to reload with a status message.

In these cases, the title should reflect this new page state as well. Something like Message sent successfully! - Contact Us - Darin's Shoe Company is a nice compliment to any other text added to the page content. Without this, users of accessible technology won't know if their submission was successful or not, they'll just think that the page reloaded.

Single Page Apps

Single Page Applications are common on the internet these days. You can have a page that constantly changes, but never actually refreshes. So, it's important that anytime the page context changes, the title changes along with it.

This is an especially important practice to keeping a product accessible. A visual user might see that the page has changed, but someone using accessible technology would have no idea. If the title updates with the content, these users will have that announced. Note that updating the title only in this example may not be enough to create an accessible experience, and developers may need to also move focus or incorporate other techniques.

Conclusion

Wow, that was a lot of information about such a seemingly minor HTML element. Between both parts of this article, I hope that I've illustrated how this unsung element actually has a big impact on a website's functionality and usefulness.

I hope you'll take away some knowledge here for your next project and give the title element the attention it, and your users, deserve!

Older Article: Functional title elements, part 1