- 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>
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. Leif 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] > http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/_accessible_role_8idl.html#e37ff81431ee3762a5d41a2cb909108d11ca544bc937d13147ed52437e212e20 > > [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. >>> >> http://www.paciellogroup.com/blog/2011/08/html5-accessibility-chops-the-figure-and-figcaption-elements/ >>> >>> 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] >> http://www.paciellogroup.com/blog/2011/08/html5-accessibility-chops-the-figure-and-figcaption-elements/comment-page-1/#li-comment-14964 >> -- >> 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:15 UTC