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

Re: aside and figure elements

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Mon, 7 Jun 2010 16:59:45 +0200
To: Steven Faulkner <faulkner.steve@gmail.com>
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>
Message-ID: <20100607165945541767.afcac9a7@xn--mlform-iua.no>
Steven Faulkner, Mon, 7 Jun 2010 13:54:39 +0100:
> 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>

As far as I can see, I did not misinterpret you. We, however, probably 
disagree/have different expectations about what the figure caption is 
the caption of.  Above you describe *your* take on <figure>. *My* take 
on <figure> is inspired by <table>. Thus I believe that, by default, 
the caption element of <figure> (<figcaption>, as it is currently 
called)  should caption the entire <figure> element, and not 
specifically the <img>.

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

This is the same for <caption> of <table>: it is possible to provide a 
<caption> without providing any content in the table. I see no problems 
with the above MSAA and Iaccessible2 interpretations.

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

Hm ... You are (technically) right:

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

But which role do you think <figure> should default to have? 

I think the following would make sense - it is the way I hope <figure> 
will work (here I present the WAI-ARIA example as a <figure>, using 
<summary> instead of <figcaption>):

<figure role="img">
  <img src="example.png" role="presentation" alt="" >
  <summary>A visible text caption labeling the image.</summary>
</figure>

Also remember that Ian think that <figure> can contain a <table> and 
says that the <table>'s <caption> should then not be used. Thus one 
should expect the following (not?):

<figure role="grid">
  <summary>A caption for the table.</summary>
  <table><tbody>
       <tr><th>head</th>data<td></tr>
  </tbody></table>
</figure>


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

Well, that does not solve the potential duplication problem, does it? 
An accessible *description* (aria-describedby) is, to quote ARIA, "a 
description is intended to provide additional detail that some users 
might need".

Thus, an accessible description is content that some users may want to 
skip. Would you expect that users would skip the figure caption? I 
suppose not.

(The confusion between aria-labelledby and aria-describedby is a 
constant problem - and *here* the consequences of that confusion really 
surfaces.)

I don't think that we should default the figure caption to the role of 
(to put it a little awkward) aria-describedby just because many authors 
may duplicate the content of the figure caption in the @alt.

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

Irony: While you advocate well marked-up web pages for accessibility, 
your e-mail messages are often difficult to follow and disordered. And 
in this case, you even manage to confuse *yourself* because of your 
sloppy writing style ... This is what you said in previous message - 
and I perceived the preceding text of each example to be a description 
of the following example:

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

But, as you can see, even though the introductions to examples are 
different, the two examples are identical.  Thus, when I asked, then 
assumed that the last example was different from the first.


> 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

OK.  But anyway, what I wanted to know (and what I thought you showed 
an example of) was what happens when the figure looks like this:

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

Note, again, that this is how I believe it should be done,

<figure role="image">
<img alt="Dog on a bike.">
<summary> Chester can ride without using his paws.</summary>
</figure>

and for this I would expect the following ARIA interpretation :

	Either:

Name: Chester can ride without using his paws.
Role: img
Description: Dog on bike.

	Or:

Name: Chester can ride without using his paws. Dog on bike.
Role: img
Description: none


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

So you suggest using @aria-describedby because it is better supported? 
Sounds like turning things on the head. Though I will of course not 
rule it out, yet.

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

I believe the default should be that the figure caption 
(<summary>/<figcaption>) by default should be an accessible *name* for 
the entire <figure>. Those UAs that do not support ARIA, will have to 
rely on the element grouping effect for associating the caption with 
the image. 

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

Above you don't use the <figure> container - you believe you can make 
your point without it. It is *really* funny that you don't count in the 
fact that the <img> and the figure caption are contained in a grouping 
figure element ....

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

So what you have trouble with here is that the @alt text gets lost. 
However, I don't think that we can rewrite the purpose of the caption 
element just because of <img>. It could be that it would be useful for 
authors to manually designate the @alt as the accessible name. But I 
don't think this what it should default to.

 E.g. what if the <figure> contained the image as an <object> and with 
a fallback table inside?:

<figure role="grid">
	<summary>A table of Opera usage statistics.</summary>
    <object data="tablle.svg" type="image/svg+xml">
      <table>[...]</table>
    </object>
</figure>

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

Well, first we have to come up with a credible default aria and role 
mapping regime for <figure>.
-- 
leif halvard silli
Received on Monday, 7 June 2010 15:00:56 UTC

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