This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Spec says: ]] The first figcaption element child of the element, if any, represents the caption of the figure element's contents. If there is no child figcaption element, then there is no caption. [[ Request: Spec should say that the <figcaption> element captions the <figure> element _itself_. Arguments: (1) With ARIA-labelledby, it is possible to identify a caption, even if there is no figcaption element. (2) It is not precise enough to say that it represents the caption of "the figure element's contents". We can make an analogy to the TABLE element: the <caption> element represents the title of the entire table it does not only caption "the table element's contents". (3) ARIA 1.0 says that authors SHOULD use ARIA-labelledby to identify the heading, even when the heading element explicitly has a heading role. However, in my opinion, it ought not (in principle) be necessary at all once user agents support <figure> to make it clear that <figcaption> labels the <figure>. And ditto for <caption> - it should (in principle) not be necessary to point to it with aria-labelledby. I interpret the SHOULD in ARIA 1.0 as a compatibility measure in case not every user agents is capable of understanding what a heading captions. However, for a <figure> element (and <table>) it should be pretty obvious what the caption element is captioning. Making this distinction also has implications for accessibility and for the use of ARIA-labelledby: the high expecations about the "automatic" accesibility from the use fo <figure> IMHO depends on a clear specification of what <figcaption> by default is captioning.
Another reason to emphasize that <figcaption> is the caption of the <figure> element itself and not of the content of the figure element is to help authors understand the difference between the any h1-h6 elements that a <figure> may contain, and the <figcaption> element: The <figcaption> is like a "bridge" between the <figure> and the rest of the document. Whereas h1-h5 elements inside <figure> only are headings inside <figure>.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: I have no idea what you're requesting here or what problem it would solve.
(In reply to comment #2) > Rationale: I have no idea what you're requesting here or what problem it would solve. THE REQUEST: That <figcaption> is defined as having the same kind of crelationship to its parent element, as <caption> already has to *its* parent element. THE PROBLEM: the caption model of <figure> differs from the caption model of <table>. To say that <figcaption> represents the _content_ of <figure>, is a synonymous with saying that it is the caption of _child(ren)_ of the element. So while <caption> explicitly captions its parent element, <figcaption> is currently explicitly defined to caption " represents the caption of the figure element's contents". This content does not even need to be an element, it could simply be a text node. What if <figure> has no content, apart from <figcaption>? Does <figcaption> then caption nothingness? SOLUTION: instead of "represents the caption of the figure element's contents", the draft should say "represents the caption of the figure element" (or simply copy the wording used about <caption>: "represents the title of the _figure_ that is its parent" ). This would clarify that <figcaption>; just like <caption>, captions its parent element. EXAMPLES OF THE CURRENT CONFUSION: (A) HTML speaks loudly about <caption>'s relationship to its parent element, and it is reasonable to believe that authors will be affected by the definition of <caption> when they interpret <figcaption>: (1) [HTML5#the-caption-element defines] <caption> as the title of its <table> parent. (2) by default, user agents display the caption element outside border of the <table> element, despite that it is a child element of <table>. (B) <Figure> is defined by HTML5 as "self-contained". To say that <figcaption> captions the content of <figure>, instead of <figure> itself, contradicts with the "self-contained" definition: it makes it seem as if <figure> is just wrapper for the <figcaption> plus the content, and that the important thing is - to quote a much cited use case - the relationsship between e.g. the <img> child and <figcaption>. (C) The name of the element isn't <contentcaption>, it is <figcaption>! A <figcaption> logically is the figure's caption. (D) Possible <img> caption confusion: HTML5 permits @alt to be dropped whenever <img> is the sole content of a <figure> with a <figcaption>. However, if the author interprets this as a relationship between <img> and <figcaption>, then he/she might not realize that a paragraph element around the <img> makes the <figcaption> the caption of the <p> and not of the <img>. Or, if one simply adds some text around the <img>, then some authors would believe that the <figcaption> still captions the <img>, despite that the figure now consists of an <img> plus some text. By emphasizing that the <figcaption> captions <figure>, then authors will get this point better. (This point would have been even easier to get, if there also existed a <figbody> element.) (E) The section about #the-table-element describes how one can place a <table> inside a <figure>, and thus drop the <caption>, using the <figcaption> instead. The section about #the-caption-element even *recommends* doing so, whenever <table> is the sole content of <figure>. Here we can see the confusion very directly: <caption> is the <table> element's caption. However, since HTML5 says that <figcaption> is the caption of the content of <figure>, then <caption> and <figcaption> would in fact caption the same thing: both of them would caption the <table> element ... (F) In Bug 9817 Rich Schwerdtfeger explains a practical consequence of not defining properly whether the caption (in that case <summary>) "belongs" to its parent element or to the content of the parent element. (He recommends that only <details> receive focus and that the <summary> be a label for it.) Making sure that implementations links <figcaption> to <figure>, will create a consistent and stable interaction pattern. So, while the issue from one point is a little bit theoretical, it *is* important to get this right: let us build on the clear perception of <caption>'s relationsship to its parent, and underline the same understanding for <figcaption>. Then both authors and implementors has better chanse of getting the <figure> element right.
(In reply to comment #3) > (In reply to comment #2) > > Rationale: I have no idea what you're requesting here or what problem it would solve. > > THE REQUEST: That <figcaption> is defined Sorry, meant: "should be defined" > as having the same kind of > crelationship to its parent element, as <caption> already has to *its* parent > element.
The bug-triage sub-team doesn't consider this to be task force priority as this is a matter of implementation.
Hi Marco, (In reply to comment #5) > The bug-triage sub-team doesn't consider this to be task force priority as this > is a matter of implementation. Did you mean to remove the "A11yTF" keyword on this bug? It is still listed.
Thanks Laura, Yes sorry. Removed "A11yTF" keyword now.