Re: aside and figure elements

Steven Faulkner wrote:
> 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>
>   

There's a couple of issues with this.

For one, there's an assertion in the HTML5 specification that the figure 
element can be moved to another location, and there's an implied 
connection between the material. A second assertion in the 
counter-proposal gives the impression that figure elements can be 
"skipped" and returned to later.

Both are expectations that don't map to a normal grouping element, such 
as div or p. In addition, if the figcaption element is not supplied, how 
would we differentiate between figure and div and p? Or I should say, 
how would UAs differentiate?
> # 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="">
>   

Agree, 100%.
> # 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.
>   
Disagree, 100%.

The figure element can have a dozen images, two tables, a code block or 
two, paragraphs, and div elements. The figcaption names all of this, not 
just the img element (s).

The alt attribute must be provided regardless of figcaption, as figure 
is defined now.


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

Again, though, considering the fact that the figure element can contain 
any number and types of elements, I don't think you can imply anything 
about a direct figcaption to img association.

I think each img element just has to live on its own, as if the 
figcaption didn't exist.  Unless, as you say, the aria-labelledby 
attribute provides a more granular definition of the association between 
the two.

> <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 ""
>
>   
And technically, can't. Not with the current figure definition.
> <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.
>
>   

Agree, 100%.

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

Shelley

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

Received on Monday, 7 June 2010 16:18:56 UTC