PROBLEM:

It is not uncommon that authors place the annotation of a quotation inside the blockquote element. As there is no child element for annotations, this conflicts with the definition of <blockquote>, which says that all the content is (possibly edited) quotation.

PROPOSAL:

Define a blockquote caption element (hereafter described as 'bqcaption') for this purpose. This element should be allowed anywhere inside <blockquote> (at start or at bottom) - much like <figcaption>. The ARIA role should probably be contentinfo.

PROS:

1) Captioning elements are often child elements of the element it is captioniong. Thus it follows a well known designpattern in all markup languages.

2) It follows a particular pattern that has emerged in HTML, where there is no general caption element that changes meaning based on context. Instead, the caption elements of HTML tend to differ in their name from parent element to parent element. Examples: <legend> for <fieldset>, <caption> for <table>, <figcaption> for <figure>, <summary> for <details> etc. This pattern has the advantage that, if the author misplaces the element, it is easy to see were it belongs or that it is incorrect. Also, it means that copy-paste of code will not easly change the meaning of the element (as could be the case if the element was a general captioning element that was used in several elements)

3) Lets us avoid the competing proposal, namely the proposal to reuse <footer> - see bug 22996. The reuse of <footer> would contradict with the pattern of using differently named captions, as described in point 2) above, as it would effectively make <footer> into an element that function as un-quoted caption. Footer would be an element that changed meaning per context, whereas <bqcaption> would not. So, for instance, if someone copies an entire page with a <footer> inside, per bug 22996, the copied <footer> would, as it seems, get the meaning of an unquoted footer.

4) A dedicated caption element would be simpler for authors to understand (this point is actually a variant of 2) and 3)).

5) But for stating that <blockquote> can have one or none blockquote caption elements, we avoid redefining the <blockquote>, and we also avoid redefining <footer> - plus that we avoid that authors have to struggle with the contextual meaning of <footer>.

6) We don't hurt anyone’s toe. Though some has advocated using <footer>, this is *far* from a pattern.

CONS:

* We must deifine a new element, which isn’t without costs. 
* AT, e.g. Jaws, supports <footer> as content info but do
  not support this new element.
 # COUNTER ARGUMENT: <footer> is presented to AT as content info because its default role is contentinfo. By defining the same role for <bqcaption>, AT users get the same experience.