I thought title text improved accessibility. I was wrong.

A over-dramatic disaster destroying civilisation

Do you add a descriptive title attribute to your links? If so did you know that you might be making your site even less accessible? Recently everything I thought I knew about the title attribute was proved false when I started using a screenreader.

Insert/edit link dialog in WordPress

When WordPress added the input for adding a title to all links I was pleased. Finally, I thought, here’s a way that I can add more descriptive text about the destination of the link that will be read aloud in screenreaders. But I was wrong.

What I thought was true

Having an attribute to describe the link would be useful for screenreaders and for SEO purposes, so I’d always assumed that’s what the title attribute was for. I thought it was read aloud by screenreaders, to solve the problem of weak link text like “read more” and “click here”, adding title text would be read aloud instead, or at least as additional text that could be accessed by pressing a special hotkey. It was for this reason that I meticulously added useful text into the title attribute that would be useful to blind users.

I couldn’t be more wrong.

A few weeks ago I spent some time using screenreaders like a blind person would. I used the most popular commercial screenreader JAWS and the most popular free alternative NVDA. It was an incredibly enlightening experience and I learned a lot (here’s a list of what I learned). One of the main things I noticed is that the title attribute isn’t read aloud, AT ALL.

There’s an option in JAWS that allows you to read title text instead of the normal anchor text, but it’s not enabled by default. The only very tiny exception a title attribute will be read is if there’s absolutely no link anchor text, and that’s rare. Even if the link wraps an image, the screenreader will chose to read the image’s alt text instead of the title attribute.

So if you’ve been adding descriptive text into the title attribute, don’t. Blind users won’t hear it. It’s next to useless. This common misconception could lead to important information being completely inaccessible by the people who it’s intended for.

If you need proof, here’s a video of JAWS and NVDA reading out link text in Firefox and Internet Explorer.

I asked HTML expert Jeffrey Zeldman whether we should be using title text in links, here’s his answer.

@silktide says "We're researching link title text, & how it's not used by screen readers. Is there any reason to use it you can think of?" @Zeldman says: "No! Do not use"

I also asked Bruce Lawson, web accessibility expert from Opera, and author of HTML5 doctor. His advice was clear that we shouldn’t be using the title attribute:

@silktide says "We're researching link title text, & how it's not used by screen readers. Is there any reason to use it you can think of?" @brucel says "Kill it with fire. Or as Bim, a blind screenreader user from RNIB would say http://bit.ly/hP62Ch"

He pointed us to an article explaining the title attribute can do more harm than good. Here’s the article on the RNIB website.

W3C’s solution

So the best way to make a link accessible is to make the anchor text relevant and descriptive. This has been best practice for a while, and our website testing tools Sitebeam and Nibbler already check for what we call “weak text” like “read more” and “click here”. The reason this is bad is that screenreader users often use hotkeys to navigate the page, skipping to the next heading or link. If they skip to a link that says “read more”, it’s unclear what page they’ll be taken when clicked.

But sometimes for us sighted users, a “read more” link is completely appropriate. We can’t write an incredibly long and unique description in the anchor text of every one of our links. So what should we do?

The W3C have a recommendation, but it’s a bit bizarre. They recommend writing all the text in the anchor, but if you need to provide additional information for screenreaders, wrap this in a span which you hide with CSS. This means the unique text is there for everyone, but if you really just need the words “read more”, you can show that, and hide everything else.

Here’s an example:

<a href="#">
<span>Washington stimulates economic growth </span>Read More</a>

What I find the most bizarre about this recommendation is how they suggest hiding the text. Using display:none will make the text hidden in screenreaders, so we have to force the text out of the displayed area.

a span {
  height: 1px;
  width: 1px;
  position: absolute;
  overflow: hidden;
  top: -10px;
}

Sighted users will just see the words “Read more”, whilst screenreaders will hear “Link: Washington stimulates economic growth. Read More”

This method is explained in more detail here in the W3C’s article about using CSS to hide a portion of the link text.

There’s some more examples of how to make invisible content for screen reader users here.

If you enjoyed this, follow us on Twitter and Facebook.


Watch quick video tour of Sitebeam

Test your website with

