Using the HTML title attribute – updated March 2020

Sideways view of the pride of Dunnington, AKA The Common Drain

Takeaway

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.

The details

The HTML title attribute is problematic. It is problematic because it is not well supported in some crucial respects, even though it has been with us for over 23 years. With the rise of touch screen interfaces, the usefulness of this attribute has decreased. The accessibility of the title attribute has fallen victim to a unfortunate combination of poor browser support, poor screen reader support and poor authoring practices.

Situations in which the the title attribute is not useful due to lack of support:

  • Displaying information for web content viewed on mobile phone browsers. Typically in desktop browsers title attribute content is displayed as a tooltip. From what I could find, tooltip display is not supported in any mobile browser and alternative visual methods of accessing title attribute content are not supported.
  • Providing information for people who cannot use a mouse. Typically in desktop browsers, title attribute content is displayed as a tooltip. Although the tooltip behavior has been supported for 20+ years, no current browser has an implemented practical method to display title attribute content using the keyboard.
  • Using it on most HTML elements to provide information for users of a variety of assistive technologies. Access to title attribute information is not supported uniformly by screen readers

User groups not well served by use of the title attribute

  • Mobile phone users.
  • Keyboard only users.
  • Screen magnifier users.
  • Screen reader users.
  • Users with fine motor skill impairments.
  • Users with cognitive impairments

Examples of title attribute use that are USEFUL:

  • Labeling frame or iframe elements:
    • <frame title="navigation">
  • Providing a programmatically associated label for a control in situations where a visible text label would be redundant:
    • In 2010<input type="text" title="search"> <input type="submit" value="search">
    • Now in 2020 a better method for doing this is using the aria-label attribute
      • <input type="text" aria-label="search"> <input type="submit" value="search">
    • In 2010 labeling controls in data tables
      • <td>
        <input type="text" title="quantity of pens">
        </td>
    • Now in 2020 a better method for doing this is using the aria-label attribute or the aria-labelledby attribute.
      • <td>
        <input type="text" aria-label="quantity of pens">
        </td>

Examples of title attribute use that are NOT USEFUL or are of LIMITED USE:

  • For additional information not provided as text in a link or surrounding content:
    • <a href="newsletter.PDF" title="PDF file, size 1 mb.">newsletter</a>
    • Instead include such information as part of the link text or next to the link.
  • Providing the same information provided as link text:
    • <a href="newsletter.PDF" title="newsletter">newsletter</a>
    • Recommend not duplicating content of a link in the title attribute. It does nothing and makes it less likely if people can access title attribute content that they will do so.
  • For a caption on an image:
    • <img src="castle1858.jpeg" title="Oil-based paint on canvas. Maria Towle, 1858."
      alt="The castle now has two towers and two walls.">
    • Presumably caption information is important information that should be available to all users by default. If so present this content as text next to the image.
  • For a label on a control that has no visible text label:
    • <input type="text" title="name">
    • Screen readers users will have access to the control label, as the title attribute is mapped to the accessible name property in accessibility APIs (when a text label using the label element is not supplied ). Many other users will not. Recommend including a visible text label whenever possible.
  • Providing the same information as a visible explicitly associated text label for a control:
    • <label for="n1">name</label> <input type="text" title="name" id="n1">
    • Repeating the visible label text does nothing except possibly add cognitive noise for a range of users. Do not do it.
  • Providing additional instructions for a control:
    • <label for="n1">name</label> <input type="text" title="Please use uppercase." id="n1">
    • If the instructions are important for using the control correctly, then provide them in text near the control, so they can be read by everyone.
  • Expansion of an abbreviation:
    • <abbr title="world wide web consortium">W3C</abbr>
    • The title on the abbr element is well supported by screen reader software, but its use is still problematic, as other user groups cannot access the expansion. It is recommended that the expanded form of an abbreviation is provided in plain text when it is first used in a document, and/or a glossary of terms that provides the expanded form is provided. This is not to suggest that that the expansion cannot be provided using the title attribute, only that due to its limitations, an expansion in plain text also be provided.

HTML includes general advice on use of 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).

source: HTML – the title attribute

Further Reading

Categories: Technical

About Steve Faulkner

Steve was the Chief Accessibility Officer at TPGi before he left in October 2023. He joined TPGi in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including ARIA in HTML and HTML Accessibility API Mappings 1.0. He also develops and maintains HTML5accessibility and the JAWS bug tracker/standards support.

