Title attributes

In many articles and blog posts on web accessibility use of the title attribute is promoted. Unfortunately this isn’t the magic bullet that many developers think it is, and I will argue for its use as a last resort.

First let’s see what the HTML 4.01 spec has to say:

This attribute offers advisory information about the element for which it is set.

Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers frequently display the title as a “tool tip” (a short message that appears when the pointing device pauses over an object). Audio user agents may speak the title information in a similar context. For example, setting the attribute on a link allows user agents (visual and non-visual) to tell users about the nature of the linked resource.

Sounds like it might be quite useful. The specification gives an example of its use:

<a href="http://someplace.com/neatstuff.gif" title="Me scuba diving">
   me scuba diving last summer

Here we start to see the problems in the way it is used. Very often a title attribute on an anchor repeats information that is already contained in link text. Supposing that the title text is read by a screen reader what additional information does it provide? Little to none in this example, and unfortunately in most other examples I have seen.

Of course just because it is used badly in an example (and in most places that it is found in the wild) doesn’t prevent it being useful in other cases. What does is the way user agents deal with title attribute values.

As the specification says title attributes are most commonly displayed in user agents (web browsers in most cases) as tooltips, but only on hover with a pointing device and not on keyboard focus. If you are a keyboard only user with a visual user agent then it is very likely that you will not see a single title.

Even if you use a mouse or other pointing device there is a good chance that you will not see title attribute content as there is no visual indication that there is content to find, so unless you are in the habit of hovering over every element on a web page just in case a title attribute is set they will often be missed. Links are the most common place to find title attributes, but even then a user has to hover over a link for a second or two before the tooltip appears thus limiting their discoverability.

What about for users of screen readers then? Sadly they fair no better. As Jared Smith of WebAIM said in a comment on a recent accessibility tips article

…the title attribute is VERY rarely read on links. Screen readers have an setting to read the screen text (the blue underlined text inside the link), the title attribute, or the longer of these two. The default is screen text and I’ve only very rarely seen users change this so that the title attribute is read. So, while it’s OK to use title attribute to provide additional advisory information (that’s what the HTML spec says title is for), do not rely on it for accessibility and don’t count on it ever being seen or read by a screen reader.

So title attributes aren’t very useful then, but does this mean they are harmful? In my opinion they can be because they give the impression to developers that their use can make content more accessible to users and this simply isn’t the case. Often I see title attributes being used to cover up for inadequacies in regular content, for example:

<a href="#" title="Information about XYZ">click here</a>

The issue here is that the link text does not provide sufficient information about the destination when it is not in its full context. The solution is to fix the link text, not to add a title attribute.

An example of an appropriate use of the title attribute is given in the Techniques for WCAG 2.0 document when it offers the following advice about using title attributes on input elements:

  • User agents will display a tool tip when the mouse hovers above an input element containing a title attribute.

  • If no label is available, JAWS and Window-Eyes speak the title attribute when the form control receives focus

    • JAWS 6.0 and later can be set to speak both label and title when the two items are different; however, very few users are aware of this setting.

    • WindowEyes 5.5 has a hot key, ins-E, that will display additional information, including the title attribute, for the item with focus.

I have one criticism of this advice however, and that is that it doesn’t make it clear that this is a technique of last resort. In a situation where a label cannot be accommodated by the visual design first consider the possibility that the visual design might be flawed rather than immediately use this technique. As with links title attributes on input elements are not displayed on keyboard focus, and only after delay on mouse hover. While for many users the layout may provide sufficient context from which to derive the purpose of an input element add a screen magnifier to the mix for a keyboard only user and we are back to content that is obfuscated. If it is possible to accommodate a label for each input element in a design then do so rather than use a title attribute.

In conclusion, whenever you are thinking of using a title attribute think carefully about whether this is the right approach – more often than not you will find that by changing your content the problem, and the need to use title, goes away. If you can find no other alternative then understand that there is no guarantee that content in a title attribute will be available to your users.


There are a couple of comments that deserve a response.

