HTML5 Accessibility Chops: title attribute use and abuse

Posted on Monday, 23 January 2012 by Steve Faulkner

For the past 7 years myself and others have banged on about the trouble with the title attribute in regards to accessibility and usability. Bottom line is that it is not well supported in browsers and its usefulness is severely compromised as a consequence. All browser vendors are aware of the issues in regards to keyboard and touch based interfaces and yet have made no movement or commitment to implement improvements in the 19 years since it was originally specified in HTML.

HTML5 codifies the authoring of inaccessible content

Furthermore we still have the authoritative document for understanding how to use and implement HTML, illustrating and advocating title attribute use in terms that promote and codify inaccessible content. While at the same time the HTML5 specification does not mention the real world documented usage methods for the title attribute that actually help users with disabilities, because the editor of HTML5 refuses to allow it.

Examples of HTML title attribute use and abuse

In the linked document title attribute usage examples I have provided some data of title attribute use on a range of popular sites. The examples illustrate that the title attribute is widely misused.

When to use the title attribute: simplified

  1. Do not use the title attribute, on any element, for any text  that you want all users to have access to.
  2. Only use it to label a form control when the same text is provided as visible text.
  3. Do not use it on a link to provide information that may be important to any user.
  4. If in doubt, read: Using the HTML title attribute

Further reading:


About Steve Faulkner

Steve is the Senior Web Accessibility Consultant and Technical Director, TPG Europe. He joined The Paciello Group in 2006 and was previously a Senior Web Accessibility Consultant at Vision Australia. He is the creator and lead developer of the Web Accessibility Toolbar accessibility testing tool. Steve is a member of several groups, including the W3C HTML Working Group and the W3C Protocols and Formats Working Group. He is an editor of several specifications at the W3C including HTML 5.1, Using WAI-ARIA in HTML and HTML5: Techniques for providing useful text alternatives. He also develops and maintains HTML5accessibility

Comments

  1. One of the ways I am currently using the title attribute is to make up for a deficiency in html user agent implementation of the time element. For example (use square brackets instead of angle brackets):

    [p]As of [time datetime="2012-01-23"]today[/time] I still have not heard back.[/p]

    I have my software go through and change it to

    [p]As of [time datetime="2012-01-23" title="January 23, 2012"]today[/time] I still have not heard back.[/p]. I then use CSS to add a light dotted underline to any time element that has a title attribute, similar effect to the way abbr is often rendered. That way someone reading the content can get context to what today is, something that browsers should support but do not.

    I know that the date will not be available to someone without a mouse, it’s tempting to also set tabindex and then use JS onfocus to show the tooltip effect, but that may actually be more annoying then beneficial, I don’t know.

    I could just put the date in instead of “today” which may be the result of what some screen readers do anyway, and in the example above that probably would be better, but in some cases it really doesn’t read as well to specify the full date in the paragraph itself. I thought using the title attribute w/ css to underline was a clever way to provide context for users who wanted it, context that should be made available by browsers when that tag is used but currently isn’t.

    I’ll have to think about it some more. I really like the ability to add a timestamp via the time element and wish browsers implemented a way to let users know the context of the time stamp when it is provided. I don’t understand why it would even be part of the spec if it isn’t going to enrich the user experience, which is what I’m trying to do by using the title tag.

    One thing I did do after reading about problems with redundant title tags is I changed my code to only put the title in when the date is not clear from the text itself. IE if I have [time datetime="2012-01-23"]January 23, 2012[/time] then I don’t have it add a title tag because it is redundant and doesn’t add to the user experience for anyone.

  2. It’s a perennial issue for anyone in touch with accessibility and must be the one thing I hear advocates scream about more than anything else. Personally I hate title attributes in any form, I hate the little yellow box that unhelpfully pops up to say something inane. It’s an element left over from the early iterations of the web and doesn’t have a role an a modern website.

    It’s also bad SEO to be dropping titles everywhere, they don’t do anything. Half the time you see titles covering empty alt attributes to boot.

    What do you guys think about using titles when an image (with an alt text of course) is a link? It’s probably the one area I can cope with titles but I still can’t bear the sight of tool tip boxes – who decided they were going to be that drab post-it yellow colour?

  3. Hi Luke,

    What do you guys think about using titles when an image (with an alt text of course) is a link? It’s probably the one area I can cope with titles but I still can’t bear the sight of tool tip boxes – who decided they were going to be that drab post-it yellow colour?

    Depends on what the title content is, if it is information that you would like all users to be able to access don’t use them. I wrote a post about providing captions for images using the new HTML5 figure and figcaption elements which may be helpful. One the examples provided is for captions that appear on hover/focus. The appearance of tooltips is reliant upon the OS, which is why they look like they do.

  4. Hi Luke,

    What do you guys think about using titles when an image (with an alt text of course) is a link? It’s probably the one area I can cope with titles but I still can’t bear the sight of tool tip boxes – who decided they were going to be that drab post-it yellow colour?

    Depends on what the title content is, if it is information that you would like all users to be able to access don’t use them. I wrote a post about providing captions for images using the new HTML5 figure and figcaption elements which may be helpful. One the examples provided is for captions that appear on hover/focus. The appearance of tooltips is reliant upon the OS, which is why they look like they do.

  5. Hi Alice, sounds like you are trying to do the right thing to avoid redundancy. I don’t see a problem with use of the title attribute if the information required to understand the content is available in text for all to access.

  6. Thanks Steve,

    if it is information that you would like all users to be able to access don’t use them

    That about sums it up for me. I want all users to get all information. The captions option looks a good one – I’ll play around with that where I can. Someone should have a word with the OS – aesthetically, it’s like having tiny post-its stuck to your screen then peeled off again.

  7. Steve,
    When you say, ” use it to label a form control when the same text is provided as visible text”, I suppose you mean like a form in a data table where both the row and column header need to be associated with the field, right?
    Else explicit label association is the best way for visible text placed as next to / above the field to serve as labels, no?
    And when fields do not have visible label text because it is pretty obvious in the context like a single search field next to a search button, a title attribute on the INPUT is handy for benefit of non-visual users. This is widely supported by AT unlike the aria-label which essentially serves the same purpose.

    The other issue is Firefox does not expose the alt when moused over on an image but it exposes the title. An example of incorrect rendering of the title and a disregard of the alt.
    Sailesh

  8. Hi sailesh, there are 2 main scenarios where I think it is appropriate:

    A textbox with a button to the right which visually identifies the text boxes purpose.
    In data tables that contain inputs and the table header cells provide the visible labels

    The other issue is Firefox does not expose the alt when moused over on an image but it exposes the title. An example of incorrect rendering of the title and a disregard of the alt.

    unsure what you mean here?

  9. My “Google fu” has failed. ;-) I’m trying to find a good search string that will describe what I’m looking for, and in frustration, I’m giving up and asking: I have a table and at the intersections of some rows and columns, I have a bullet — well, actually, a Unicode character that actually pays attention to the font-size style, in contrast with the actual bullet entity. If beaten into submission, I suppose I could substitute each bullet with an img, but I’d rather not. My question: How can I provide alternate text for what is, in effect, text, not an img. (I *want* to use alt=”” on a non-img span but I also want to stay with HTML5 compliance.)

Comments for this post are closed.

Recent Posts

See all posts in the blog archive

I am thrilled to hear that TPG will be part of the state blanket contract allowing our agencies to use your unique expertise and broad knowledge of accessibility. This is a bright day for citizens of the Commonwealth of Massachusetts.

Sarah Bourne, Director of Assistive Technology – IT Division, Commonwealth of Massachusetts