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
Comments
As you said in the first sentence “not well supported” is correct; although it is supported by those who care and those who want to use it properly. Obviously a Browser issue not a Web developers issue. Preach to Mozilla, IE, AT tech developers not web developers.
Surely if you ignore a browser issue and this causes user issues then that in itself is something a developer should be concerned about?
Regarding the use of @title with abbr, my tests with various screen readers returned the following:
Jaws 10-11 : turned off by default
Window-Eyes 7.02 : turned on by default
NVDA : not supported (no support options)
VoiceOver : not supported (no support options)
Therefore, clearly not a recommended practice.
Hi Henawder,
I am not preaching to anybody. I would presume as a developer one would find it useful to understand the limitations of the technology being used. You can do what what you want with the information.
some people are like a cloud when they leave it brightens up everyones day. nice artical it’s on of the simple things that alot of developers forgat about over time. many thanks for the reminder.
Isn’t writing for browser behaviour, and not to HTML specs, only compounding problems?
For us slack people who find explicitly associating labels with input fields a bit tedious, WCAG V2 Guidelines allow use of the title attribute instead. If you don’t explicitly associate labels with input fields, the title attribute is a quick and easy way of removing ambiguity for screen reader users. If I had a dollar for every poorly marked up form…
Title attributes are important. Period. They are more so when developers do slipshod work in associating labels with their respective controls. Moreover, on forms, when a screen reader does not voice labels of required fields –it clearly impinges on equal access. Well then, title attributes serve as a solid fall back option. It is a commonly reported defect whenever an asterisk in front of a label does not voice. Concerning screen readers, most users I know configure them to voice title attributes on a form field. As far as a keyboard only user is concerned, if the link text can stand on its own, they really would not care what the title attribute is. In addition, with custom tags, it is now possible to make these title attributes / tooltips accessible. There are ways, sometimes impossible, but certainly attainable.
Hi Andy,
continuing to use the title attribute in the hope that it may one day it may be implemented accessibly is compounding the problem.
hi Devarshi,
you wrote:
“Title attributes are important. Period. They are more so when developers do slipshod work in associating labels with their respective controls.”
I don’t quite get this line of reasoning, if they do slipshod work in associating labels why would they not do slipshod work in providing title attribute content?
“Moreover, on forms, when a screen reader does not voice labels of required fields –it clearly impinges on equal access. Well then, title attributes serve as a solid fall back option.”
Yes, titles can be used for providing explicitly associated labels on controls in certain cases, as I said in the post.
“It is a commonly reported defect whenever an asterisk in front of a label does not voice.”
and your point is?
“Concerning screen readers, most users I know configure them to voice title attributes on a form field.”
Most screen reader users I know don’t, anecdotal evidence is not much use. What can be said, is the default behaviour for screen reading software in general is to read only an explicitly associated (using the label element) text label if there is one and announce the content of the controls title attribute if there is one, but no explicitly associated (using the label element) text label. It is not default behaviour for both to be announced.
“As far as a keyboard only user is concerned, if the link text can stand on its own, they really would not care what the title attribute is.”
If the title on a link is not useful to someone simply because they cannot use a mouse, why would the content be useful for mouse users? Why bother in the first place?
Hi Steve – First of all, thanks for throwing light on this elephant in the room full of what to use and what not. There are some variables here. We may not agree on all of them but the consensus does go with using title attributes while appreciating its use—A point you succinctly made in your post. Regarding the slipshod work, it applies to developers that firstly do not empathize with disabled users and do not want to change their coding style. With such developers, achieving accessibility without getting into the for and id associations, just telling them that by supplying title attributes, though imperfect, is the simplest task (of getting one step closer to compliance) under the sun. For example, a developer responsible for coding numerous controls will be more forthcoming in supplying title attributes to controls in achieving accessibility rather than going the extra mile fixing the label and control associations.
Coming to your second point about whether a screen reader should favor a title attribute or not, I would say it should be since that how I use it. That is subjective. We have our own preferred ways. Assistive Technology vendors need to be consistent. If one screen reader does not default to title attributes while the other one does only shows that blindness is perceived differently, which basically is constant.
Type of application, context, timeframe, supervisors, end users, accessibility-aware peers etc. will drive this discussion in different directions. For example, take a large complex data table with multiple controls spanned across one end of the table and explanatory labels on the other. Someone can argue that we don’t need title attributes on complex data tables giving the reason that table navigation keys would be sufficient. Well, what if a screen reader or for that matter a screen magnification user prefers a forms list to access this table data and starts complaining about the missing title attributes? If my screen reader is configured to voice labels, am I getting the supplemental information via title attributes on pulling up the forms list that a developer coded into those multiple controls? I don’t think so.
Coming to the third point, what if a keyboard only user would like to see the association in the grid when the keyboard focus indicator is on a link on one end of this large table? I would prefer a title attribute on the link aiding me spatially even though the link text is self-sufficient. In that case, exposing that title attribute to a keyboard only user becomes important, although I have seen very few cases of that.