Re: aside and figure elements

hi laura,
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:

In this case the accessible name is "Dog on a bike. Chester can ride
without using his paws."

<figure>
<img id="img1" alt="dog on a bike." aria-labelledby="img1 cap">
<figcaption id="cap"> Chester can ride without using his paws.</figcaption>
</figure>

In this case the accessible name is "Dog on a bike." and the
accessible description is "Chester can ride without using his paws."


<figure>
<img id="img1" alt="dog on a bike." aria-labelledby="img1 cap">
<figcaption id="cap"> Chester can ride without using his paws.</figcaption>
</figure>

In this case the accessible name is "Chester can ride without using
his paws." which I think is an unsatisfactory text alternative as it
does not provide adequate information about what is depicted visually
in the image.

<figure>
<img >
<figcaption >Chester can ride without using his paws.</figcaption>
</figure>

while this would be better, but it is still currently problematic from
a practical point of view as no browsers or AT provide the
programmatic mapping between the <figcaption> and the img. So the
accessible name provided through an accessibility API is ""

<figure>
<img >
<figcaption>Chester the dog riding a bike without using his paws.</figcaption>
</figure>

Using aria-labelledby is better in this case because for users of
AT/browsers that support aria-labelledby the programmatic association
will be provided,
<figure>
<img aria-labelledby="cap">
<figcaption id="cap">Chester the dog riding a bike without using his
paws.</figcaption>
</figure>

but again aria-labelledby is only supported by a subset of browsers/AT
so the safest bet is to provide an adequate accessible name using alt
attribute.

<figure>
<img aria-describedby="cap" alt="dog on a bike">
<figcaption id="cap">Chester the dog riding a bike without using his
paws.</figcaption>
</figure>

regards
steve

On 6 June 2010 20:21, Laura Carlson <laura.lee.carlson@gmail.com> wrote:
> 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
>
>



-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html

Received on Monday, 7 June 2010 10:19:21 UTC