[S]upport aside, it’s still not a particularly good choice as a consistent means to convey accessible information. Because while the
titledoes 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.
titleattribute 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
titleon these elements to announce.
Block-level wrapping elements can get some usage out of the
titleattribute. JAWS, NVDA and VoiceOver will all announce a
titleon elements like landmarks (
main, etc.) but support may vary on other elements depending on your browser pairing. For example, JAWS will not announce a
Other wrapping elements, like lists and paragraphs, are announced in JAWS and VoiceOver, but NVDA ignores the attribute on these elements. But honestly, using
titletooltips 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
titlein this manner.
Images, form fields, and anchor links are the elements one is most likely to associate with the
titleattribute. 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.