ALT and TITLE

Just a refresher for me…

Is it correct that the ALT attribute is required?

And that if ALT is not needed, you should do…

ALT=""

And is it correct that the TITLE attribute is optional?

And that if TITLE is not needed, it should be omitted?

Debbie

Yes, yes, yes and yes. :slight_smile:

That was easy! :lol:

Thanks TechnoBear!

Debbie

Presumably you’re referring to image elements here? Personally, I’d keep everything lower case. Seems to make for much neater code to me.

Yes and yes! :wink:

Debbie

ALT attribute: AREA, IMG #REQUIRED

Yes - for all the tags that result in an image being displayed in the page you need an alt attribute to supply alternative text to be displayed in place of the image when the browser is unable to display the image. That includes the tags you mention as well as all the others that can display an image.

The title attribute can be optionally added to any tag within the body of the page and contains text to be displayed either in the status bar or in a tooltip popup when the mouse is moved over the element.

Some versions of Internet Explorer have a bug where when a title attribute is not supplied for images, a title attribute will be generated by the browser with a copy of the text from the alt attribute. To fix this bug you should supply an empty title attribute on your images.

ALT is required on image, if the image does not warrant the use of ALT or you’d put a empty one on it, said image probably has no malfing business in the markup in the first place!!!

There is NO legitimate reason to put TITLE on IMG – EVER. Unless for some idiotic reason you want to override the browsers useful behaviors – and in most cases where people want to do that, it’s on images that HAVE NO MALFING BUSINESS IN THE MARKUP IN THE FIRST PLACE!!!

… and on a related note, with all but the rarest of exceptions the only legitimate reason to put title on a anchor is if you are using accesskeys and care about Opera accesskey menus showing your text instead of the URL. (open up this forum page in Opera, hit shift-esc and you’ll see the difference between accesskeys with TITLE and those without)

… and as a rule of thumb, unless it’s something like a ABBR or ACRONYM, if you have to use the TITLE attribute, there’s probably something wrong with the content.

… and if you use TITLE on a anchor and it’s IDENTICAL to the content, you’re a {expletive omited} re-re. #DDD. herpafreakingderp even!!!

We’re talking proud owner of the shirt that says “I’m with Stupid” and the arrow points up. We’re talking the type of idiotic drooling on oneself that could keep Stanley Spedowski, Will Hunting and Melvin Ferd gainfully employed for life following you around mopping up the mess.

You get to drink from the FIRE HOSE!!!

In other words, much like “if every LI inside a OL/UL is getting the same class, none of them need classes” it’s one of those Yes Wordpress, I’m looking at you moments.

For completeness, here’s an excerpt from the specs:

Attributes
List of attributes (excluding event handler content attributes) 
Attribute  Element(s) 	        Description 	                          Value 

alt        area; img; input 	Replacement text for use                  Text*
                                when images are not available 

title 	   HTML elements 	Advisory information for the element 	  Text
title 	   abbr; dfn 	        Full term or expansion of abbreviation 	  Text
title 	   command 	        Hint describing the command 	          Text
title 	   link 	        Title of the link 	                  Text
title 	   link; style 	        Alternative style sheet set name 	  Text

An asterisk (*) in a cell indicates that the actual rules are more complicated 
than indicated in the table above.

There wouldn’t be if it weren’t for the bug in Internet Explorer. You need to add [b]title=“”[/b} to all your images so that Internet Explorer will treat the images the same way as all the other browsers do. Without that IE generates a title attribute using the alt text.

Placing a title=“” on img tags is required as an IE bug fix.

I do agree that the title attribute should never have a value when used with images.

ASSUMING you consider that a ‘bug’ and not a ‘usability aid’ that you wish more browsers did.

That’s not “required” IMHO to be removed – if anything you are talking about making IE users not have the behavior they expect… and that’s bad usability.

… really if it’s a image that shouldn’t trip a usability aid on hover like showing alt, what in blazes is it doing in the markup as a IMG in the first place? The only situation I can see that being a desired behavior is for presentational images like icons on menus – and those don’t belong in the markup since, well… they’re presentation.

Just asking, so be nice…

I save this as a good Reference Guide on this topic…
http://www.456bereastreet.com/archive/200412/the_alt_and_title_attributes/

In this guide, the author states…

Use this to provide additional information that is not essential…

…Another potential use is to provide additional information for an image, like maybe a date or other information that is likely not essential.

When users create a Member Profile on my website, I have a “Photo Label” field that I add to the <title> attribute in case they want to add an additional annotation to their Profile Photo, for example…

Debbie sitting in garden

DeathShadow cleaning his fresh kill…

I don’t think that is egregious by any means… :cool:

Debbie

Sounds like alt text’s job to me. Title redundant to alt text is bloat IMHO… just because other browser makers are too lazy to make it useful like IE did is no reason to turn the markup into redundant garbage.

I’d probably also not put it there as title because screen readers will waste time on reading it twice, and to be frank I don’t think the blind really give a flying purple fish about avatars.

