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.
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…
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.
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!!!”
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.
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.