In finding that the legend element simply doesn't work inside both detail and figure, myself and others been keen to find a solution.

Ian Hickson has said:

I am leaning towards keeping the language sane (not introducing yet another element that basically means "header" or "important" or "caption"), at the cost of delaying how soon we can use the feature.

The huge problem with this is that browsers will not catch up. IE is the dominant browser, and if IE6 to IE8 don't support the legend element embedded in anything other than fieldset then we, as authors, are going to have to find an alternative. This is where the spec is fiction.

I agree with Hixie that a new element isn't required that means "header" or "caption", but equally I believe we have enough in the spec to label the figure and detail elements properly.

Alternatives

I've gone through a number of alternatives with Jeremy and Bruce and I want to share them with you:

label

label: This was my initial favourite to work within the new elements, since what we're trying to do is label the figure or details that are tucked away.

The problem Jeremy raised was that of screenreaders. Are they going to look or assume there's an associated input element?

I'm not an expert on screenreaders, so I can't say for sure. Bruce suggests screenreaders may only look for the input element if the label is within a form. If this is so, then it's almost a good candidate.

My issue with this, is that it's perfectly reasonable, in my head, to have a figure within a form, which could cause screenreader problems.

Here's a label figure test: http://jsbin.com/elatu (edit)

caption

caption is used to add a caption to tables, which makes it a good candidate for captioning the figure and detail elements.

However, due to a similar bug as the legend issue, if the browser finds the caption element outside a table, it simply strips it from the DOM - which makes this a non-option.

Example of caption being stripped from the DOM: http://jsbin.com/eloda (edit) (view the DOM and you'll see the element has gone)

Heading

Could we use an hX tag? We want to give the figure or detail element a heading, so it stands to reason that we could use an h2 or h3, etc.

The problem is the TOC that's created. So to solve this we could wrap the in an hgroup, then it would be hidden from the TOC outliner.

My issue with this is that it seems over the top to include two elements just to solve this issue. I think the figure and detail need a heading, and although using hX elements make sense to me, it feels klunky (for want of a more expressive technical term!).

Header

header, to me, has a similar semantic meaning as an hX element, and we could reuse this to replace the legend in the figure and detail elements.

It wouldn't become part of the TOC, because you'd need an hX element to create a new item in the TOC. This also doesn't cause any issues with screenreaders (if in fact label does).

Here's an example of header being used in the wild (for the button example on the right): http://2009.full-frontal.org/ticket-draw

Conclusion

It's my opinion is header is the best fit, but we need to discuss and find an alternative to hoping the browsers will fix the legend issue.

HTML 5 paves the cowpaths but the use of legend isn't possible, so we must find an alternative if we want to sensibly uses this captioning feature.

I know using the html5.enable feature if Firefox 3.6b, but this still leaves all the other browsers (and Firefox 3.6 isn't even out) - so again, this isn't a solution (nor is serving the page as XML - since IE just chokes).

What do you think? Is there a better alternative? How do screenreaders react to label?

You should follow me on Twitter here I'll tweet about JavaScript, HTML 5 and other such gems (amongst usual tweet-splurges)