Re: aside and figure elements

Hi Shelley,

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

There is an ARIA mapping subgroup in the accessibility task force. I
think Steve heading that group.

Steve, has the ARIA mapping group discussed the aside or figure elements?

Thanks.

Best Regards,
Laura

On 6/6/10, Shelley Powers <shelleyp@burningbird.net> wrote:
>
> 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
>
>


-- 
Laura L. Carlson

Received on Sunday, 6 June 2010 19:21:41 UTC