The a11y Monthly: Why you shouldn’t rely on the title attribute

The title attribute is a small bit of HTML that developers can use on most of the HTML elements. In desktop browsers, the title attribute content is typically displayed as a visual “tooltip”. The attribute has been around for about 15 years. It is still widely used on the internet in the belief it’s a good way to provide information and also for SEO purposes. In this post, I’ll try to explain why you shouldn’t rely on the title attribute to convey important information to your users and why, as a WordPress contributor, together with many other contributors, we’re progressively removing the title attributes from the WordPress codebase.

If you want to hide content, use the title attribute

Quoting from an excellent post from Steve Faulkner on the Paciello Group blog:

If you want to hide content from mobile and tablet users as well as assistive tech users and keyboard only users, use the title attribute.

Steve Faulkner, among other things, is one of the editors of the HTML5 Recommendation and I hope he won’t dislike I use his provocative statement. Worth noting the HTML5 Recommendation itself warns against relying on the title attribute:

Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g. requiring a pointing device such as a mouse to cause a tooltip to appear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet).

What does this mean for content producers and non-technical persons willing to create effective and accessible content? What should developers aiming to build beautiful and accessible websites do? Let’s consider a few scenarios.

Desktop browsers

The title attribute was introduced 20 years ago and browsers have implemented it as a “visual tooltip” displayed when hovering an element with the mouse or other pointing devices. Among today’s modern browsers, Internet Explorer 10+ and Edge are the only ones that have implemented a method to display the title attribute content when using the keyboard. Firefox used to have a “Properties” item in the contextual menu accessible with a right-click or pressing Shift+F10 that gave access to an “Element properties” dialog showing various information including the title attribute. This feature was removed some years ago.

All the other modern browsers don’t display anything when using a keyboard and focusing an element. Not to mention title attributes on not-focusable elements are not available to keyboard users either, as the elements can’t receive keyboard focus. As a consequence, the information provided via the title attribute is completely hidden to the vast majority of users who use a keyboard to navigate content.

Touch devices

With the advent of touchscreen devices, the title attribute usefulness has greatly decreased. As far as I’m aware, mobile browsers don’t support the tooltip display behavior. There is no support for alternative methods of accessing the title attribute content either. This makes the information provided via title attribute simply not available to all mobile phones and tablet users.

Screen readers

Screen readers don’t support access to the title attribute content in a consistent way. It also depends on user settings: many screen readers have a “verbosity” setting. When set to low verbosity, the reader may ignore the title attributes completely. For some HTML elements, there are complicated technical rules screen readers have to follow to calculate a “fallback” for an element label. A few other HTML elements have special rules, such as frames, iframes, inputs, and abbreviations. I won’t go into technical details because that’s out of the scope of this post. The point is, there is no guarantee for a full support. You should never rely on title attributes to convey relevant information.

Screen magnifiers

Screen magnifiers, among other features, allow visually impaired users to zoom a portion of a web page to make the content bigger and easier to perceive. Usually, you can only zoom in on one portion of a web page at a time. While screen magnifiers users have access to the title attribute “tooltip” if they use a mouse, tooltips that consist of more than a few words are difficult or worse to read simply because they fall out the “zoomed” region, especially at high magnification levels.

Motor skill and cognitive impairments

There’s a great variety of other impairments.  For the sake of brevity, I have to group them in the same paragraph. It’s just impossible to list all of them. It’s easy to imagine how motor skill impairments make hard to fine-control a pointing device and hover on an element in the first place. Furthermore, in some browsers, the displayed tooltip disappears after a short period of time. Not pretending to be a highly scientific test, quickly checking the current major browsers, here’s what I’ve found:

• Chrome 58 on macOS: the tooltip disappears after about 10 seconds
• Chrome 58 on Windows 10: the tooltip doesn’t disappear
• Safari 10: the tooltip disappears after about 10 seconds
• Edge: the tooltip disappears after about 5 seconds
• Internet Explorer 11: the tooltip disappears after about 5 seconds
• Firefox 53 (macOS and Windows): the tooltip doesn’t disappear

Apart from the different behaviors, the tooltip disappearing can cause difficulty accessing the title attribute content for users who can use a mouse but have fine motor skill impairment. For the same reason, this may result in difficulties for users who need more time to read the tooltip content.

Authoring practices

Even when assistive technologies support access to the title attribute content, poor authoring practices or software limitations can negatively impact accessibility. I’ve often seen title attributes used to just repeat (or nearly repeat) the links content. Even WordPress was doing that and luckily fixed it a few years ago. In any case, where the title attribute matches the link text, it is redundant at best. It causes a repetition effect (where screen readers read the text twice). And at worst, producing just unwanted noise for screen reader users.

Title attributes in WordPress

The progressive removal of title attributes in WordPress started a few years ago, with a very specific case about images. At that time, title attributes were automatically added to images displayed by WordPress on the front-end. Most of the users weren’t filling up the “title” field while uploading new images. So almost every time the tooltip was going to be one of three things. It could be the image caption (redundant), the alt text (misapplied and redundant), or the image filename used as fallback, something like “IMG_5678”. Luckily, this not-so-useful behavior was fixed in WordPress 3.5.

Since then, a lot of work has been done, especially focused on the WordPress administration screens. I’ll give you an idea of the progress done so far. Here’s some data from the WordPress codebase from version 4.0 to 4.7. In the WordPress 4.0 admin screens codebase, there were 157 occurrences where the code was generating title attributes. In WordPress 4.7 there are just 17. Some of them are legitimate because used on iframe elements. Others are in files that WordPress core doesn’t use anymore. These stick around for backward compatibility reasons.

Additionally, WordPress 4.8 removes all the title attributes from the Tag Cloud widget: it’s a legacy, glorious, and still pretty popular widget that deserved some accessibility improvements.

Alternative to title attribute

From an accessibility perspective, if some bit of information is so important that you feel you must add it via the title attribute, then you should wonder why it’s not in clear text on the page where everyone has access to it. Making your content accessible to everyone is always the best option. Google will be happy too. Specifically for links, a meaningful, descriptive, accurate anchor text is the best accessible solution.

Want to help?

At Yoast accessibility matters a great deal. We know it’s a process and we’re continuously improving, testing, iterating, and developing. We’re always open to feedback and contributions. Please do not hesitate to let us hear your voice. Please report any issues or potential improvements you notice in our products.

Read more: Why every website needs Yoast SEO »