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
titleattribute 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 accessingtitleattribute content are not supported. - Providing information for people who cannot use a mouse. Typically in desktop browsers,
titleattribute 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 displaytitleattribute content using the keyboard. - Using it on most HTML elements to provide information for users of a variety of assistive technologies. Access to
titleattribute 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
frameoriframeelements:<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-labelattribute<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-labelattribute or thearia-labelledbyattribute.<td>
<input type="text" aria-label="quantity of pens">
</td>
- In 2010
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
titleattribute. It does nothing and makes it less likely if people can accesstitleattribute 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
titleon theabbrelement 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 thetitleattribute, only that due to its limitations, an expansion in plain text also be provided.- Read Short note: The abbreviation appreciation society for further details
HTML includes general advice on use of the title attribute:
Relying on the
titleattribute 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
- title attribute use and abuse
- The title attribute – what is it good for? (resurrected)
- The Trials and Tribulations of the Title Attribute (2019)
Like to be notified about more articles like this? Subscribe to the Knowledge Center Newsletter. It not only gives you summaries and links to our technical blog posts but also TPGi webinars, podcasts, and business blog posts – as well as accessibility and web tech conferences and other events, and a reading list of other relevant articles. You get one email a month, it’s free, requires just your email address, and we promise we won’t share that with anyone. Check the archive.
Comments
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
hi Frank, do you have a working example of:
img::focus:after{content:attr(title)}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.
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.
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).
Sure, but why bother with the title attribute at all, just use the tooltip widget.
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.
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.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
This is not about
titleelement, used for page titles, it’s about thetitleattribute.Even so, I believe there are some quarters that would argue that contextual title attributes on links would bring some SEO value.
fine, if you don’t expect the info to be available to actual users, only search engines, then use away.
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?
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.
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.