The title attribute is an accessibility fallback

[S]upport 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.

[…]

While the 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 (header, footer, 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 role updates.

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.