Re: aside and figure elements

Laura Carlson wrote:
> 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?
>
>   

Not part of the group, but I wanted to respond to this question, and 
also explain why I said neither is accessible. Thanks for cc'ing me on 
the email, Laura.

Some time back when we were discussing all of the new elements, I made a 
statement that so many new elements are going to be a burden on AT 
devices, too. At that time, one of the group members stated that rather 
than AT devices having to learn the new elements, such as "figure" and 
"aside", each would be mapped to the existing accessibility API by the 
browser companies, so they would be accessible "out of the box".

This made a lot of sense to me, and is the reason I didn't include the 
elements being an additional burden on AT devices as an objection to 
figure and aside.

However, seems to me for this to work, this accessibility mapping needs 
to be stated. Otherwise, each browser vendor could map the elements 
differently. Now, perhaps another spec is the place, but I would think 
that the HTML5 spec would be the better place, since it is the spec that 
originated the elements.

I'm not sure how the accessibility API mapping would work, though I've 
seen the spec that provides User Agent instructions. However, from a 
ARIA to element mapping perspective, I'm not sure how figure and aside 
would map. For instance, if aside is treated as a typographical sidebar 
or note, there is an ARIA role of note that fits this use. However, if 
aside is treated as a web page sidebar, the more appropriate role is 
complementary. The two are not the same in ARIA, so we have to assume 
the two are not the same in the accessibility API, either.

So, in my opinion, I don't believe aside, as currently defined in the 
HTML5 spec, is accessible. I'm not an accessibility expert, though. 
Perhaps the experts don't see this as a problem.

Figure is another issue, as you have also noted. If figure really were 
captioning for a graphic, I think there could be a clean accessibility 
mapping, but because figure can include most anything, you start to have 
some interesting issues.

And figures really aren't meant to be 'skipped' typographically. They're 
actually an important part of the content, but are managed differently 
because larger images may not fit well where they are needed within 
printed material. When people say, "See Figure ..." they really mean for 
folks to look at that figure -- it's complementary to the text. It 
clarifies and expands on the text. It's never meant to be skipped.

I'm not sure how figure got redefined to something that can be skipped. 
 From an accessibility perspective, though, if it's managed as something 
that can be easily skipped, those needing this functionality may end up 
with a less than ideal experience. They may actually _lose_ important 
information.

In my read of the HTML5 spec, I don't see anything addressing these 
issues. I imagine this could be covered in another spec, but there's 
nothing detailing this, or providing a plan.

Anyway, your questions are good. I failed to get the elements removed, 
and am concerned that this failure then meant that these elements were 
not going to be 'cleaned up'. I should have provided an alternative 
change proposal--keep the elements and redefine and clean them up--but I 
genuinely believe the ARIA approach to be the better one, and couldn't 
support an alternative I felt to be inferior.

> 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
>
>   

Shelley

Received on Sunday, 6 June 2010 15:57:15 UTC