I use them on Dutch pages where the owner wants to follow the hip and trendy “Home” for the home page, while plenty of older people aren’t sure what that is (and it gets pronounced “homeh” or “homa” for them, or they look for a word spelled “hoom” like Grandma wrote on a note to us recently), so I often have home links (but not other links) stating “hoofd pagina”. It’s a language thing, and eventually “Home” will just be an internet norm for Dutch pages. But it’s not there yet.
The only way I’ve been able to make JAWS take a pause after the titles is to actually add a “.” at the end.

I use them when doing image replacement on logos, who are also usually links to the home page. Usually the text behind it is “Company Name”, the anchor has no text at all but the title, mostly telling people that yes, this logo is following the convention of linking to the home page. What screen readers get is “Company Name link Home Page” (”link” being the reader itself, not my title text).

I use them on inputs where for whatever reason, a question in a form is not in a form control (and thus not read out). Visual users, even keyboarders, get the p or h3 or whatever the non-form-control is. I nipped this one from Juicy Studios.

I use them on anchors wrapping thumbnail images who have no alt text, stating “larger image” (in Dutch tho) as that’s the purpose of the link, and there is no link text. Keyboarders get the suck end of this, though on a repetitive page such as a shopping cart page, one time clicking on a thumb shows you exactly what all the rest of them do. A better way to do it would be to have text announcing this right before the thumbnails, but I can’t always afford to do this.

For CSS “image maps” (usually lists) I do not use title attribute, I’ll pull a span or something offscreen and have it appear just like a title on focus or hover, since I’m already adding anchors over the map. However, I’m not sure it’s worth the pile of extra CSS and the rigidity necessary to do this for other things people like to stick titles on (like links on plain old menus). Image maps can afford to be sized in pixels, since their image is sized in pixels. Menus however need to scale, as does regular body text and anchors.

Using tooltip spans in the middle of text has been done, although Opera had a nasty bug that appeared with that, if you scrolled the page or something. Not sure if that’s been fixed in 9.6, but it was in 9.5. Something to do with an absolutely positioned child span inside a relatively positioned inline element.

I have used title in forms for when a label is also a link to something (a larger page with further explanations, to open an Excel sheet, to open a PDF) back when I was forced to open those things in new windows (with the deprecated target atty) as the back-end could not always keep filled-in but not-yet-submitted information, and having someone click a supposedly “helpful” link, only to go back with the back button to find their browser isn’t caching (you can never count on people having brower caching on) prompted this. So the anchor had a title stating that the whatever opened in a new window (later I managed to change the PDFs to just opening the PDF reader, but I still kept the titles stating this was a link to a PDF). Using Javascript was not an option.
Luckily nowadays we can track people with sessions, no need for target, though they tend to miss folks like me because I don’t accept cookies (like many other web surfers. Still using titles on anchors to state the link is a pdf, along with a background image. Worst comes to worst, people clicking on it get prompted by their OS what they want to open this PDF with, which they can cancel and go back to the page.

I use tooltips regularly on icons, whether they are anchors or not. To this day, I remember my mother driving the car and saying “I wonder, what does the little flag in the water mean again and why is it glowing?” Thus, I usually turn images off where there are lots of icons so I can read them, but a tooltip often does the same job for me. It’s too helpful when you’re being dictated to by a stringent graphic designer and you cannot add any real text or there’s no room (the purpose of the icon in the first place). Keyboarders get the suck here too, but that isn’t going to stop me from trying to at least make it useful to SOME people. I hate icons.

I’ve avoided name attributes, from back when I thought I was writing XHTML (it’s not deprecated in 1.0 but it is after that, as “name” was reserved for other things) and it’s a habit that’s stuck. That and I don’t suppose names should never be read out, those are for internal use only (just like on form inputs).

That keyboarders can’t get tooltips on :focus is the fault of the browser vendors and I lay the blame at their feet. They’re so busy adding gee-whiz factors and trying to implement that HTML5 junk, while leaving other things in the back field.

<a href=”…” …>Read more<span style=”hide me off screen”> about XYZ</span></a>

One solution that I came up with was an anchor that has the short Read More and a span that has been positioned off screen with a fuller description added after it. That way, there is a single link. The visual formatting has Read More only, but the extra information is read as well because it is part of the same link. Eg of code Read more about XYZ. Would this be an accessible solution?

Thanks for the great article

However, the solution is definitely NOT to abandon the W3C standards in order that site visitors can cope with what is there at the moment. There are few more disability aware bodies than the W3C. All their standards are built on foundations designed to maximise accessibility. If authors stuck to those standards the problems that he cites would not exist.

Authors are at fault, I don’t deny it. But it is just as often site visitors with hardware and software that is inappropriate, poorly set up for their needs, or plain ill used though lack of training or knowledge. (Maybe, for some disabilities the hardware and software that is needed doesn’t exist yet.)

Far from helping, in the long run BIM’s “solutions” are self defeating and will only make the situation worse. The right approach is for authors to adhere to the standards and site visitors to to get the right tools for them and the knowledge on how to use them.

Some XHTML validators will fail many sites if title tags are omitted.

The title attribute can also be a useful tool tip for the user (who may not need accessibility) who needs usability tips (e.g: silver surfers - those new to the web etc) - Web sites have different designs (so inconsistent with each other) in particular hyperlinks underline decoration. Some underlined pre-rollover and vice-versa, so the title is useful where the default hyperlink CSS style may not be so obvious to some.

All your comments are mostly related to disability, which is understandable. For me - alt is for alternative for image - title is a tool tip in my experience.

I really want to make the sites I work on as accessible as possible
and having read this, I now know I have been doing too much. The
irony is that I had just coded a page with TITLE in every text link
and then thought I would check on it’s correct usage.

I am going to remove them now, even from images unless they are
absolutey needed. It would be good to have a check list to follow,
based on this article and not the W3C guideline, on how we should
be applying TITLE for humans and not some standards checker.

Currently (before my mass link TITLE mission I have just stopped)
I was under the impression that all images should have ALT. This
is to replicate any text on that particular image. TITLE should be
used to expand that description if needed. For example….

I have been in e-commerce for over 5 years now and during that
time the the ALT has always been needed and more recently the
TITLE has been encouraged, even though it has always been
there. One of the biggest things, based on the rules I thought
I knew is ‘Buy’ buttons. This is how I currently do it:

where BOOK TITLE is
the actual book we want to sell.

Based on this article I should have:

Is this correct? What about the LONGDESC attribute. Does this get annoying too?

Unfortunately we do have many links on our site that say “View
more” and this is where I was at before this article. I am now going
down the route of the invisible text next to these for better clarity
but any advise on the ALT verses TITLE on images would be a
great help.

If you want some help setting out a guidline for the use of TITLE I
would be more than happy to help.

Bim

This is often difficult to implement for content-led sites like those of magazines and newspapers, who often have a CMS that requires blurb text on a front page plus link text. If you have trailer text for ten stories on your home page, how many ways are there of saying “read the rest of this article”?

Some more web-savvy writers have asked if it’s OK to repeat anchor text if the TITLE text is different — glad we can deny them that get-out! If their CMS allows, our advice is usually to write intuitive, scannable headlines and make those the links — I’d say that convention is well enough established now that users don’t need a separate link (this is what BBC News now does).

Martin