Using the HTML title attribute – updated

Posted on Tuesday, 15 January 2013 by Steve Faulkner

tl;dr

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 14 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 behaviour has been supported for 10+ years, no browser as yet has implemented a 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:

  • Labelling 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:

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 should not be provided using the title attribute, only that due to its limitations, an expansion in plain text should also be provided.

HTML 5.1 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 apear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet).

source: HTML 5.1 – the title attribute

Use of the title attribute in place of an alt attribute on an img element or for an image caption is prohibited

Relying on the title attribute is currently prohibited as many user agents do not expose the attribute in an accessible manner…

source: HTML 5.1

Further Reading


About Steve Faulkner

Steve is the Senior Web Accessibility Consultant and Technical Director, TPG Europe. He joined The Paciello Group in 2006 and was previously a Senior Web Accessibility Consultant at Vision Australia. He is the creator and lead developer of the Web Accessibility Toolbar accessibility testing tool. Steve is a member of several groups, including the W3C HTML Working Group and the W3C Protocols and Formats Working Group. He is an editor of several specifications at the W3C including HTML 5.1, Using WAI-ARIA in HTML and HTML5: Techniques for providing useful text alternatives. He also develops and maintains HTML5accessibility

Comments

  1. 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.

  2. 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?

  3. What about using the title attribute together with a tooltip widget like the one in jQuery UI? See http://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.

  4. 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).

  5. 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.

  6. 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.

  7. 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?

  8. 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.

  9. 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.

Comments for this post are closed.

Recent Posts

See all posts in the blog archive

Having worked in accessibility for quite some time I can tell you that TPG's Steve Faulkner is one of the top technical accessibility talents, and leaders, in the field and I have no reservations in giving him my endorsement.

Richard Schwerdtfeger, Distinguished Engineer and CTO for Accessibility of IBM Software