title attribute gets a lot of flack. And largely the disdain towards the attribute is quite justified.
In June of 1993, twenty-four and a half years ago,
title was proposed as part of the HTML 1.2 draft. It is primarily displayed as a native tooltip in desktop browsers, and revealed when a user mouse hovers over markup elements the
title is set to. Because of this, it has been a universal usability challenge since its inception, as not all users have been consistently able to interact with it.
Faulty and outdated SEO practices along with general misunderstandings of proper usage, have rendered the
title a pariah to many developers and reinforce its poor reputation.
If all of that weren’t enough, the guidance from the W3C HTML specification is pretty damning:
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).
Accessibility support for various screen readers has come in dribs and drabs over the many years of
title‘s lifespan. In fact, it might just have more support than you’re aware of.
While more support should be a good thing, it’s actually one of the biggest problems I have with the attribute. Due to misuse, the better support gets for screen readers, the worse the experience these users may get.
Even though articles have been written, outlining dos and don’ts for the
title, time passes and some things change. With that in mind, this won’t be an article aimed to promote the use of the attribute, as I completely agree with the statement made here:
If I found a genie and it gave me one wish, it would be that web developers stopped using the title attribute
— Karl Groves 🇺🇸 (@karlgroves) December 15, 2017
So if this is where you’re coming a TLDR stopping point, then I only ask you help grant Karl’s wish.
But if you’re at all interested in the current state of the
title‘s accessibility support, want to know of a few instances where it actually may be useful, and generally want to get a better understanding of why this native HTML tooltip continually fails to live up to expectations, well, there’s plenty more to read.
When one thinks of the
title attribute, its likely in the context of links. If you’re familiar with managing media in WordPress, you may also associate it with images. But were you aware of the
title‘s accessibility support for form fields? Did you know that per the release of the HTML5 specification, the
title has become a global attribute, and can be used on any HTML element?
What does this all mean in terms of the
title‘s utility? And most important of all, is any of this actually accessible?
title could only just
In all the time that the
title has been around, most browsers still have not implemented any support to reveal the attribute’s value to sighted users that aren’t using a mouse.
That means sighted users utilizing a keyboard as their primary means of navigating the web are likely to not encounter
title tooltips. Users that rely on other means, such as voice recognition software, won’t be getting much use out of
titles either. Essentially, if hovering is not an option, then you may never know a tooltip exists.
However, there is a subset of these users that can access some
titles in their desktop browser, without a mouse. That is so long as they are browsing with Internet Explorer 10, 11, or Microsoft Edge.
That’s right, it took nineteen years, but starting with Internet Explorer 10, released in 2012, focusable elements with
titles display their tooltips after a short pause, as if they were mouse hovered.
However, one browser vendor implementing focus support does not make for a reliable accessible experience for all. And this still doesn’t do anything to reveal
titles on non-focusable elements like images. And if you’re thinking “Oh well, we could add a
tabindex="0" to these elements to they receive keyboard focus”, stop. Just stop right there.
tabindexes to non-focusable elements forces additional focus stops for keyboard users. Doing this creates a poor user experience, by breaking user expectations of what should be focusable, and results in a document taking longer to navigate by keyboard.
tabindexes aside, let’s not forget about
titles on touch devices. Unless you’re using a screen reader (more on that in a bit)
title attributes are almost completely useless, save for one element: images.
The iOS 11 screenshot from shows that the
title of an image will be displayed in the popover menu which loads when a user performs a long press on an image. This works in mobile Safari and Chrome on iOS, and Chrome on Android. But from additional testing, this may not be an inherent function of all mobile browsers. For instance, using the Brave browser on iOS, the
title of an image is not displayed when performing the same long press action.
Again, a single element revealing its
title value in a manner that’s debatably not straightforward or even good user experience (UX), is not universally useful by any means.
titles are still pretty crap — especially if used on non-focusable elements.
But what about screen readers?
While support isn’t perfect, it may be a whole lot better than what you might suspect. Understandably, if one is aware of
title‘s accessibility issues for sighted users, why would it be assumed that screen reader users get off any better?
That’s where assumptions and old information about the
title‘s support have clouded some of the advances the attribute has made.
title can be used on any HTML element, as far as screen readers are concerned, it primarily remains only (mildly) useful on certain elements.
title attribute can be used on any HTML element, it’s essentially wasted on most inline, text level elements. As these elements aren’t typically included in the accessibility tree, there’s no reason for a screen reader to look for a
title on these elements to announce.
Block-level wrapping elements can get some usage out of the
title attribute. JAWS, NVDA and VoiceOver will all announce a
title on elements like landmarks (
main, etc.) but support may vary on other elements depending on your browser pairing. For example, JAWS will not announce a
title on a
div without additional
Other wrapping elements, like lists and paragraphs, are announced in JAWS and VoiceOver, but NVDA ignores the attribute on these elements. But honestly, using
title tooltips on these elements is highly suspect. Why would you want to have a tooltip constantly appearing over a large chunk of content? Unless you are purposefully trying to hide content, which isn’t helpful, there’s little need for using the
title in this manner.
Images, form fields, and anchor links are the elements one is most likely to associate with the
title attribute. In regards to screen readers, the title attribute essentially gets a “B” grade when reviewing publicly available screen reader support charts from powermapper.com.
titles are meant to serve as descriptive text. And largely only in situations where there is no accessible name for an image, form field, or anchor element, the title will be promoted to the accessible name.
<img src="my-image.jpg" title="The 3 little pigs build their houses"> <input type="text" title="First Name"> <a href="/" title="home" style=" display: inline-block; height: 20px; width: 20px; background: url(home-icon.png) no-repeat; "></a>
Pretty much across the board, screen readers will announce the
title as the accessible name for the element in the code example. (check for yourself with this CodePen demo.)
But support aside, it’s still not a particularly good choice as a consistent means to convey accessible information. Because while the
title does provide an accessible name to elements in the absence of other sources, it is considered a fallback. Outside of some notable exceptions (more on this later), other mechanisms will always be preferred.
When using a
title in place of an image
alt, as mentioned, the
title will be used as the accessible name for the image.
But being a fallback, there are issues with that.
For one, validators will still throw an error if an
alt is missing from an image.
Additionally, if an image were to break, or were to be purposefully suppressed, most browsers would not print the value of the
title in its place.
Chrome breaks the mold here, as if there is no
title is displayed on screen. However, since we should be looking for consistency reliability, a single browser’s support continues to be inadequate.
If one wants to supply an image with additional context, a
title is a poor choice due to all of the things we’ve already covered, as well as the fact a
title‘s value needs to be strictly written so as to not cause unnecessary verbosity to screen reader users. For example:
<img src="banana.jpg" alt="A yellow banana" title="a yellow banana">
img has an
title with the same value, except that the
alt starts with a capital “A”.
This seemingly minor difference causes VoiceOver + Safari to read both values. If the image is broken, JAWS18 + Firefox will also read both values. In scenarios where the image renders, the
title is flat out ignored in favor of the
alt, even when the value of the
title are very different. NVDA also never reads the
title if an
Having a matching
title may seem silly to most, but it’s unfortunately a lot more common than one might think. As noted earlier, seemingly insignificant details, like capitalizations, can cause duplicate announcements, which unfortunately is also not unique to image announcements.
Instead, what one should be doing, is utilizing a
figcaption pattern if additional context should be conveyed to all users:
<figure> <img src="banana.jpg" alt="a banana"> <figcaption> <p>Outside of knowing this is an image of a banana, here is context, useful to all users, as to why said banana image was included here. Now you know.</p> </figcaption> </figure>
Anchor links & Form Fields
Next, let’s take a look at how the
title fares with links and form fields (specifically text inputs in this example):
To quickly summarize some of the findings:
Depending on the browser and screen reader pairing, results may not be exactly as expected, and results vary depending on one’s method of navigating a document.
For example, using arrow keys to navigate content will typically ignore the
However when using the tab key (or screen reader quick keys) typically both the accessible name and
title value will be announced.
As mentioned with images, different browser and screen reader combos will have redundant announcements if
title and accessible name values have minor capitalization differences. In some cases, identical values may still produce individual announcements depending on the screen reader + browser pairing.
This is a common misuse of the
<a href="/" title="home">Home</a>
Where developers may think they’re “helping” the accessibility of a link, it actually makes the link annoying to parse, as “home” is announced twice.
In the context of
title could be considered useful to help convey contextual help for entering data. That is if it weren’t for the fact that outside of Microsoft browsers, sighted keyboard users won’t have access to the tooltip on initial input focus.
aria-describedbys don’t play nice together. Which does makes sense:
title is to
label is to
Take the following into consideration:
<label for="un"> Set Username </label> <input type="text" id="un" title="these special characters (!, *, $, %) are not allowed" aria-describedby="error_msg"> <span id="error_msg"></span>
The above example shows an
input with a
title informing users that special characters are not allowed. Again, this information is not accessible to sighted keyboard users outside of Microsoft browsers, but let’s put that aside for a minute.
Screen readers will announce the information about special characters, and that’s a good thing. However, an issue arises if a special character sneaks in there. The error message updates and says: “You used a special character! Stop it!”. Note: I am not allowed to write error copy.
title has been overwritten by the
aria-describedby error text, so the instructions are gone and a user may not recall what special characters weren’t allowed. Boo.
While not part of my original tests, Steve Faulkner pointed out that if using a browser’s default HTML5 form validation, the
title may be used when displaying the error message for an
Check out the in line validation and
title demo here.
A quick summary of findings:
- On a Mac, Safari makes no use of the
titlein its in line validation message. Chrome does, but the validation message is not announced with VoiceOver.
- On Windows, Firefox, IE11, Edge and Chrome all make use of the
titlewith the native invalid error message that will appear when attempting to submit a form.
- With NVDA, Chrome, Firefox and Edge will announce the in line error message and
- With JAWS18, only when using Firefox will the invalid error message and
Ultimately, a visible label with clear instructions are far better for all users—including those who navigate with the aid of assistive technology—than a
title applied for just a small subset of unknown users. For example:
<div class="always-be-wrapping"> <label for="password"> Create password </label> <p id="instructions"> Use at least one special character, so as to better ensure you'll consistently forget your password and throw your keyboard out a window. </p> </div>
title usage with inputs
Even though the recommendation should be to just stay away from the
title attribute for inputs, there are actually a couple of instances where using the
title as the accessible name would be OK.
Search Inputs or inputs within tables
You’ve likely come across these patterns a multitude of times. A search input in a document’s header, where there’s no room left for a visible label. Or how about inputs (checkboxes, or text inputs) within tables, where a checkbox may be used for marking a row for edit or deletion. Or a text input so individual cell data can be modified.
In the case of a search input, there’s typically a magnifying glass as an icon within the input. The pattern is so common that the location and the icon are typically the only references a sighted user needs to understand the purpose of the input. Instead of forcing a visually hidden label, or utilizing an
aria-label to announce the accessible name of the
input, use a
title="Search site/app" instead. You’ll get a free tooltip for sighted users, and the accessible name you need for screen readers.
Regarding inputs within tables, there’s often not enough space allotted to provide a visible label for an input. However, if a table is setup appropriately with clearly defined column and/or row headings, then sighted users can probably piece together the purpose of these inputs. Again, instead of using hidden text or ARIA, try utilizing the native
title attribute to give these inputs unique accessible names.
title use cases
Outside of potential uses on
input elements, there are notable instances where the
title is the recommended attribute for accessibility user experiences.
Abbreviations, acronyms, and numeronyms (“a11y” for example) are quite useful to condense a long word, or words, into a single shorthand entity. But they can be troublesome for those that may not be familiar with the shorthand.
While it’s always best to write out the full version of the word(s) and to make a direct association with their abbreviation or acronym, the
<abbr> element, utilizing the
title attribute can help make these shorthands easier to understand for some users. For example, introduce the term by using it in full, with a reference to the shorthand:
<p> The World Wide Web Consortium (W3C)... </p>
Then, when the term is used again, wrap it with an
abbr element and set a
title value to the full term.
<p> Again, the <abbr title="World Wide Web Consortium">W3C</abbr>... </p>
abbr element is not, nor should be, inherently focusable, the
title tooltip will not be accessible via standard keyboard navigation. But people using certain screen readers and browser combos will have the
title announced to them, in place of the visible shorthand.
If you give this a whirl, and don’t hearing the
title announced, you may need to modify your screen reader’s settings. For instance, to enable this functionality with JAWS, open Settings Center and expand the Web/HTML/PDFs group. Then, expand the Reading group and turn on the abbreviation and acronym options. Blamo. The
title is announced in place of the abbreviation.
Clearly not accessible to all users, using
abbr would be considered an accessibility enhancement for those with the proper screen reader settings, and mouse users. Even though there will still be some users—like sighted keyboard users—that may not be able to access the
title, using it won’t be detrimental to their user experience. That is as long as the full term is consistently used in full, prior to its abbreviation.
In contrast to the enhancing nature of the
title on an
abbr, using a
title on an
iframe is actually important to meet WCAG success criteria, as this is a recommended way to give an accessible name to frames, using the native HTML language alone.
<iframe src="http://scottohara.me" title="Scott's website"></iframe>
title serves to provide screen reader users an understanding of the contents of the
iframe. Having an understanding of the
title will give them context for the content they are about to engage with and will put any content a user encounters within it into perspective.
e.g. “Why does the author’s tone change so much? Oh, wait, it’s because this is a different website altogether. Fantastic. Get me out of here…”
title on a
In the last example of using the
title attribute, documents that provide alternate themes (different style sheets or
styles in the
title may be used to label each of the stylesheets for user selection in the browser chrome. For example:
<link rel="stylesheet" href="normalize.css"> <link rel="stylesheet" href="app.css" title="Default Theme"> <link rel="alternate stylesheet" href="app.dark.css" title="Dark Theme"> <style title="Dark Theme"> /* dark styles go here */ </style>
In the code snippet, the normalize.css stylesheet and the app.css will load by default, as normalize.css has no
title attribute, and the app.css stylesheet does not have a
The CSS in app.dark.css and
<style title="Dark Theme"> should not render in browsers that respect the use of the
title attribute on
style elements. If you give this a try, I strongly suggest checking in all browsers anyway, just to be safe.
If using Firefox, one can then go to the Firefox View menu, select Page Style, and then select No Style, Default Theme or Dark Theme.
As this usage of the
title attribute doesn’t have wide support from other browsers, it’s a good example of the attribute putting on its gym clothes, doing some mild stretching, and then binge-watching Netflix.
It’s really a shame because offering alternate style sheets could be an ideal way to ensure users could choose the best manner for them to view a website or app. For example, want to support browsers that don’t support the reduced motion media query? Well, it’s too bad they also likely don’t support an alternate stylesheet that could revise the design, without a user having to rely on reader mode or their own stripped down user stylesheet.
Wrapping this all up
title attribute has provided glimpses of its potential usefulness. But because of some bad practices and inconsistent support, many title attribute use cases are pointless at best—or actively harmful—to those who can access them.
The continued lack of support from all browser vendors to reveal
titles to non-mouse users, and just the fact that tooltips in general call out inadequacies with user interfaces, should deter their usage for more straightforward and always accessible content.
More information and acknowledgements
Please see these additional resources for more information about
- W3C HTML Specification – The title attribute
- W3C Specification for
- Change proposal pertaining to
- Don’t Rely on the Title Attribute for Accessibility