This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10483 - <figcaption> should be considered the caption of <figure> _itself_
Summary: <figcaption> should be considered the caption of <figure> _itself_
Status: RESOLVED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: LC
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://dev.w3.org/html5/spec/interact...
Whiteboard:
Keywords: a11y
Depends on:
Blocks: 10480 10497
  Show dependency treegraph
 
Reported: 2010-08-28 23:37 UTC by Leif Halvard Silli
Modified: 2011-01-13 13:19 UTC (History)
8 users (show)

See Also:


Attachments

Description Leif Halvard Silli 2010-08-28 23:37:19 UTC
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.
Comment 1 Leif Halvard Silli 2010-08-29 01:20:42 UTC
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>.
Comment 2 Ian 'Hixie' Hickson 2010-09-08 08:45:40 UTC
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.
Comment 3 Leif Halvard Silli 2010-09-10 00:32:39 UTC
(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.
Comment 4 Leif Halvard Silli 2010-09-10 00:34:02 UTC
(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.
Comment 5 Marco Ranon 2011-01-11 17:45:57 UTC
The bug-triage sub-team doesn't consider this to be task force priority as this is a matter of implementation.
Comment 6 Laura Carlson 2011-01-11 19:45:41 UTC
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.
Comment 7 Marco Ranon 2011-01-13 13:19:46 UTC
Thanks Laura,

Yes sorry. Removed "A11yTF" keyword now.