Time to vent some steam about the TITLE attribute. This, almost more than any other item in the web author’s toolbox, seems to be misunderstood and overused.
The TITLE is an essential attribute for some elements, such as ACRONYM or ABBR, and is a required attribute for FRAME elements where it provides contextual information that wouldn’t otherwise be obvious to screen reader users.
Unfortunately though, it can be applied to almost any HTML element. Most often we see it on links and images, where it can confuse or even mask essential information. It can create issues on other elements, but for this article we’ll concentrate on the damage it can do to clear link text and images with good ALT attributes. Often creating classic examples of too much accessibility.
Users and TITLE attributes
Before going into the reasons why the TITLE attribute can create accessibility problems, lets look at who can, and who can’t “benefit” from information presented in that way.
- Keyboard only users: would never see the TITLE content, because the “tooltip” is activated only by mouse hover.
- Most screen reader users: wouldn’t hear it, unless they set their settings to do so. This would be at the expense of the ALT attribute, as two “tooltips” can’t be read at the same time. As the ALT attribute is required, and the TITLE attribute is optional, few users would choose to hear the TITLE rather than the ALT.
- Other screen reader users: notably those designed for people with low vision, as opposed to no vision, may support the TITLE attribute on links, but will also read the link text. On images they read the ALT attribute only. These readers often also read portions of text “on hover”, which is handy for locating required information without literally having to navigate to that part of the page. But if a TITLE attribute exists in the hover region it will be read instead of the visible text.
- Screen magnification users: would have their access to information in an image’s ALT attribute blocked by a TITLE attribute, especially, a null one.
- People with dyslexia: often prefer not to have “tooltips” popping up, as they can be a serious distraction to the process of reading the text. If they have moved to a standards compliant browser to get away from the ALT attribute popping up in Internet Explorer, imagine how delighted they might be to find a site that has more TITLE “tooltips” than a leopard has spots.
So we have a range of users: some who don’t have any access to information in the TITLE attribute, others who do have access to it, but have specific needs on what it contains and yet others, whose browsing experience would be improved if it were used with more discretion.
If, about now, you’re beginning to wish that the use of TITLE attributes had been restricted to elements where they are essential, join the club. Membership is free and there’s plenty of room inside.
TITLE attribute shortcomings
The enthusiasm with which many web authors employ this attribute, is enough to make some disabled users’ heads spin with the volume of repeated or irrelevant text at one end of the scale; while at the other end, users are kept completely in the dark about important information.
How can that happen you might well ask. Well, it rather depends on what the web author believes they should put into a TITLE attribute, and why. The problem is, opinions vary. This means that the quality and value of information slotted into TITLE attributes also varies … widely.
Too much information
At the head-spinning end of the spectrum, the content might be:
-
Identical link text and TITLE attribute.
This is repetition for, and may be confusing to; users who have screen readers that do read aloud the TITLE attribute. They may hear both, the link text and the TITLE attribute. Unless punctuation, or a space has been left between the two, confusion arises because the last word of the TITLE is joined to the first word of the link text. So a link, and TITLE, that both said, “Appearing in Diss” would be delivered as “Appearing in disappearing in Diss”. Most of the time of course it isn’t that neat, and a completely unrecognisable mash of sound is produced.
-
Link text with a TITLE attribute, which repeats the link text, but prefixes it with fluffy terms such as “Link to information on …” or “Click here for more about (whatever)”.
The problems here are for people with dyslexia, and screen magnification users as well as those who have screen readers that read aloud the TITLE attribute.
The dyslexic user will see the “tooltip” and may recognise that its first words aren’t the same as the link text, so rather than follow the link, they may spend frustrating time moving the mouse on and off the link to have time enough to read the “tooltip”, only to find that it wasn’t important, or even different, information at all.
Screen magnification users may never know whether the “tooltip” held useful information or not, they’re less likely to be able to see the information that follows the fluff, as their enlarged view of the “tooltip” may only be able to show the first two or three words. This may or may not reassure them that there is nothing important in the “tooltip”, usually it won’t, leaving them in doubt..
The TITLE supporting screen reader user gets both TITLE and link text, gets cross, and after a few such links is likely to head for pastures new where they won’t be sent crazy.
-
A decorative image with a null ALT attribute and a descriptive TITLE attribute.
This is the kind of use that can unnecessarily distract a dyslexic user. Images are often quite big targets, if the user is concentrating on reading some text; it’s quite possible for the mouse pointer to be moved over an adjacent image. The resulting “distraction from the tooltip” popup could mean that they have to start again. If you can’t imagine what it’s like to be unable to recognise words instantly, try reading Russian.
Hidden information
At the head-scratching end of the spectrum, the information invisible to users who don’t have access to the TITLE attribute commonly includes:
- A link’s destination. Generic link text like “Read more” is often given a TITLE attribute to explain where the link goes.
- New window warnings.
- File format or file size information.
In addition, unless images are turned off, the TITLE attribute can make other, more important information, unavailable to most users. This happens when:
-
An image has an ALT attribute and a TITLE attribute that differ from one another.
Only screen reader users would have access to the ALT attribute text, everyone else would see the TITLE attribute. Where these aren’t functionally identical, someone is losing out. One recently seen example of an image used as a link to a PDF version of a magazine, had a perfect ALT attribute, giving the document name, format type and file size, which was overridden by the TITLE attribute “Document cover”. In that case, only screen reader users had any useful information.
-
A linked image is given a good ALT attribute but also a null TITLE attribute.
In this case, nothing at all is available to people who rely on “tooltip” information, which may be most users, depending on the quality of the image. The null TITLE attribute means that no “tooltip” at all is made visible.
Using TITLE attributes
So it seems that the TITLE attribute can do real harm to the accessibility of images and links where they’re used. Can anyone give any instances where they are beneficial? I can think of only one: where a rollover image effect is required, the TITLE attribute would be needed on the link element, if the original image were rendered as a background.
Any other offers: or should we just stop using them?
Well, we’re convinced, so we’re in the process of trying to remove the little perishers from the links in the WACblog. As most of you know, this is a Wordpress template, so we didn’t put them in, but we’re going to get them out. :)
Dan | 16/05/2007 at 14:16 | Permalink
Excellent piece Bim, thank you, I’ve been waiting for this one. Let’s just stop using them on links and images, eh?
And isn’t it just a little bit ironic that WordPress is a serial abuser…?
Bim | 16/05/2007 at 14:39 | Permalink
Thanks Dan, it’s taken some time to get this one together, I’m glad it fits the bill. Irony and Wordpress seem to be cell-mates, but our technical wizard sorted out the TABINDEX issue that ruined the tab order, so I have high hopes that he’ll be able to get this one behind bars too!
JackP | 16/05/2007 at 15:11 | Permalink
It’s just like any other feature though, isn’t it? Used well, it’s a boon. Used badly…
What about those pesky “double copyrights”? You know…
© Copyright RNIB 2007
Bim | 16/05/2007 at 15:49 | Permalink
That’s agreed wholeheartedly Jack, the problem with using the TITLE attribute well, is that it seems impossible, certainly for links and most images, the needs of the affected user groups appear to be so diametrically opposed.
The Copyright and other “marks” are something else again. Another of my least favourite things. Top of my list in that vein though is the “registered mark” - ®. Probably because I happened across what could qualify as the worst case ever. It was used as part of every product name on a page full of links to products. Oh my!
Joe Clark | 17/05/2007 at 14:00 | Permalink
All the objections in your section “Users and title attributes” pertain to browsers and adaptive technology, not Web content. The problems are theirs, not ours.
Bim | 17/05/2007 at 15:43 | Permalink
Of course it all pertains to browser and assistive technology. That’s the whole point of making web sites accessible isn’t it? If you agree with the use of TITLE attributes on say, link text, what would you use it for, that couldn’t be included in unencumbered clear link text? The dichotomiesI’ve described exist now, and so do the users who suffer from an overload or lack of information. Should they stay off the web until user agents all sing from the same song-sheet?
Jenny | 18/05/2007 at 14:52 | Permalink
Browsing Jakob Nielsen’s Alterbox recently I came across an article recommending the use of Link Titles to help users predict where they are going (the article is dated 1998, with an update note in 2004).
My question is this: is the Link Title the same as the Title attribute? Any clarification would be most welcome. The article by Nielsen can be found at: http://www.useit.com/alertbox/980111.html
Bim | 18/05/2007 at 15:40 | Permalink
Hi Jenny, yes, the link title described in Jakob Neilson’s article is the TITLE attribute. While I hate to disagree with someone of his standing, the examples he gives, as good reasons for using it, also point up the type of information that people who are keyboard users would be denied. For instance, if you tab to the link of his name, there is no indication that it leads to the author’s biography, so these users get no benefit from the TITLE being there, neither do most screen reader users. The reliable way to make this information available to everyone is to include “biography” in the link text. In practice this would spoil the flow of the text that his name appears in, so it might be better to provide a separate biography link, and remove the link from his name.
He does say, in the article that the link title::
I’m just trying to clarify how very important that rule is, in practice.
Jermayn Parker | 25/05/2007 at 7:19 | Permalink
Good points but I do not think besides a link, a title has much use…
LSF | 12/06/2007 at 1:26 | Permalink
Link titles do offer benefit to users without disability and on that basis are worth keeping. How about you contact the manufacturer of browsers and assistive technology so they amend their products to manage titles better?
Annette | 26/06/2007 at 13:09 | Permalink
Thank you very much for this Bim. I’ll be referring to this info the next time the web development team of a client I’m working for insists, against my lowly freelancer judgement, that every image and link tag ‘must’ have the title attribute!
J.Sexton | 27/06/2007 at 23:31 | Permalink
As a work around to link titles, using the example from Jakob Neilson, if the use of small image icons were used within the link text with suitable alt-text for example an icon of a book with the alt-text biography, wouldn’t this both help as a visual indication of the link and its purpose without too much textual distraction to the overall context?
Great artical Bim, you’ve a new member to the club and I’ve some work to do on the Newham site.
Andrzej | 29/06/2007 at 16:14 | Permalink
Very interesting reading. I had never considered the point you make.
I have just followed the guidelines as they are set out by the W3C. I always try to make my sites accessible.
My main use of Title is on links where there is a repetition of the link text. For example on a list of news articles where I have a link at the end of the brief saying “…More…” I use the title to give say something like “More information on XYZ” To use the full descriptive text would disrupt the flow of the site. Are you saying not to use the Title and just leave “…More”
Dom | 02/07/2007 at 9:56 | Permalink
I use the ‘title’ attribute on links, I have to say, although I tend to write a description of the link (i.e. where the link goes to) rather than simply replicate the text of the link.
I also use the ‘title’ attribute on images, but it’s always the same text as in the ‘alt’ attribute, so nomatter what settings a user may have enabled/disabled within their screen reader, they should get the same information across.
I have to say, though, that I do all of that because I can, and not necessarily because I understood why. So this article has certainly cleared things up for me, and I thank you for writing it.
One quick question though: does the ‘title’ attribute help SEO in any way? I mean, surely it cant hurt your page to have ‘title’ attributes that contain keywords and key phrases? Especially in links, as the link text also helps SEO…
:-)
paul doncaster | 05/07/2007 at 20:10 | Permalink
To get away from links for a second . . .
I’m currently working to get TITLE attributes assigned to frames for my company’s product (which unfortunately makes very heavy use of frames). After submitting it to development, I was told that in a previous attempt along this line, it was discovered that frame titles produce “hover text” that sighted users found distracting, so the project was cancelled.
To date, I’ve not seen any instances in which frame titles produce “hover text,” though I would imagine it might be possible under certain circumstances. So my questions are:
1. Does the addition of a TITLE attribute to a frame necessitate the generation of “hover text” (a la ALT text)?
2. If not, what are the circumstances (if any) where the addition of a TITLE attribute could cause this result?
Paul D.
Bim | 30/07/2007 at 12:02 | Permalink
Sorry about the long delay in responding to your comments, I’ll try to pick up on all that haven’t been covered, but do feel free to send a prompt if you see one that is overlooked.
LSF suggested that we contact user agents to get a more reliable way of having TITLE attribute information conveyed.
We have contacted ZoomText, which is the screen reader that creates most problems by announcing TITLE attribute content, without giving users the option of turning it off.
However, the problem doesn’t go away, because of the variety of ways that the attribute is used. On links it is often purely repetition of link text, which is hardly likely to be of any use to anyone, sighted or not.
Could you give an instance where a TITLE attribute is a positive advantage to anyone when used on links or images please?
J.Sexton suggested a good way to replace the TITLE attribute in the Jakob Neilson example. My only reservation on this technique is that web authors will need to ensure that any icon chosen is large enough to be recognisable, and the image needs to have a close visual association with the purpose of the link.
Andrzej asked about using the TITLE attribute to expand a “More ….” link, but in the meantime I think you’ve changed your site, haven’t you Andrzej?
To clarify this though, there’s no harm in a TITLE attribute providing page specific detail on a more link, as long as it comes after a fully descriptive text link to the same page. Usually there’s a paragraph of text between the page description and the “More” link, but users who can’t hear the TITLE will soon get used to the idea that each fully described link is followed by an associated “More” link.
So this technique is only inaccessible when there’s no prior link giving the full description.
Don asked if the TITLE attribute has any effect on SEO. I know that some people think so, but don’t know if it’s true Don. I’ll try to find out and come back to you on this.
Paul D asked if TITLE attributes always do make a tooltip popup in frames. I think they do Paul, but it’s something I’ll test to see if there’s a way to avoid the “tooltip”, without affecting the audible output for screen readers.
In the meantime, the NAME attribute should give at least some screen reader users the information they need, as long as it makes sense, i.e. it describes the content, rather than the position or any other less than informative reference.
Thanks all for your contributions, and again apologies for late replies.
Bim
Web Access Centre Blog :: Better Connected, Better Results: Top tips for TITLEs | 16/10/2007 at 10:41 | Permalink
[…] Earlier this year, Bim wrote very eloquently on the subject of Too much accessibility: TITLE attributes, which, if you haven’t read it, or don’t remember what it says, is worth taking a couple of minutes to read over. […]
Martin Sach | 03/01/2008 at 1:42 | Permalink
I am working on some new pages that comprise a graphic of a map, and list of the numbered features on the map. Sighted readers see the numbers on the graphic and read the corresponding paragraph text alongside. I have been thinking of adding a title attribute to each paragraph, that will identify the category into which it falls - something that a blind reader would not be able to tell otherwise. So, the map shows numbered canal routes, the list gives the names in paragraph text and the title tells the screen reader user what type of canal it is, which they can’t see on the map. Is this a good way of doing it, a useful way to use the title attribute?
tony robins | 06/01/2008 at 3:24 | Permalink
Valid use of title. I have a navigation menu inside a
<ul title=”You are at the top of the site navigation menu.” >
Sighted users see nothing since 90% of the UL space is occupied by LI information. Screen readers such as Jaws tell the user where they just landed. “You are at the top of the site navigation menu. 20 items”
Andy | 17/01/2008 at 8:54 | Permalink
This is the sort of article I would like to read more often!
One thought crossed my mind after reading it:
What about simulating the tooltip behaviour by wrapping additional link information inside a span tag, and show this info in one way or another on hover/focus? This way, both the sighted users, the blind/visually impaired, and the keyboard users would all benefit? Or am I thinking too fast?
Would like to hear your opinions…
Andy | 17/01/2008 at 9:02 | Permalink
By the way, reading the HTML specs, they suggest using the attribute as seen below. Just a repitition of the link text itself, which really makes no sense:
Code view:
...some text...
Here's a photo of
<a href="http://someplace.com/neatstuff.gif" title="Me scuba diving" rel="nofollow">
me scuba diving last summer
</a>
...some more text...
Browser view:
…some text…
Here’s a photo of
me scuba diving last summer
…some more text…
Bim | 06/02/2008 at 14:56 | Permalink
Apologies for late responses folks. Hope the following will help:
Martin Sach, you asked about using the TITLE attribute to give screen reader users contextual information about map features, information which, if I read it right, is visually obvious. Sorry Martin, the TITLE won’t do this, as most screen readers don’t recognise or announce them. Have you thought of using CSS to position the contextual information off the page view? Negative absolute positioning of a span containing the contextual information would work for most screen readers. Even better, how about making the contextual information visible as plain text? This would help people with poor vision or cognitive difficulties, who find it difficult to recognise the visual clues.
Tony Robins, again, sorry, this information wouldn’t get through to most screen readers. However, if you decide to adopt the alternative I suggested for Martin’s map, you can leave out how many items there are, as screen readers already give that info for properly coded lists, so your text would just create repetition.
Andy, that’s an interesting idea. I’d like to see something like that working, as it would solve the problem for developers and users alike, certainly as far as links are concerned. Do you have an working example we could see? Would it work in all browsers? I do hope so .
Your other comment is well made, but WordPress has suppressed your code, I’ll do a quick edit, to reveal the code as well as the example, so that everyone can see the point you’re making.
Bim | 12/02/2008 at 21:42 | Permalink
A few comments ago Don asked if the TITLE attribute has any effect on search engine ranking. I promised to get back to you on this one.
The answer appears to be that the TITLE attribute doesn’t seem to be at all important. As far as images go, it’s a very poor relation to the ALT attribute. One site I found when researching this, had reverted to having their logo image rendered via the HTML code using an appropriate ALT attribute, after finding that the site had fallen badly in the ranking after a redesign that used image replacement, backed up with link text and a TITLE attribute. It appears to have worked, the site was the 2nd in the search results to my query.
Another site gave a clue to why people have begun to believe that the TITLE is a good SEO technique. It’s the confusion about what a tag is or is not. The fact is that the TITLE element (which is the tag), is the most powerful SEO tool in the box. It creates the page title and when relevant and coded with unique information first, it makes a huge difference.
The TITLE attribute, on the other hand, isn’t a tag, but is often called one. So people may be wasting hours getting relevant keywords into TITLE attributes for every link and image in their site, when they could achieve what they want in a few seconds careful thought about how relevant their page titles are.
.
Matt | 13/02/2008 at 11:43 | Permalink
Great article and I’ve seen it just in time!
I’m currently just putting the finishing touches to a document about SEO, in which, I was going to recommend writing relevant copy on the page and in the link text, while putting the URL of the webiste the user is linking to in the title attribute.
However, from reading your article it looks like I would be better off recommending that the copy and the link text be relevative as I have done, but recommending the URL of the website is in included in parenthesis within the copy and to avoid title attributes.
I’m hoping that this would give the requried SEO and be good for accessibility (I’m already strongly reccommending better use of alt tags).
Bim | 13/02/2008 at 12:43 | Permalink
Oh please don’t do that Matt. It’s really great that you’re thinking through ways to improve the accessibility, but I’m afraid this won’t achieve what you want.
The URI belongs in the code, not something that users should be forced to see, or hear, in either plain text or in the TITLE attribute. From an accessibility, usability and SEO perspective, it’s far better to just use a clear, unencumbered, relevant link text to the resource.
The power of links to SEO, is the increased chance of a match to the user’s search keywords. Few users would put a URI into the search engine, would they? If they already know the address, why search for it?
Thanks for bringing it up though, I hope that others will take heed too, and stop including the URI in link text.
Matt | 13/02/2008 at 13:41 | Permalink
Thanks for the quick response.
So are you suggesting that we shouldn’t display the URI at all?
I agree with your comment about not including the URI as part of the link text, but is it not useful to have it dispayed to the user somewhere on the page?
e.g. the words ‘post about use of the TITLE attribute in accessibility’ in the example below are the link.
Bim has written a useful post about use of the TITLE attribute in accessibility (http://www.rnib.org.uk/wacblog/articles/too-much-accessibility/too-much-accessibility-title-attributes/).
Bim | 14/02/2008 at 10:01 | Permalink
Hi Matt, if I’ve understood you properly, the link would use clear language, and be followed by the unlinked URI.
This would be less horrendous than including it in the link, but I can only think of one circumstance where it might be useful, and that’s if the document were to be printed. Is there another reason you feel the URI should be seen on the page?
They really are horrible to listen to, so if there’s no practical purpose to having them render to the page, I’d recommend avoiding the practice. The URI isn’t attractive, but it isn’t actually as much of a burden on the eyes as it is on the ears, when heard through a screen reader. The one in your example is announced:
“aitch-tee-tee-pea slash slash doubleyou doubleyou doubleyou dot rnib dot org dot uk slash wacblog slash articles slash too much accessibility slash too much accessibility title attributes slash”.
This obviously breaks up reading flow, and makes pages a good deal harder to read.
Matt | 15/02/2008 at 9:53 | Permalink
Point taken when you put it like that!
I suppose when you actually sit back and think about it there isn’t a reason to see it online, other than that’s what people have always done! If people are that interested in the URI they can click on the link and get it from the browser….time for a change I feel.
In addition time to look for an open source screen reader, we are just in the process of rebuilding our test machine with more up-to-date browsers, etc. While it’s great to talk about these things I’m not sure I can fully appreciate it till I turn the monitor off and listen to what the page it saying.
Thanks again
Bim | 15/02/2008 at 10:50 | Permalink
I feel you’re right Matt. Fortunately there don’t seem to be so many sites that have their http: on show these days. It’ll be good to know you’re joining the discrete linkers. :)
Firevox voicing plugin for Firefox, gives a reasonable simulation of a screen reader, or if you can limit your time listening to your site to 40 minutes, you could download the trial version of JAWS from Freedom Scientific. Not the 30 day download, the other one, it works forever but only for 40 minutes at a time, then you have to reboot before you can use it again.
Andrew | 15/02/2008 at 13:06 | Permalink
Bim - just to add to the resources you’ve pointed Matt in the direction of already, there is an open source screen reader available called Non Visual Desktop Access or NVDA for short. NVDA can be useful for developers who want to get a feel for using a screen reader on their sites. There is an interesting article on NVDA on the Paciello Group blog which discusses how NVDA compares to JAWS and Window Eyes, particularly when dealing with updating content without reloading the page. Reading this, it looks like NVDA is particularly useful for developers who want to test how accessible their dynamic content is to screen reader users.
Here are the links to the relevant information and downloads:
NVDA Project Home
NVDA Download
NVDA Documentation
Hope that helps as well Matt.
Isotoma | 03/03/2008 at 10:57 | Permalink
In praise of invisible text…
As a website accessibility feature, invisible text has long been accepted as one of the most helpful things you can do. This is text that is invisible on screen, but read out in screen readers, using CSS like the off-left……
Peter Stevens | 09/04/2008 at 1:02 | Permalink
Hello Folks,
I’m not convinced by this article at all, I’m sorry. For me accessibility
is about balancing functionality with practicality. For someone using
a screen reader with disabled hands and suffering from short-term
memory loss, repitition is vital!
Often there is a delay in deciding whether or not to follow that link,
so those few seconds whilst the “confirmation” of where the link
leads becomes vital!
There is one really peeving thing about _this_ page! Good readability
is limiting lines of text to around 12 to 15 per line. That provides the
ability to speed-read (with assimilation) and does not hurt the eyes
of people with reasonable vision have it badly hampered by trying
to follow long lines of text right across the screen.
…and No! resizing the browser window is _not_ an option.
Both the article and this page layout demonstrate excuses for not
putting enough thought into the design process. Expending a bit of
thought into how title texts are composed is by far better than just
leaving them out.
Bim | 16/04/2008 at 12:27 | Permalink
Hi Peter, I’m not sure that I understand how a potentially
confusing repetition can be better than clear static link text. The
user can easily get the link read again, if they aren’t sure where it
leads. But the convergence of a link, for instance to, “About us”,
with an identical TITLE attribute is likely to be announced
as, “About usabout us”. The only way to avoid this is to include
punctuation and spaces in the TITLE, such as “About us. “.
Punctuation in “tooltip” text is so rare, that there’s a greater
likelihood of increasing, rather than reducing confusion.
Where TITLE attributes may be useful, is in providing a call to
action, or expansion of the link text. For instance a link to “Sport”
is self-explanatory, but can mean different things depending on the
sporting season, or the content being provided on the site. Here
the TITLE “attribute could be useful, identifying the sports being
covered. Then it would be explaining the “Sport” link, without
confusion or repetition, although the link text, “Sport”, is accurate
in itself. So there are winners, but no losers.
I do take your point on the width of text in our Blog though, and
thank you for raising it. We’ve started working on a way to get this
under control, and hope to have it changed in the near future.
Martin Wake | 18/05/2008 at 12:14 | Permalink
Thanks Bim - this is a question that’s been floating around in our thinking for a while. We train people in writing for the web (as well as doing it ourselves), and one of the standard pieces of advice we give is or “Read More Considered Harmful” — unique anchor text for every separate target page.
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
Bim | 19/05/2008 at 10:12 | Permalink
Glad it’s helped Martin. From a screen reader user’s perspective, it would be good to see an end to “Read more” links. Although, if they follow a full and clear link, there is an argument that they are useful for dyslexic people. However, I haven’t been able to find any research to either support or refute this argument. Has anyone else?
Bim
Jason | 05/06/2008 at 9:52 | Permalink
I am blown away with this whole article, in a good way. I have
to really consider my future design work and instigate where
and how we now use the TITLE attribute.
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.
nick cumber | 21/07/2008 at 13:31 | Permalink
What you say is mostly logical - however you may not realise that many clients rely on 3rd party audits like yourself and trust the outcome of a paid audit - and some are less concerned with real usability than others. One i came across is ’sitemorse’ product which will automatically fail pages where hyperlinks have no title tag - so then the supplier is left with an argument to solve over who is correct.
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.
Greg Chapman | 09/09/2008 at 23:51 | Permalink
The trouble with the BIM view is that it is totally reactive. His “solutions” are a combination of coping with what web authors and browser/reader publishers currently inflict upon us. (I am sympathetic - most of the web is a mess!)
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.
Marc K | 14/01/2009 at 15:58 | Permalink
So I’m now wondering what you all think of the use of the title attribute to announce the accesskeys of the navigational links, on the Natwest online banking site for example? I’ve copied this technique for a university webdesign project, but I’m realising that this could be rather annoying…
Marc K | 14/01/2009 at 15:59 | Permalink
Regarding the accesskeys, I was sure to stick with numbers rather than letters.
JP Spear | 12/03/2009 at 3:15 | Permalink
I am trying to figure out a way to elegantly do both the short and sweet “Read more…” link as well as a fully accessible version. The short version is often preferable due to how easy it is to fit it into the design of the page (shorter lines are less likely to be forced onto a new line). However, some users will not have access to the visual cues of positioning, and need more info.
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
JP Spear | 12/03/2009 at 3:17 | Permalink
The code did not post as intended so here goes another try:
<a href=”…” …>Read more<span style=”hide me off screen”> about XYZ</span></a>
SP | 19/05/2009 at 16:10 | Permalink
I make pretty heavy use of title attributes.
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.