For the past 7 years myself and others have banged on about the trouble with the title attribute in regards to accessibility and usability. Bottom line is that it is not well supported in browsers and its usefulness is severely compromised as a consequence. All browser vendors are aware of the issues in regards to keyboard and touch based interfaces and yet have made no movement or commitment to implement improvements in the 19 years since it was originally specified in HTML.
HTML5 codifies the authoring of inaccessible content
Furthermore we still have the authoritative document for understanding how to use and implement HTML, illustrating and advocating title attribute use in terms that promote and codify inaccessible content. While at the same time the HTML5 specification does not mention the real world documented usage methods for the title attribute that actually help users with disabilities, because the editor of HTML5 refuses to allow it.
The W3C HTML5 Recommendation warns against use of the title attribute:
Warning! 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).
Examples of HTML title attribute use and abuse
In the linked document title attribute usage examples I have provided some data of title attribute use on a range of popular sites. The examples illustrate that the title attribute is widely misused.
When to use the title attribute: simplified
- Do not use the
titleattribute, on any element, for any text that you want all users to have access to. - Only use it to label a form control when the same text is provided as visible text.
- Do not use it on a link to provide information that may be important to any user.
- If in doubt, read: Using the HTML title attribute
Further reading:
- Reasons to not allow the title attribute to be used as a substitute for the alt attribute in HTML5
- Reason to not promote the use of the title attribute for footnotes in HTML5
- Reasons for not promoting the title attribute as a container for captions in HTML5
- title attribute definition does not match reality
Comments
One of the ways I am currently using the title attribute is to make up for a deficiency in html user agent implementation of the time element. For example (use square brackets instead of angle brackets):
[p]As of [time datetime=”2012-01-23″]today[/time] I still have not heard back.[/p]
I have my software go through and change it to
[p]As of [time datetime=”2012-01-23″ title=”January 23, 2012″]today[/time] I still have not heard back.[/p]. I then use CSS to add a light dotted underline to any time element that has a title attribute, similar effect to the way abbr is often rendered. That way someone reading the content can get context to what today is, something that browsers should support but do not.
I know that the date will not be available to someone without a mouse, it’s tempting to also set tabindex and then use JS onfocus to show the tooltip effect, but that may actually be more annoying then beneficial, I don’t know.
I could just put the date in instead of “today” which may be the result of what some screen readers do anyway, and in the example above that probably would be better, but in some cases it really doesn’t read as well to specify the full date in the paragraph itself. I thought using the title attribute w/ css to underline was a clever way to provide context for users who wanted it, context that should be made available by browsers when that tag is used but currently isn’t.
I’ll have to think about it some more. I really like the ability to add a timestamp via the time element and wish browsers implemented a way to let users know the context of the time stamp when it is provided. I don’t understand why it would even be part of the spec if it isn’t going to enrich the user experience, which is what I’m trying to do by using the title tag.
One thing I did do after reading about problems with redundant title tags is I changed my code to only put the title in when the date is not clear from the text itself. IE if I have [time datetime=”2012-01-23″]January 23, 2012[/time] then I don’t have it add a title tag because it is redundant and doesn’t add to the user experience for anyone.
It’s a perennial issue for anyone in touch with accessibility and must be the one thing I hear advocates scream about more than anything else. Personally I hate title attributes in any form, I hate the little yellow box that unhelpfully pops up to say something inane. It’s an element left over from the early iterations of the web and doesn’t have a role an a modern website.
It’s also bad SEO to be dropping titles everywhere, they don’t do anything. Half the time you see titles covering empty alt attributes to boot.
What do you guys think about using titles when an image (with an alt text of course) is a link? It’s probably the one area I can cope with titles but I still can’t bear the sight of tool tip boxes – who decided they were going to be that drab post-it yellow colour?
Hi Luke,
Depends on what the
titlecontent is, if it is information that you would like all users to be able to access don’t use them. I wrote a post about providing captions for images using the new HTML5figureandfigcaptionelements which may be helpful. One the examples provided is for captions that appear on hover/focus. The appearance of tooltips is reliant upon the OS, which is why they look like they do.Hi Alice, sounds like you are trying to do the right thing to avoid redundancy. I don’t see a problem with use of the title attribute if the information required to understand the content is available in text for all to access.
Thanks Steve,
That about sums it up for me. I want all users to get all information. The captions option looks a good one – I’ll play around with that where I can. Someone should have a word with the OS – aesthetically, it’s like having tiny post-its stuck to your screen then peeled off again.
Steve,
When you say, ” use it to label a form control when the same text is provided as visible text”, I suppose you mean like a form in a data table where both the row and column header need to be associated with the field, right?
Else explicit label association is the best way for visible text placed as next to / above the field to serve as labels, no?
And when fields do not have visible label text because it is pretty obvious in the context like a single search field next to a search button, a title attribute on the INPUT is handy for benefit of non-visual users. This is widely supported by AT unlike the aria-label which essentially serves the same purpose.
The other issue is Firefox does not expose the alt when moused over on an image but it exposes the title. An example of incorrect rendering of the title and a disregard of the alt.
Sailesh
Hi sailesh, there are 2 main scenarios where I think it is appropriate:
A textbox with a button to the right which visually identifies the text boxes purpose.
In data tables that contain inputs and the table header cells provide the visible labels
unsure what you mean here?
My “Google fu” has failed. 😉 I’m trying to find a good search string that will describe what I’m looking for, and in frustration, I’m giving up and asking: I have a table and at the intersections of some rows and columns, I have a bullet — well, actually, a Unicode character that actually pays attention to the font-size style, in contrast with the actual bullet entity. If beaten into submission, I suppose I could substitute each bullet with an img, but I’d rather not. My question: How can I provide alternate text for what is, in effect, text, not an img. (I *want* to use alt=”” on a non-img span but I also want to stay with HTML5 compliance.)
Hi Kevin, can you provide a link to an example?