or see prices & plans
  • http://www.igorware.com/ Igor

    Would be interesting to know how Google (and Bing) would treat hidden text in links.

    • Jared Smith

      Google uses this off-screen technique itself on its own homepage and recommends it in their webmaster guidelines. As long as it is not deceptive or malicious, Google has confirmed that it does not impact ranking. In the example above, it would be beneficial to SEO because the link text has meaning, rather than the ambiguous “Read More”.

      However, I would strongly recommend changing the off-screen CSS to:

      top:auto;
      left:-10000px;

      Positioning the off-screen content above the top of the page causes the browser to scroll to the top of the page when the link is focused, which can be confusing for sighted keyboard users. Positioning it off left has no negative impact.

      As noted, the key words for title are “advisory information”, meaning info that is not necessary for understanding or accessibility and that will likely not be read.

      • Stomme poes

        Having the element positioned above the page (like top: -4000px) would also make older versions of Window-Eyes read the element as if it were the first on the page, then further down the page again when it encountered where the element was really from in the DOM.
        Also Opera has (or had if this is fixed) an actual pixel height limit and doing something like top -9999em was over that limit, and if overflow:hidden were on some main page elements you’d lose the ability to scroll everything correctly.

      • http://www.igorware.com/ Igor

        It’s good to know that they use it on their pages. Thank you for the tips.

        I just can’t fight the feeling that this text hiding is wrong way of doing things. It’s definetly not part of HTML spec and feels like trying to cheat someone instead of trying to help someone.

        • gordondev

          This type of text hiding is actually a very common practice (albeit, with various methods of pushing the text off-screen), though the most common use-case for it is image replacement of text (either for using a specific font, before web fonts got popular; or for graphics that are more stylistic than content). The logos in the header and footer of this site are a prime example of this technique in action. It’s most often used as a technique to maintain meaning of the replaced text to user agents that don’t use CSS and/or images by putting that text back in its place (such as search engine bots and text-only browsers).

  • elliotlewis

    So what’s the title attribute used for, just displaying a tooltip for sighted readers? I knew it’s hi-jacked for SEO purposes but is there a ‘proper’ use for it?

    • silktide

      It was originally intended to display “advisory information”, here’s the description in the HTML4.01 spec:
      http://www.w3.org/TR/html401/struct/global.html#h-7.4.3

      This is a bit vague though, and they’ve clarified it in the HTML5 spec using an example as a “description of the target resource”:
      http://www.w3.org/TR/2011/WD-html5-20110525/elements.html#the-title-attribute

      • elliotlewis

        Thanks for the update (I should have done that!). So generally; sighted users aren’t bothered, screen readers don’t use it and Peter Knight reckons Google considers it less important for SEO.

        I ‘thought’ title text was important to use, seems not!

  • http://twitter.com/peterrknight Peter Knight

    Great piece. Another reason why the title attribute sucks is that its hover behavior is ugly and not really functional on touch screens.

    In terms of SEO, Google is caring less about the anchor tag and looking more at the surrounding context so I don’t think we have to worry anymore about excessively seo-ing the title and anchor tags (in fact that could work against you now).

  • David Mulder

    Ok, so first of all @elliotlewis:disqus the title text is used for the hover behavior when you stay with your mouse on the link.

    Secondly, wouldn’t it be easier to have a 1×1 pixel image with an alt text containing something like read more

  • Steve Hurst

    The solution in the article is absurd. We’re supposed to hack in a fix, and dismantle what the majority of good web designers have used for years, in order to address this screen reader problem? Why not petition the screen reader developers to change their specs to read titles that are already in place on the majority of the web?

    We should be careful not to look at this as programmers finding a solution. Maybe human interaction is the best way to go.

    • silktide

      I imagine it’s not that easy to just get the screenreaders to read it, otherwise it’d be fixed already. I’ve been reading about each browser’s “accessibility API”, which is what communicates to the screenreader, annoyingly it’s different for each browser, so I imagine the problem lies somewhere between the API and the screenreader.
      -David

      • Steve Hurst

        Then we start with the browser Accessibility APIs. Of course it’s not easy, but its not a good idea to introduce hacks, and back-step on such a widely used practice. It will ultimately result in less reliability and more confusion.

        Most likely in the case of the Accessibilty APIs, the issue was an invisible one to the developers, and it is a missing or broken feature because of the audience size. Bringing attention to it could solve it. If we all remove our title tags, and run in a different direction, there’s no hope.

        • http://twitter.com/stevefaulkner Steve Faulkner

          browser implementers are well aware of the poor implementation refer to: http://www.w3.org/html/wg/wiki/ChangeProposals/notitlev2

          in short:

          “no vendors have indicated any plans to implement device independent access to title attribute content as a feature.”

    • http://twitter.com/stevefaulkner Steve Faulkner

      The display of tile attribute content as a tooltip has always been poor UI. It cannot be accessed by keyboard users or touch interface users, so all those millions of mobile and tablet users do not see title attribute content or know its there. browsers implementers are all aware of the issues (have been for years), but have chosen not to fix the issues. Which is why the HTML spec includes the following advice:

      “Note: Relying on the title attribute 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 apear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet).”

      source: http://www.w3.org/html/wg/drafts/html/master/dom.html#the-title-attribute

  • Stomme poes

    Re “The only very tiny exception a title attribute will be read is if there’s absolutely no link anchor text, and that’s rare.”
    There is one example I know of where a title attribute would *generally* be read out, as mentioned on Gez Lemon’s site http://juicystudio.com/article/invisible-form-prompts.php (quite old by now actually): form inputs. Title has been used as a last-ditch effort to give meaning to label-less text inputs before and this had wide support. It’s still much better to add a label and hide it offscreen instead, and today the problem is more with people using placeholders to replace labels instead of titltes, but wanted to point out that case.

    Also re do titles never do harm to sighted users? Yes, actually they get in the way sometimes. I remember seeing on Nielsen’s UseIt alert box a screenshot of title attributes often end up covering the useful text of the next link in a dropdown, and in the screenshots on his site these tooltips were, like many old default WordPress sites, just replicas of the anchor text (another reason it’s probably still a Good Thing that most screen readers don’t read out title attributes anyway). (It seems useit.com is gone? I did find a similar example on another site: http://media.smashingmagazine.com/wp-content/uploads/2011/09/brita-deutschland.png and here’s an example from the WP plugin which would remove redundant titles for you… but notice the image itself makes a redundant tooltip http://stommepoes.nl/crappytitles2.png )

    A personal problem I have with them: as a manager of a group on LinkedIn, I get a list of people who want to join the group. If I hover over each user’s name, I get a box with some basic profile information about them. This is good for me when I have a mouse: I can quickly scan if they look like they’re some kind of SEO marketer or someone who genuinely wants to join the group. However, LinkedIn in all its wisdom has decided their full names and occupations should be covered up by a large, black tooltip showing… guess what… their names. Which I could already see, cause it was what I was hovering over in the first place. The title gets in the way so much, I sometimes have to kinda jump with the mouse over to the new info popup box, and hope it remains onscreen while the annoying and useless tooltip vanishes. (example with someone’s name not blurred out (for now): http://stommepoes.nl/crappytitles.png however this particular person does not have as long a name as some others, where the covering gets more painful)

    Lastly, I want to mention something else: while titles mostly suck, are inaccessible not only to screen readers but keyboarders and touch device users and I dunno possibly Dragon and similar too, we might want to be careful removing all of them everywhere now. Many sighted mousing users rely mentally on tooltips, or at least strongly expect them, especially in web sites that look like applications (with buttons and toolbars and things) since this is common on desktop software. I urge developers to do some user testing before flatly removing all title attributes (unless they are redundantly repeating the anchor text, bleh), to see if users are expecting tooltips in places (like form inputs) and are using them for things like confirmation or looking for additional information (even if, as good developers, we know additional information needs to be available in another form).

  • http://gniw.ca Ambrose Li

    The only problem with the proposed hack is that if you use a text browser you just see junk. “Washington stimulates economic growth Read More” does not make sense in English.

    • http://www.ongoingworlds.com/ David Ball

      True it’s not exactly prose, but it explains the destination of the link. Remember that interactive TV bit in Starship Troopers where at the end of each bit it says “would you like to know more?” It’s exactly like that but more concise :-) https://www.youtube.com/watch?v=SMTz9nIUkGc

      • Guest

        Yeah, but I am still weary of this ubiquitous “Read more” thing. So many sites are not just cutting paragraphs at random places but splicing up words in half and relying on people clicking “Read more.” I find this very hard to like.

        • http://www.ongoingworlds.com/ David Ball

          Yeah cutting up sentences is bad, and confusing. I don’t like that, although I can understand technically why many sites do it like that.

  • Pingback: Using the Title Attribute with HTML Elements

  • http://www.facebook.com/cookiecrook James Craig

    It’s a common misconception that all screen readers behave the same way.

    Title text *is* spoken by default on Mac OS X VoiceOver after a short delay. This has been the behavior for years. Also, in the WebKit nightlies, in accordance with the ARIA spec, the title attribute attribute is used as the default label if no other label text is calculated.

    • silktide

      Interesting James, I’ll have to check this out, thanks!

  • domellen

    I tried using the html suggested by the W3C but whatever method I use to hide the span text in the link, there is a problem in Chrome Mac and Safari Mac, but not in Firefox or Opera. This Fiddle : http://jsfiddle.net/ellenh/hVG5d/4/ shows it. I used the CSS from HTML5 boilerplate but all methods have the same problem. I haven’t found a good solution yet.

  • Oliver Keim

    Tool tips are not only used on links, but also on buttons, input fields, labels with abbreviated texts and many elements more. This is the case on native user interfaces, no matter if Windows, Linux or an Apple. Tooltips often provide information about the element itself, especially if not textually labelled, such as buttons with icons, but may also present the documentation of the hotkeys to be used. Furthermore the tooltip can also be used to expose even more important information, even for the sake of accessibility, especially in the web where custom controls will arise, even in old HTML4 environments. There are already many and their support can be very proficient, if the tool tip would be announced to screen reader users.

    Good designed software systems provide access to tool tip data, by using mouse, touch screen or the keyboard. We all have seen examples where keyboard access to tool tips is implemented, or where the software automatically shows up the tool tip as soon as the keyboard focus is placed onto the control.

    More than this, there are software environments which provide the tool tip information, such as IE10 and Narrator8 or Firefox and NVDA. The fact that the leader of screen readers on Windows has decreasing support of announcing a tooltip/immediate access to a tool tip – it is a vendor issue, but not a problem with the HTML specification of the principle of using tool tips to expose textual data.
    Very honestly, if it does not work with one screen reader, there are others that do support the announcements.

    Instead of asking thousands of web authors to change their practise it would be wise to talk to the involved software producers and ask them to fix their bugs. Especially if some decreasing support has being recognized at the time the screen reader’s settings dialog was reworked.

    ALT is not the alternative.

  • http://www.biztechconsultancy.com/magento-development.htm Magento Development

    Impressed from your article. Somethings are totally new for me on your post that i like most. Interesting facts also on your post that put extra edge to your post.

  • http://www.incion.com/ web design company los angeles

    Thoroughly enjoyed the post. Eagerly anticipating what coming next .

  • كيمو نور
  • mohammed elgammal

    شركة السريا
    شركة تنظيف بالدمام
    شركة تنظيف بجدة
    شركة تنظيف فلل بالدمام
    شركة تنظيف فلل بجدة
    شركة تنظيف شقق بالدمام
    شركة تنظيف شقق بجدة
    شركة تنظيف شقق بالمدينة المنورة
    شركة تنظيف بيوت بالدمام
    شركة تنظيف البيوت بجدة
    شركة تنظيف بيوت بالخبر
    شركة تنظيف مجالس بالدمام
    شركة تنظيف مجالس بجدة
    شركة تنظيف موكيت بالدمام
    شركة تنظيف موكيت بجدة
    شركة تنظيف موكيت بالخبر
    شركة نقل اثاث بالدمام
    شركة نقل اثاث بجدة
    شركة نقل عفش بالدمام
    شركة نقل عفش بجدة
    شركة نقل عفش بالجبيل
    شركة نقل عفش بالخبر
    شركة نقل عفش بالقصيم
    شركة نقل عفش بالقطيف
    شركة نقل عفش بالمدينة المنورة
    شركة تخزين عفش بالدمام
    شركة تخزين عفش بجدة
    شركة مكافحة الحشرات بالدمام
    شركة مكافحة الحشرات بجدة
    شركة مكافحة الحشرات بالخبر
    شركة مكافحة الحشرات بالقصيم
    شركة مكافحة الحشرات بالقطيف
    شركة مكافحة الحشرات بالمدينة المنورة
    شركة مكافحة الحشرات بالجبيل
    شركة رش مبيدات بالدمام
    شركة رش مبيدات بجدة
    شركة رش مبيدات بالجبيل
    شركة كشف تسربات المياه بالدمام
    شركة كشف تسربات المياه بجدة
    شركة عزل خزانات بالدمام
    شركة عزل خزانات بجدة
    شركة تنظيف خزانات بالدمام
    شركة تنظيف خزانات بجدة
    شركة تسليك مجارى بالدمام
    شركة تسليك مجارى بجدة
    شركة تنظيف بيارات بالدمام
    شركة تنظيف بيارات بجدة