Re: aside and figure elements

Hi Steve,

Thank you very much for your thoughtful and comprehensive responses.

> we haven't discussed the <figure> element.
>
> my take on the figure element is that the
> # <figure> should be mapped to accessibility APIs as a grouping
> element like <p> or <div>
> # decorative images should not be allowed as content of a <figure>
> element as the HTML5 semantics imply that the content of the figure
> should be meaningful, so no <img alt="">
> # when a figure has a <figcaption> the content of the <figcaption>
> should act as the accessible name for the image(s) inside the <figure>
> if the image(s) do not have a text alternative provided using the alt
> attribute.
> #if the image(s) inside the figure have alt then the <figcaption>
> content could act as the accessible description unless for example the
> figcaption is referenced by an aria labelledby on an img:

This makes sense.

Have you thought about tables inside of a figure? When a table element
is the only content in a figure  element other than the figcaption,
the spec says that the caption element should be omitted in favor of
the figcaption do you think this is specified correctly? It seems to
me to make sense. Should it be extended to mention grouping multiple
tables in a figure? (figcaption + caption +caption +caption scenario).
 Or do you consider this would not be needed?

> missed the bit about <aside>
>
> this would map to ARIA role="complementary", though it should be noted
> that that most accessibility APIs don't have a specific role that maps
> onto "complementary" and it's role is passed to AT as a string value
> or it is ignored (in the case of MSAA). It is then up to AT as to how
> they expose this to the user.

This makes sense too.

Thanks again, Steve for taking the time to address this. Much appreciated.

Best Regards,
Laura

-- 
Laura L. Carlson

Received on Monday, 7 June 2010 13:42:50 UTC