W3C home > Mailing lists > Public > public-html@w3.org > August 2011

Re: how HTML5 figure and figcaption should/could work

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Wed, 24 Aug 2011 15:25:24 +0200
To: Steve Faulkner <faulkner.steve@gmail.com>
Cc: HTMLWG WG <public-html@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <20110824152524967023.259e4b4f@xn--mlform-iua.no>
Hi Steve,

Thought: just as caption cannot contain a table, perhaps figcaption 
should not be able to contain a figure element? 

Regarding the what you say about a caption role perhaps not necessary: 
I suppose those user that reports that it works as is, are using AT 
that have a caption role and where the figcaption has been mapped to 
have that role? - And thus I assuem that *no other* content, in case 
figcaption si lacking, for instance, would be used as caption? If so, 
isn't that a reason to add the caption role? At least, I don't see that 
it would not hurt? 

But how do you know that caption's ability to take flow content does 
not create problems? It is only with HTML5 that it has become 
permitted, and it has - so far - not been used very much in real 
content. Btw, to what degree is the content of a caption element being 
treated as semantic 'mark-up'? I ask because I associate 'accessible 
name' with @alt text and other 'info strings' without markup - the 
<caption> element has, so far, only used to contain so light mark-up 
that it did not hurt very much to just present it as a string.


Steve Faulkner, Wed, 24 Aug 2011 13:52:05 +0100:
> Hi leif,
> in initial feedback from users it seems as if the additon of a 
> caption role for ficaption may not be needed as the figcaption 
> content would be mapped as the accessible name for the figure.
> Note that in some accessibility APis there is already a caption role 
> defined [1], the addition of one in ARIA would be for APIs that do 
> not have a caption role defined.
> In regards to figcaption being able to accept flow content, i don't 
> think this is an issue, the caption element has the same content 
> model (with the exception it cannot include a table) [2] and that 
> does not cause a problem for its use as the accessble name for a 
> table.
> regards
> stevef
> [1] 
> [2] http://dev.w3.org/html5/spec/tabular-data.html#the-caption-element
> On 24 August 2011 12:51, Leif Halvard Silli 
> <xn--mlform-iua@xn--mlform-iua.no> wrote:
>> Steve Faulkner, Wed, 24 Aug 2011 12:37:37 +0100:
>>> I have written some stuff down about how figure and figcaption could
>>> work for screen reader users, as currently it is not accessibility
>>> supported in browsers or AT.
>>> I think there may be the need to create a new role to represent
>>> figure, probably an ARIA landmark role.
>>> I am asking for feedback from users and implementors.
>>> any feedback would be appreciated
>> +1 I defintely think that a new, default role for figure is needed.
>> As for caption role, which you also propose, would <caption> also get
>> the same role? And what about the problem that Rich takes up in that
>> regard - that figcaption -- and caption has the same issue - can take
>> flow content. [1] Perhaps the default role should not be used if it
>> contains flow content?
>> [1]
>> --
>> Leif Halvard Silli
> -- 
> with regards
> Steve Faulkner
> Technical Director - TPG
> www.paciellogroup.com | www.HTML5accessibility.com | 
> www.twitter.com/stevefaulkner
> HTML5: Techniques for providing useful text alternatives - 
> dev.w3.org/html5/alt-techniques/
> Web Accessibility Toolbar - 
> www.paciellogroup.com/resources/wat-ie-about.html 
Received on Wednesday, 24 August 2011 13:26:24 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:16 UTC