W3C home > Mailing lists > Public > public-html@w3.org > June 2010

Re: aside and figure elements

From: Steven Faulkner <faulkner.steve@gmail.com>
Date: Mon, 7 Jun 2010 13:54:39 +0100
Message-ID: <AANLkTimjRYNkcY1PsTxZOjm5TfrGNy5rsFVMPIEKMECX@mail.gmail.com>
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Cc: Laura Carlson <laura.lee.carlson@gmail.com>, Shelley Powers <shelleyp@burningbird.net>, HTML WG <public-html@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
hi leif,

> Unless I misinterpret what you say, then WAI-ARIA disagrees with you
> (and Shelley has been using the same example in her discussion of the
> issue). WAI-ARIA "blesses" a construct which is 100% identical to a
> <figure> containing a presentational <img> in combination with a
> caption: [1]

yes you are misinterpreting me as I stated that

>> my take on the figure element is that the
>> # <figure> should be mapped to accessibility APIs as a grouping
>> element like <p> or <div>

the ARIA example you referred to moves the role of img from the img
element to the the div, this is what is reported by MSAA and
Iaccessible2 for the example code:

MSAA
Name:	A visible text caption labeling the image.
Value:	(none)
Role:	graphic
State:	(none)
Description:	(none)

IAccessible2
Name:	A visible text caption labeling the image.
Value:	(none)
Role:	graphic
State:	Horizontal, Opaque, Selectable text

so in this case the <img> element would be redundant as the img role
is provided via the role="img". problem I see with the ARIA example is
that it only works if there is one image inside the div, it also only
works for a single image not other stuff inside figures.

WAI-ARIA "blesses" a construct which is 100% identical to a
> <figure> containing a presentational <img> in combination with a
> caption: [1]

well no, as the img role is still there, its just been moved.

> I agree that img with *both* content inside @alt as well as a <figure>
> caption, is a problem. We will sure see many cases where the @alt and
> the caption contains the same text.

that is why i suggest the caption should be mapped to the accessible
description rather than the accessible name, which is always announced
by default.


>> <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>
>
> And what happens to the @alt text here? Does it get ignored in UAs that
> *are* ARIA compatible?

note that the aria labelledby consists of 2 references 1 to the img
itself and 1 to the figcaption
for browsers that support aria-labelledby the accessible name is

MSAA
Name:	dog on a bike. Chester can ride without using his paws.
Role:	graphic
	,

for browsers that do not support:

MSAA
Name:	dog on a bike.
Role:	graphic


>> but again aria-labelledby is only supported by a subset of browsers/AT
>
> I suppose you meant ARIA in general and not specifically
> aria-labelledby.


no, I meant aria-labelledby, while it is true that ARIA in general is
only supported by a subset of browsers/AT, that subset is not
identical for all ARIA features.

> And just because you used content inside @alt, you also used
> @aria-describedby instead of @aria-labelledby? (I'll suppose you just
> didn't take care to make your text and your code congruent.) Is this
> also the reason why you filled the @alt with content?

i used the alt as it is the most robust method to programmatically
associate a text alternative with an image. I used aria-describedby as
i did not want the alt to be overwritten by the aria-labelledby:

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

MSAA
Name:	dog on a bike
Role:	graphic
Description:	Description: Chester the dog riding a bike without using his paws.

IAccessible2
Name:	dog on a bike
Role:	graphic
Description:	Description: Chester the dog riding a bike without using his paws.

labelledby example:

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

MSAA
Name:	Chester the dog riding a bike without using his paws.
Role:	graphic
Description:	(none)

IAccessible2
Name:	Chester the dog riding a bike without using his paws.
Role:	graphic
Description:	(none)




> It is not very satisfying if we "should" use
> @aria-describedby/-labelledby *and* fill the @alt with content, even
> when using <figure> - then it doesn't live up to (all) the
> expectations.

It is not very statisfying that no browser as yet supports the
accessibility mappings  for <figure> and <figcaption> elements, when
the do there will be no need to use ARIA to create those mappings.


regards
stevef







On 7 June 2010 13:01, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> Steven Faulkner, Mon, 7 Jun 2010 11:18:24 +0100:
>> 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="">
>
> Unless I misinterpret what you say, then WAI-ARIA disagrees with you
> (and Shelley has been using the same example in her discussion of the
> issue). WAI-ARIA "blesses" a construct which is 100% identical to a
> <figure> containing a presentational <img> in combination with a
> caption: [1]
>
> ]]
> In the following code sample, the containing div element has a WAI-ARIA
> role of img and is appropriately labeled by the caption paragraph. In
> this example the img element can be marked as presentation because the
> role and the text alternatives are provided by the containing element.
>
> <div role="img" aria-labelledby="caption">
>  <img src="example.png" role="presentation" alt="">
>  <p id="caption">A visible text caption labeling the image.</p>
> </div>
> [[
>
>> # 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:
>
> I agree that img with *both* content inside @alt as well as a <figure>
> caption, is a problem. We will sure see many cases where the @alt and
> the caption contains the same text.
>
>> 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>
>
> And what happens to the @alt text here? Does it get ignored in UAs that
> *are* ARIA compatible?
>
>> 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
>
> I suppose you meant ARIA in general and not specifically
> aria-labelledby.
>
>> 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>
>
> And just because you used content inside @alt, you also used
> @aria-describedby instead of @aria-labelledby? (I'll suppose you just
> didn't take care to make your text and your code congruent.) Is this
> also the reason why you filled the @alt with content?
>
> It is not very satisfying if we "should" use
> @aria-describedby/-labelledby *and* fill the @alt with content, even
> when using <figure> - then it doesn't live up to (all) the
> expectations.
>
> [1] http://www.w3.org/TR/wai-aria/roles#presentation
> --
> leif halvard silli
>



-- 
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 14:37:56 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:18 UTC