Though, I’m weird, I’d like to see other browsers provide useful tools for dealing with images like IE does; perish the thought. Nope, got to be crippleware all the way.

If the alt text that IE displays as if it were a title is actually useful then the alt text is wrong - or you are using the wrong image. The purpose of the alt text is to convey the same information for those who can’t see the image is conveyed by the image itself for those who can see it - so displaying the text as well as the image is duplicate content. duplicate content.

A wordpress user. The tooltips actually get in the way of reading the anchor text when trying to click the stuff.

Sounds like a caption to me.

I respect Roger’s opinion on shoulds and shouldnots on the web, but I’ll trot out Steve Faulkner’s message on title, it’s spot-on: http://www.paciellogroup.com/blog/2010/11/using-the-html-title-attribute/

And I do also agree with Crusty that IE users have been seeing alt text for so darn long, and real user testing actually shows that sighted mouse-users are actually using it if they’re regular IE users, to double-check things… it sounds silly, but they’ve been trained over years and years for this behaviour which is otherwise innocuous… I’d leave it in there rather than use the title=“” (unless there was an instance where there really was good reason that no tooltips appeared, for anyone).

Not at all – you might have a picture of five people, but you have no clue who they are… You see someone operating a machine, you have not idea what the machine is or what they are doing; A picture may be worth a thousand words, but quite often it’s the WRONG words.

Though Mallory did hit it on the head, one of the few elements from 5 that makes any sense in concept – figCaption. Of course it would make a hell of a lot more sense if it was called imgCaption so we could use it on everything, not just scientific figures and without the extra pointless wrapper… naturally we’ll just start wrapping ALL images in figures, even when they aren’t FIGURES, just so figcaption can be used.

In that way, ALT is actually handy to have shown; were that more browsers did it; using TITLE and ALT with the exact same text is just an idiotic workaround for browsers other than IE not behaving that way… and usually the results of doing so are disastrous – as Mallory pointed out, see Turdpress with it’s “TITLE for EVERY anchor, even around the exact same text!!!”

Honestly something like this would make more sense than figcaption:


<img src="/path/to/file.jpg" alt="Short Description">
     Optional descriptive text to be displayed underneath
</img>

But not all figures are images? A figure can be a video (those have captions), a table (those have captions though we don’t need figure/figcaption cause they already have their own), a chart or a graph (neither of which have to be <img>s at all) can have captions… why they deliberately chose the useless word “figure”. I’m sure non-English speakers have a field day trying to figure out the difference.

They considered that, except someone said “but what if that caption needs to be or contain block elements?” It was harder to change browser parsers to change what an EMPTY (as in spec-definition of EMPTY elements) inline element can contain.
But the advantage of having the caption inside the image tag is that you now have a natural, semantic relationship, something that right now they are trying hard to fix (for screen reader users and the like) with aria-describedbys and aria-labeledbys and other things they’re trying out.

Well and also having the caption separate but linked to the figure means you’re not stuck with the caption text at the bottom. I thought table captions could be rendered wherever around the table partially because, while the caption must come as the first child of a table, it’s wrapped in its own tag.

<img> could just default to inline-block instead of inline. Makes more sense for images anyway; if I’m using an image inside some text I’m probably going to float it so the text will wrap around.

They could also go ahead and wrap the caption in <caption> tags within <img> so it wouldn’t necessarily have to be at the bottom and could have its own styles applied

Video? As a figure? Where in blazes did you get that idea? Maybe I’m just used to figures as in the traditional sense where they are diagrams or pictures related to the content they are next to. Video… uhm… NO. Tables are NOT figures either – they’re tables. Open up a technical book – See Table 1, see Figure 1… Entirely separate entities with different meanings. One is a diagram, cutaway or mathematical formula, the other is a orderly division of data into rows and columns.

What you just said has ABSOLUTELY NOTHING to do with the meaning of the word in terms of layout, grammar, or anything you’ll find in a dictionary… Video? As a “figure”?!? Ok, where’s my pimp hat, gold chains and draino. [i](For those of you who don’t recognize it, that’s a [url=http://www.imdb.com/title/tt0070355/]Magnum Force joke…)[/i]

Of course it wouldn’t be the first time the HTML specs use a word in a manner that has nothing to do with it’s meaning; I mean, are we talking down to tags like an insultingly condescending kindergarten teacher, or are we making them of lesser value. (deprecate vs. depreciate) – not a shock many people think deprecate is a typo – Many places in the HTML specs are like that, treading into the same territory as “oh the humanity”. Poor guy was in such a panic he said the wrong word (should have been inhumanity), now the meaning of the word is changed… what’s next, changing the numerical designation on a aircraft because the president is dyslexic and the president can’t be wrong? That NEVER happened to the Reconnaissance Special 17.

It’s almost like when a recent band does a cover of a song nobody under 30 knows the original to. “Shout” – Oh man, I love Disturbed… NOT. Tears for Fears dumbass.

REALLY wish they’d research some of these words BEFORE they used them.