Re: aside and figure elements

Laura Carlson wrote:
> Hi Shelley,
>
> Steve wrote:
>
>   
>>> # 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.
>>>       
>
> Shelley wrote:
>
>   
>> 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.
>>     
>
> Good catch Shelley. Okay, how about restricting it to:
>
> When a figure has an image as sole content use a  <figcaption> as the
> accessible name for the image. But in scenarios of multiple images in
> a figure element alt rules apply.
>
> Thoughts?
>
>   

It could work, but the problem with all these rules and constraints is 
that people will be confused, and will, most likely, use all of the 
elements incorrectly.

I would say that img should be treated the same, regardless of whether 
it's in a figure element or not. It should have a non-empty alt tag. We 
hope people would have enough commonsense not to use figure for a 
decorative image.


> Thanks.
>
> Best Regards,
> Laura
>
>
>   

Regards

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