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

Re: how HTML5 figure and figcaption should/could work

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Wed, 24 Aug 2011 14:43:01 +0100
Message-ID: <CA+ri+VmN=USSEmm5nYgChFO7cC=QG9Fpi8-vvitqCUr-HZpbnw@mail.gmail.com>
To: Chris Adams <chris@chrisadams-studios.com>
Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, HTMLWG WG <public-html@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Hi Chris,
while i agree it may be worthwhile, it is such a chore in most cases to get
a chnage made to  HTML5, it is something that I don't see as a high priority
right now.
I think its more a case of in most cases authors will not put silly stuff in
the figcaption as they don't see a need to.

best regards
Steve

On 24 August 2011 14:37, Chris Adams <chris@chrisadams-studios.com> wrote:

> Perhaps it would be wise to define exactly what content is valid within
> figcaption (and caption)
> while there are valid use cases for some elements (cite being the example
> used in the current draft ) many other elements do not make sense, such as
> form or script elements
>
> On Wed, Aug 24, 2011 at 09:25, Leif Halvard Silli <
> xn--mlform-iua@xn--mlform-iua.no> wrote:
>
>> 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
>> >
>>
>>
>
>
> --
> ~ Known Some Call Is Air Am ~
> Chris@chrisadams-studios.com
> ph: 614.654.4119
> http://www.chrisadams-studios.com
>
> -------------------------------------------------------------------------------------------------
>
> This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed.  If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone.
>
> Please contact the sender if you believe you have received this email in error.
>
>
>


-- 
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:43:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:44 GMT