As Jared points out the key phrase in the HTML specification is ‘advisory information’, however I think it can be difficult to determine what is advisory and what can, for some users, turn an unusable interaction in to a usable one. In my opinion the safest option is to assume that any potentially useful content is useful, and sometimes necessary, to all users and where possible to display it by default. Sometimes a tidy design which otherwise improves the user experience doesn’t allow for advisory information, in which case use of the title attribute is a possibility, but as I say in the post it should perhaps be a last resort. The same can apply to any situation were you want to visually hide content, for example to make it available only to screen readers by positioning it off screen – it is a great technique but be sure to understand the consequences before using it.

Thierry mentioned the problems screen magnifier users can have with title attributes. The focus of this post was how unreliably content in title attribute values is made available to users, but he is right to point this out. The issue is that when a title attribute is displayed as a tooltip it covers, and can obscure, other content. With a screen magnifier a smaller area of the page is visible at a time, the tooltip will cover a larger proportion of the visible area than normal, and can therefore get in the way that much more.

14 thoughts on “Title attributes”

  1. One example I often see of using the title attribute on elements is for placeholder or example content. This is a common UI pattern, and the title attribute seems like a good place to put such advisory information. It will need to be duplicated in markup that can be displayed visually, but using the title attribute at least gives screen reader users a chance of getting at this information when using forms mode.

    If I had one criticism of the article, it’s that I would like to have seen more code examples showing suitable alternatives to common misuses of the title attribute. For example, showing that the ‘click here’ link text could contain the additional information from the title attribute, which can then be hidden with CSS to prevent visual clutter.

  2. Hiya Ian,

    An interesting article, some nice examples of its poor use and i was unaware of how jaws supported the title element on form elements, handy to know.


    Jamie & Lion

  3. Nice article, but came here half expecting to find some mention of the “alt” tag in relation to the “title” tag.

    You mention an image tag in your examples, and I was wondering if there is some kind of race condition in browsers whether to display “title” or “alt”?

    Just a itch I haven’t got round to scratching really, I’m probably not alone in wondering about this.

    On another tack: It might be a UI Pattern but I frequently display links which are derived from articles or RSS Feeds which look like this:

    <a href="/story.htm?234" title="This can be up to 255 chars introducing .... " rel="nofollow">My Story</a>

    Where the 1st ~255 chars are pumped into the title tag of the link.

    Would pumping them into the tag make it more or less usable for those non-sighted I wonder?

    Good subject.

  4. Nice article. I can vouch for what has been said and quoted here. Most screen reader or screen magnification users will never know a title attribute even exists. Very few even know how to configure their AT product to look for them.

    FYI, JAWS screen reader defaults to the alt attribute, but will read the title if it is present when an alt tag is absent.

    Visit the e-learning entrance page (link: online learning) and take a look at the Surf’s Up webinars I teach, also available in archive format, to learn more about how JAWS or MAGic behave on the Web.

  5. Thanks! You saved me the effort of finishing my own blog entry on this exact topic.

    The key is “advisory information”, as defined in the HTML specification. If the information in the title attribute is necessary for information, then this goes beyond at least the spirit of the spec, and it will likely cause accessibility issues.

  6. Nice article.
    One thing I would have added though is the issue title creates with screen magnifiers because of tooltips “getting in the way”.

  7. Nice article.
    I’m wondering though why default settings of screenreaders are this way. I think that having their default to read the longer of the two would make more sense with a hot key to read the other value. This would also reduce the number of cases of identical content in links (e.g. when we have 15 “More…” links on some websites, the title can contain additional info about the context).
    For Paul G.: SteveFaulkner wrote a post about “alt and title content display in popular browsers” a few days ago: http://www.paciellogroup.com/blog/?p=498

  8. Thanks for writing this article! And great comments, too. Now I have a good resource to point to when I advise folks not to use what I call “redundant title attributes”.

  9. Hiya,

    just a quote note to add that voice over in tumbler / lists up uses the title element. While adding it to out of context links is not ideal, I’d for some reason changing these links is not possible it’s preferable to nothing.


    Jamie & lion

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.