Comments

Paul J. Adam says:

Hi Steve, thanks for the great post. I disagree though with the statement that title attributes are not useful for Screen Magnification users.

I’ve worked with Low Vision, ZoomText users and when they are zoomed in at very high magnification levels the title appears as a tooltip when they hover over an HTML element with their mouse. When an image or GUI component is huge, pixelated, and cut off from the screen the title/tooltip can help them understand what they’re looking at.

It seems to me that mobile & desktop browser developers should make the title/tooltip appear on keyboard focus or during a tap and hold gesture on touch devices.

I know it’s not a perfect solution for mobile, but couldn’t you at least try img::active:after{content:attr(title)}

If you set a tabindex to an HTML element, doesn’t that make it focusable on the keyboard, even if it wasn’t a focusable element by default?

If that is the case, then you could do:
img::focus:after{content:attr(title)}

I know this isn’t an accessible solution, but doesn’t this resolve the issue for the mobile, keyboard, and screen magnifier groups?

I should add, too, that this solution works fine on mobile.

::after has been supported in CSS2.1, which goes back to IE8, and ::before is CSS3, which is IE9+ .

Here’s a sample of how it could be used: https://cssdesk.com/apBwH

Steve Faulkner says:

hi Frank, do you have a working example of:
img::focus:after{content:attr(title)}

Jörn Zaefferer says:

What about using the title attribute together with a tooltip widget like the one in jQuery UI? See https://jqueryui.com/tooltip/

That one works for keyboard users, as the title is displayed on focus (not just on moueover), as the ARIA authoring practices recommend. It also adds an aria-describedby attribute to the tooltiped element, giving screenreader access to its tooltip content.

While the tooltip widget doesn’t require you to use the title attribute, it still seems like a reasonable default. Maybe one day browsers will even display a native tooltip on focus like jQuery UI does, instead of telling everyone to stop using the attribute.

Steve Faulkner says:

Hi Paul,
I too have worked with screen magnifier users and found that at high magnification levels users found it difficult or worse to read tooltips that consisted of more than a word or two.

It seems to me that mobile & desktop browser developers should make the title/tooltip appear on keyboard focus or during a tap and hold gesture on touch devices.

Perhaps they should, but have chosen not to, even though they are well aware of the inability to access tooltips on mobile/tablets. I think part of the issue is that the desktop tooltip paradigm does not fit well with the mobile/touch UI. It is interesting to note that the instances of the title attribute on the http://www.apple.com are practically non existent (I coudl only find one).

Steve Faulkner says:

Sure, but why bother with the title attribute at all, just use the tooltip widget.

Spudley says:

One of the uses I like for the title attribute is in conjuntion with data that is truncated by a CSS ellipsis. In these cases, I put the same string into the title attribute so that mouse users can hover over it and see the full text.

I’m sure there are other ways of achieving this but it works for me, and I don’t think it detracts from accessibility because the content is there in full in the element anyway for screen readers, etc.

Steve Faulkner says:

Sure, if the content is not important and you are not bothered that users on tablets or mobile devices cannot access it, then use away.

Hmmm… you are right that mobile browsers don’t seem to show the contents of title (at least on Android where I tested) but the Google Reader app for Android, which presumably uses the embedded web view, has a View Caption option on long press which does show it. Not sure why that should be different from browser behaviour.

Taras says:

I think title is still a big deal mainly thanks to its SEO/SEM role as search engines still care a lot about page titles

Steve Faulkner says:

This is not about title element, used for page titles, it’s about the title attribute.

Ian P says:

Even so, I believe there are some quarters that would argue that contextual title attributes on links would bring some SEO value.

Steve Faulkner says:

fine, if you don’t expect the info to be available to actual users, only search engines, then use away.

simon kerr says:

how about links that are duplicated on a page? for example a link within a top level navigation and the same link within the body of a cms page? they need to be differentiated in some way, don’t they? and you can’t really put “link name (top nav)”within the link itself. what do you suggest?

Steve Faulkner says:

Hi Simon,
if the links point to the same URL, then it fine if they have the same link text. If the links point to different URL’s they should have different link text.

Ryan Benson says:

In addition to what Paul said, the title attribute can cause confusion with screen mag users. While some say this is just a known bug and to ignore it, titles on links will read the title versus the linking words. So for users that need audio and visual feedback, this could throw them off.