aside and figure elements

Hi John,

Shelley wrote:

>> I appreciate her effort, but I believe that Sam has shut down the
>> discussion, which is a co-chair prerogative. I'm waiting resolution on
>> several change proposals before I determine my next steps.

John wrote:

> I don't think the chairs (Sam) has shut down any discussion at all - he has
> clearly given all a 'next-steps' roadmap that actually has two options -
> file bug reports with specific actionable items, as well as leaving the door
> open to a Formal Objection (with an apparent preference for bug reports
> first).

Thanks. I hope people have the time and the wisdom to do what is best.

Creating elements that are inherently accessible, that provide
accessibility from the get-go, with no additional work by the author
is could be a win for accessibility. A mechanism to provide a native
aside element ala the WAI-ARIA "complimentary" landmark role is a good
idea. It could be applied to an area containing associated content.

In the counter change proposal it says that the aside element
"expresses this semantic directly in the markup, allowing other types
of UAs to give their users similar ability to skip over irrelevant
content and return to it at their leisure".

Do you think HTML5 specifies how devices are to interact with aside
and skip the content clearly enough? Do you see any flaws in the
specification of the aside element?

Do you (or anyone else) see any ways in which the aside element should
be improved in HTML5? Or do you consider it okay as is?

In regards to the figure/figcaption elements, there is no doubt that a
mechanism to explicitly provide a caption for an image is a good idea.

Do you think that the figure/figcaption elements are specified correctly?

The majority of style guides disallow tables as content for a figure.
But HTML5 does not. It allows any flow content in the figure element
not just images. Do you think this present any problems?

Do you anticipate nesting a table into figure causing any problems?

Do you see any issues existing with a figcaption + table caption
scenario? A table caption is read by JAWS. Do you foresee a figcaption
to be read in the same way? 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 speced correctly?

Do you think that multiple tables in a figure element would be read
correctly? It seems that they should linearize, do you think would
that they would?

The spec does not define how the figure is associated with the
original content. The counter proposal states,

"Users interacting visually with the article can easily skip past this
content temporarily and avoid interrupting their reading of the main
article, and then return to the content to understand it when they
feel comfortable. Expressing this semantic directly in markup allows
alternative UAs to present their users with the same ability, thus
improving Accessibility."

The spec does not say devices should have the ability to skip over the
figures, and return later, do you think that would be useful? The
figure element could be located outside of an article; it could be
located in another part of the web page, even another web page. It is
not specified how a connection between this physically separated
element is relate back to the original article element. Do you think
that the spec should specify how this is to be accomplished or
anything in this regards?

Do you (or anyone else) see any ways in which the figure element
should be improved in HTML5? Or do you consider the element okay as
is?

Thanks.

Kindest regards,
Laura

-- 
Laura L. Carlson

Received on Saturday, 5 June 2010 08:50:38 UTC