A few years ago, Dan Cederholm published a series of articles called Simplequiz. Dan posed some options for marking up a specified piece of content and invited readers to choose the one they felt was the best way to mark that up. The value was in the comments, where people defended their choices and debated the options (which means it is the law that you read the preceding comments before adding your own).
With Dan’s blessing, we’re running an occasional series of HTML5 Simplequizzes.
HTML5 offers a way to associate a figure (which can be an image, a video, a graph, a table, a pull-quote) with a caption using the
<figure> element. This is very common in print, but there has been no way to do this in HTML4, as there is no element that groups a figure and a caption (other than a semantically-empty
Our question this week is about alternate text for images that are captioned. I’ve gotten this wrong before (in print, embarrassingly), as have two highly-clueful friends of mine. The man who set us right will be your moderator and quizmaster this week, Steve Faulkner of The Paciello Group, possibly the most respected accessibility agency out there.
We have an image as a figure in a story simply about a dignitary opening a new branch of Mr Lidl’s marvelous emporium. The caption will be “Mayor of Casterbridge opens a new Lidl supermarket”.
What’s the best markup for this? Show your working out.
<figure> <img src=blah.png alt="A portly gent cuts a ribbon. He is with five small children, and is watched by two middle-aged woman, a very tall smiling man, and a small crowd"> <figcaption> Mayor of Casterbridge opens a new Lidl supermarket. </figcaption> </figure>
<figure role=img aria-labelledby=lidl> <img src=blah.png alt=""> <figcaption id=lidl> Mayor of Casterbridge opens a new Lidl supermarket. </figcaption> </figure>
<figure> <img src=blah.png> <figcaption> Mayor of Casterbridge opens a new Lidl supermarket. </figcaption> </figure>
<figure> <img src=blah.png alt=""> <figcaption> <p>Mayor of Casterbridge opens a new Lidl supermarket.</p> </figcaption> </figure>
<figure> <img src=blah.png alt="Mayor of Casterbridge opens a new Lidl supermarket."> <figcaption> Mayor of Casterbridge opens a new Lidl supermarket. </figcaption> </figure>
Steve will wrap up the quiz next Thursday.
63 Responses on the article “HTML5 Simplequiz #4: figures, captions and alt text”
[A] is perfect. Well, “portly” and “middle-aged” can probably be scrubbed for political correctness and/or semantic reasons.
I would go with D. I believe keeping the figcaption associated with the figure by embedding is important for accessibility and is associated with the image. The alt attribute is no longer required because figcaption can now handle that function. But would you still have to include alt=”” to create a valid document? If not then C would be a better choice.
I would choose C.
imgis not for purely presentational purposes as it is contained in a
<figure>element and has an associated
<figcaption>. This being the case, it requires no
It would benefit, however, from an
idbeing given to the
<figcaption>, and associating the
<img>with it using
<mg src=blah.png aria-labelledby=lidl>
<igcaption id=lidl>Mayor of Casterbridge opens a new Lidl supermarket.</figcaption>
*Obviously, in the example, those tags should read
Haven’t you exactly described B?
A is out for me because the
altattribute should never be used to describe an image, only to offer alternative text when the image can not be shown.
B is out for me because ARIA is a bridging technology. We should use pure HTML5 whenever possible and since we are talking about how to create a caption using HTML5 that one is a big no-no.
E might be right (depending on the context) if we were not using the whole figure/figcaption thing. But since we are, it gives us double content and is out.
In the end I’d like to vote for combining C and D. I don’t think that
<figcaption>should include a
<p>since this is such a short caption. However, I want to keep
<img>because we aren’t actually providing any text alternative for the image. (A caption might read “Figure 2: A pie diagram” and that’s not alternative text!)
I would probably choose A
alt should be the description of a picture for people and/or user-agent who can’t see it so an in-depth description for this attribute makes perfectly sense, while I would use figcaption more like as an figure title
He would be much portlier if you corrected the aspect ratio. The correct markup should include
<img width=500 height=343.
If there’s a real story told below of above the image, I’d say D is sufficient. If the image is the main content of the article, A might be useful. E duplicates information and it the worst solution. B includes Aria stuff that should be implicit by the markup that gets used (but I’ll admit I don’t know if there’s a need for that). I’ll also admit that I don’t know if C and D are considered to be equivalent nowadays.
B has an
altattribute and the
aria-labelledbyhas been set on the
<figcaption>in this way doesn’t make sense to me, as the text contained in
figcaptionshould be used to describe
<figcaption>were to be associated with
<figure>, then it shouldn’t be contained by it. As a child element, i feel as though the relationship between those two particular elements is implicit (or should be).
From what I’ve read on the subject, that’s my own interpretation. There’s probably a hell of a lot of hair-splitting going on there. I’m sure Mr. Faulkner will lend this issue some clarity!
It’s definitely A. The purpose of an alt tag for an image, regardless of HTML version, is to describe what is going on in the photo so that an individual without sight can understand the photo and take away the same value someone with sight would get. These should provide as much description as possible, without being overly verbose. But the remaining options are too short to provide value.
setting alt=”” on an img is specced (in HTML5) as the same as having the ARIA role=”presentation”. role=”presentation” removes the from the accessible tree (the DOM as presented to assistive technology via accessibility APIs). So with alt=”” there is no image in the figure. Using role=”img” on figure conveys to accessibility APIs there is an image and associating the figcaption content using aria-labelledby conveys the accessible name value for the img to accessibility APIs.
“role=”presentation” removes the img from the accessible tree”
I think B is the best choice.
A is out because it provides a very descriptive but uninformative alt text (this reminds me of people who put in alt text like “rounded corners with drop-shadow”). The most appropriate alt text communicates the purpose of the graphic, not its appearance.
C is out because it doesn’t provide an alt text. And empty alt text is better that no alt text, as screen readers know how to skip an image if the alt text is empty. If there isn’t an alt text at all, most screen readers will read out the file name instead (boring).
E is out because it simply repeats the information.
And I prefer B over D because D has an unnecessary paragraph tag. And in any case it doesn’t hurt to add some WAI-ARIA. Even if it duplicates some HTML5. ARIA is much better implemented than HTML5, and although this will change, having the ARIA roles there will not hurt anyone. [true story]
“The img is not for purely presentational purposes as it is contained in a <figure> element and has an associated <figcaption>. This being the case, it requires no alt attribute.”
This interpretation is currently correct as per the HTML5 spec (note i say ‘currently’, as alt conformance requirements are still being debated). But it currently suffers from a similar issue to alt=”” , when an image has no alt text it’s presence is usually not indicated to AT users, As the figure/figcaption elements are not implemented accessibly in browsers (the semantics are not wired up) and not supported by AT, effectively there is a caption for nothing, which does not make a lot of sense for AT users.
Thank for the reply, I think I’m getting it. Just so I’m clear— by including role=”img” on figure and alt=”” on img, does this give the browser conflicting information about whether there is an image or not?
The function of the image is to illustrate the mayor opening. It may or may not be accompanied with an article, but I presume its function is to communicate what the caption says. For that reason it’s “described by its context” and no additional alt text is necessary (or desirable).
A – No.
Why? That’s a lot of extraneous & rather useless information in
@alt. The caption is fine.
E – No.
Why? Repeats the caption in
@alt. Repetition = bad.
C & D – OK.
The major reason to use the empty alt element is to (1) conform to the XHTML requirement for
@altand (2) possibly to imply that it’s not that you forgot
@alt, it’s that there’s no need for
@alt. D has a fairly unnecessary
<p>tag, however. So I put both of these on the same level. They use the correct description, they understand that the image is labeled by context, and they don’t repeat anything in
B – Best.
Why? It avoids the mistakes from A & E, gets the same things right from C & D, but adds a dose of specificity & care by using ARIA.
I think A is the best, although I’d probably mention someone holding Laura Bush to keep her from falling over in a drunken state.
I’d go with A as it follows the rules of alt tags correctly, however B may also be right with it’s figurecaption for the image and more comprehensive use of ARIA tags.
I think from an accessibility standpoint B would work but would require the screen reader to know about figurecaption’s.
…then again it’s got to be A, an empty alt attribute is just so wrong
[ A ]
I would have to agree with @Martijn, for all of the same reasons. ARIA should * never * be used in html5 (perhaps I’m in the minority here). If it is useful in ARIA it should be adopted natively in the html5 (markup language) spec… (trumpets sound).
The only thing that I would add is that the image should * likely have a longer description, like that provided in (a)… of course we lack an “appropriate” mechanism to do that in html5, so I suppose that as a completely blind user I will never really groc the portlyness of the man :(
a. Too much information, but would be a good runner up.
b. ARIA (makes me feel a little sick inside)
c. Missing alt
d. Looks great, could go either way on the use of p in the figcaption
e. Duplicates alt in the figcaption (or is that the other way around?)
Let’s start with option B. Because the only content of the figure is an <img> and the <figcaption>, the role=”img” looks unnecessary. If there were more content in the figure that semantically formed part of the image, then adding role=”img” would be a good idea. Equally the aria-labelledby is not providing anything that the native semantics is not, so in this case can be considered superfluous.
Repeating the caption in the alt as per option E does not provide any new information to the user who cannot directly experience the image, so is pure duplication. As such, it’s the worst of all the options.
Option A provides a description of the image in the alt attribute, whereas the other options do not. The caption, which is content, must be captioning something, so that something must also be content. If the image is content then someone who cannot see the image must be missing out on some information unless that information is provided in another form. The mechanism for the other form in HTML is alt text.
The correct alt text is always somewhat context dependent, and knowing what aspects of an photograph should be described in text is something of a minefield, but the option A alt text seems to describe most of the pertinent information. In addition, one important thing to note is that the alt text in option A only describes information that someone who can experience the image directly can see for themselves. That is, there is no new information in the alt text that a sighted person would be missing out on.
I conclude, therefore, that the alt text in option A is very fine indeed, and option A is the correct choice.
@Steve Faulkner – Is it really true that img with no alt attribute is not presented to AT? I thought there was a big argument over AT “repairing” images without alt attributes, that didn’t happen if the image had alt=””.
(“repairing” in quotes since, of course, it does nothing of the sort, reading out the file name or similar)
I like A best because it works today. AT users have something to go on to understand what the image is there for. It could be enhanced by giving the figcaption an id and using aria-describedby on the img.
I don’t like B because the labelledby should be on the img not the figure, and the empty alt means the image is ignored by AT.
C is correct according to the spec and is how things would work in a perfect world, but so is XHTML2. In order to have a semblance of accessibility it would need an id on the figcaption and aria-labelledby on the img.
D is kind of like B in that the empty alt means there is a caption for nothing for AT users. I don’t know if the p is unnecessary or not, but that’s not my main issue with this option anyway.
There’s no point in duplicating the figcaption in the alt like in E. Either use ARIA to associate the figcaption with the img and drop the alt attribute, or use alt and give it a value, like in option A.
So to summarize, A if the alt text is considered necessary or C with ARIA if it’s not. I would say it is and go for option A with aria-describedby.
I have no idea why I ended that with a capital E. Ignore it!
A – blind users would be appreciative! The figcaption is just that, a caption. The verbose alt provides a good description for any user who cannot see the image.
After having actually read the W3C guidelines ( http://dev.w3.org/html5/alt-techniques/ ), it appears [A] is the correct answer. /*hangs head in shame */
Also I’m a bit worried about the comments saying you should never mix HTML5 and ARIA. Why not? HTML5 accessibility is not very well supported, it will be in the future, but ARIA works today. And yes it’s a little bit extra work but it’s very minimal. And even when HTML5 accessibility works natively, having the ARIA there as well doesn’t hurt. Right? And even then there will still be roles and properties in ARIA that are not matched by HTML5.
I think I agree with the emerging consensus on A being the correct choice.
The only thing I will add to the comments above is about the
pelement in the
figcationin example D.
figcaptionshould only contain phrasing content.
This bit of the spec is quite fiddly, but there is a nice Venn diagram under Kinds of content in the Overview document which shows how the content types relate to eachother.
pelement is flow content but not phrasing content.
Sure there has, the title attribute is perfectly suable for captions (and can be displayed via CSS).
HTML5 accessibility is not very well supported, it will be
in the future, but ARIA works today. And yes it’s a little bit extra work but it’s very minimal. And even when HTML5 accessibility works natively, having
the ARIA there as well doesn’t hurt. Right? And even then there will still be roles and properties in ARIA that are not matched by HTML5.
1. If we were to adopt all of ARIA natively into html5 then ARIA would not have anything that HTML5 does not. Remember, ARIA is a transitional, bridging, technology.
2. There are huge dangers in using ARIA instead of natively supporting accessibility in HTML5, these are not technical in nature. The longer the broader development community, such as the HTMLWG, ignores accessibility, or thinks that others like the PFWG / WAI will take care of it for them, the longer we will need technologies like ARIA to fill in the blanks.
Making websites shouldn’t be about politics. Are you seriously suggesting we hold the users ransom for political gain?
I’ll take implementation over ideology any day. ARIA works. If I by using ARIA make a site more enjoyable or easier to use then it’s worth it.
Using ARIA is not *dangerous*. It won’t hurt your site, it won’t hurt your users.
For a list of ARIA features not considered to be available natively in HTML5 see: http://www.paciellogroup.com/blog/?p=585
Making websites shouldn’t be about politics. Are you seriously suggesting we hold the users ransom for political gain?
Yes, absolutely, I am suggesting that, I have a whole basement full of them (/sarcasm) Whether you believe making web-sites (actually what I am talking about here is making specifications) should be political or not, it is.
I’ll take implementation over ideology any day.
Me too. I’ll take language specifications that implement accessibility, that force engineers and implementers to struggle with the concepts of accessibility, and therefor learn more about accessibility and develop more accessible specs any day. And yes, this way we end up with specifications that are natively accessible, instead of specs that implement new technology and techniques and then wait for the accessibility folks to come around later to make them accessible.
Using ARIA is not *dangerous*. It won’t hurt your site, it won’t hurt your users.
Correct, but relying on ARIA when developing new technologies (oh, ARIA 1.1 / 2.0 will come up with a solution for that, let’s ignore it) will hurt your site and will hurt your users.
I’m working my way through http://dev.w3.org/html5/alt-techniques/ and I think a salient point is made where it says:
That definitely rules out B even if the labelledby is on the img.
From best to worst:
[B] and [D] – [B] is very thorough with the ARIA, essentially, in a way, better explaining the situation of potential @alt/caption redundancy to the user agent. [D] is similar but more minimalistic. It does not include the ARIA and for some reason includes an unnecessary <p> element, however, it is still conforming.
[E] – Redundant, but still technically semantically correct
[C] – Similar to [D], but it does not include an @alt on the img, which is non-conforming, but I would almost say this is correct. The reason an empty string in an @alt is used is when the meaning of the image cannot be ascertained by the author of the html. In our current situation, we understand what the image means, however, we can’t put that meaning in the @alt and we can’t leave the @alt empty because that would also be semantically inaccurate. The only other option is to not use @alt at all, which unfortunately, is non-conforming.
[A] – The worst by far. @alt text should never describe an image. @alt text should never even acknowledge that there once may have been an image in its place. It should never hint at the existence of the image because it is not there to describe an image, it’s there as a replacement for the meaning of the image.
Personally, this is what I would use:
<img src="blah.png" alt="">
Mayor of Casterbridge opens a new Lidl supermarket.
“Just so I’m clear— by including role=”img” on figure and alt=”” on img, does this give the browser conflicting information about whether there is an image or not?”
No, the role information is not used by browsers, other than to convey information to accessibility APIs.
In general the default setting for screen readers is to ignore img elements without alt attributes. There are exceptions to this rule, for example if an img element is the sole content of a link and it has no alt attribute, screen readers in general will announce the img src content or the href content of the containing a element.
have a look at Investigating the proposed alt attribute recommendations in HTML 5 for further info about this.
“Sure there has, the title attribute is perfectly usable for captions (and can be displayed via CSS).”
The title attribute is not a good container for captions as it’s default rendering is device dependent. CSS should not be required to provide device independent access to caption information.
none, it should be something like
blah blah blah blah
we don’t need a figcaption as it could be used for tables and other things, also adding another container is just silly and add to the tag soup
-Agree with Tom and Max above that the alt text description is needed and would be appreciated by blind users (and useful for SEO).
-No real need for ARIA because the semantic HTML5 elements (figure, figcaption) already provide the required association.
-Agree with Andy in first comment that: portly” and “middle-aged” can probably be scrubbed for political correctness (smiley)
I go for “A” for two very simple reasons.
It is semantically pure
and more importantly the alt tag describes the content of the photo which is clearly meant as content (placed in a figure tag) to those who have visual impairment .
Contrary to some other comments I think PC has no place when it comes to describing things to those with visual impairment. the purpose is to describe things in a way that leaves no ambiguity to allow the user to share as closely as possible the same experience as everyone else as they imagine the photo in the heads. I can’t speak for all visually impaired people, but I’d rather have the gory detail than some vanilla PC description
(D) is wrong for 2 reasons: 1. you can’t have <p> inside a <figcaption> element. 2. as the <img> is in a <figure> it is subject matter not fluff and as such must not have an emplty alt (alt=””) how can you have a caption for something that is not there?
(E) is wrong because the alt and figcaption content are the same. this does nothing but add cognitive noise for users who have access to both.
(C) is conforming HTML5 and will be good for situations where a suitable caption text is provided but not a suitable alt (probably most instances on phot sharing sites for example). I say ‘will’ because currently the <figcaption> and <figure> have zero semantics due to lack of browser and assistive tech (AT) implementation. So currently (C) is a caption in search of an image for AT users.
(B) is conforming HTML5 and a method (using WAI-ARIA) to make up for the lack of implemented semantics of example (C).
(A) is conforming HTML5, despite what people may consider as an overly verbose text alternative. It was a genuine attempt by bruce to provide what he thought would be a good alt text, so he should be commended not pilloried for his effort. I also consider it to be the most accessible of the examples. The image has an explictly associated text alternative (via the alt attribute) and an implicitly asscoiated caption (via the figcaption being adjacent to the img in the DOM).
So, I agree with Steve:
(C) is the right answer for when browsers and ATs catch up. The missing ALT alerts the user that there is an image (alt=”” tells assistive technology not to tell the user, because the image is purely presentational. I hadn’t realised this before Steve told me, hence the errata for my Introducing HTML5 chapter).
(B) is the transitional right answer – the ARIA plugs the gaps until (C) is supported
(D) is wrong because it breaks the content model for
<figcaption>. We threw this in here as we’re seeing a few examples where authors have assumed you can have paragraphs or other “block-level” elements here.
Where Steve and I disagree is about the verbose alt text in (A). Personally, I think it’s too verbose.. BUT some blind users may like this level of verbosity.
It’s also largely contextual. If, for example, the article were about Portly Man’s weight, describing the image in this level of detail would be appropriate. In this example, we said it’s “a story simply about a dignitary opening a new branch of Lidl” , so I think that in this example there is too much description here. But we can agree to disagree here.
The WebAIM screen reader survey is worth a read on the subject of what users want in a text alternative.
What Steve said.
Good points in this exercise, but it’s kind of a trick question since there’s no real one correct answer (mostly depending on state of browser support). In the WebAIM screen reader survey (as Steve refers to above), 59% said if an image is used solely to enhance the mood of a web page, they’d prefer that the image be described. Going by that, A is correct (my original answer) since it’s the only one with alternative text. Without it, a screen reader user wouldn’t know that the gentleman has several children (or that he’s portly!)
“it’s kind of a trick question since there’s no real one correct answer”
– true enough. But the purpose is the debate. (And often with semantics there are numerous different cat-skinning methodologies)
“Without it, a screen reader user wouldn’t know that the gentleman has several children (or that he’s portly!)”
– but is that material to understanding that the Mayor opened a new supermarket?
Where did you get the idea that block level elements are not allowed in figcaption? The content model for figcaption ( http://dev.w3.org/html5/spec/grouping-content.html#the-figcaption-element ) is flow content, which includes block level elements. This is easily verified by patching the D sample into the validator at validator.nu.
– crikey! You’re right! How did I possibly get that idea? Thanks for setting me straight!
I was wrong on (D) in regards to < p> I should have checked the spec rather than listening to @brucel :-)
(D) is wrong as the is in a it is subject matter not fluff and as such must not have an emplty alt (alt=””) how can you have a caption for something that is not there?
I choose “C”… first I thought the right answer is “E”, but coding wise “E” becomes redundant using the and the “alt” property of ….. so I’ll go with “C”
I choose “C”… first I thought the right answer is “E”, but coding wise “E” becomes redundant using the and the “alt” property of ….. so I’ll go with “C”.
I choose “C”… first I thought the right answer is “E”, but coding wise “E” becomes redundant using the
“” and the “alt” property of “” ….. so I’ll go with “C”..
I forgot to use the < and > for brackets… anyway you know what I mean.
wait I’ll change my answer to “E” because “alt” property and <figcaption> has different function…. so I’ll choose “E”.. I hope I’m correct
All the captions are incorrect, as it should identify Brett Favre and Laura Bush and explain exactly what sort of dirt the portly Lidl manager has on them to force their appearance at a store opening in the UK.
Another vote for A. On occasions when I’ve browsed with images disabled (e.g. on the bus with patchy mobile reception), I always preferred fuller descriptions for missing images; and when asked, screenreader users tend to prefer more information to less.
Here’s my question we discussed with Bruce and Steve Faulkner (who should post his reply here soon).
In the comments Bruce said that answer B is the right one, at least for now, which I agree with.
I used this solution in my current project, but was surprised when I saw validation errors: „Attribute role not allowed on element figure at this point”.
According to this table „img” is an implicit role of the figure element.
So my question is: do we need and should we use role=”img” on figure, if it’s implicit and appears to be invalid?
this table is a very early suggested mapping draft, some of the
mappings are agreed upon, but others are not. In the latest version(s)  of the mappings,
figurehas no default role (and no restrictions on roles that are conforming).
One of the reasons for this is that figure can contain any content not just images, so having a default role of
imgwould not be appropriate.
 there are currently 2 versions of the conformance rules for ARIA in
HTML5, both are under active discussion:
the one in the spec:
spec draft and this one:
Neither are considered definitive at this stage as the W3C HTML working group has not reached agreement.
but where they are the same, as in the case of
figure, it is unlikely that the mapping will change.
In other cases where default roles are defined for an element it is true that you should not need to add an ARIA role, sometimes though in the case of newer HTML5 elements, the use of ARIA may be warranted to
fill gaps in native implementations.
You can use
role="navigation"to expose the info to assistive tech that support ARIA landmarks.
This should not be necessary when browsers implement
< nav role=”navigation”>
The other case where use of a default role on an element is useful is if the role has a property in ARIA (but not in HTML) that you want to use
In order to use the on a button element you need to use role=”button”
< button aria-pressed=”true | false” role=”button”>button text< /button>
Note: global ARIA attributes can be used on most HTML element and do not require an explicit ARIA role.
@Bartek. The ARIA mappings in HTML5 are frankly a mess right now. According to the draft, <img src=”example,com/usflag.img” > has default role “img” but <img src=”example,com/usflag.img” alt=”English” > does not.
The figure rule from Henri’s table does not appear to match up with the current draft. Indeed the example at the very bottom of this page: http://dev.w3.org/html5/spec/content-models.html#annotations-for-assistive-technology-products-aria, uses role=”img” on the figure element and fails validation in validation.nu/W3C HTML Validator for that very reason.
@Steve Faulkner – Excellent. I wasn’t aware of your alternative draft. The mappings in that look much saner.
A is definitely my choose.
It’s perfectly correct
altattribute — describes an image content (when it’s significant) to people, who can’t view this image (page didn’t loaded, or an user is disabled).
Leave a Reply to steve faulkner