Should figcaption participate in name/desc computation?

[mbgower]

I have seen a growing number of occurrences where people are properly using the figcaption as a child of figure, and have useful information in the caption, but are failing a checker because figcaption is not included in the computation for either name and description.

As per my issue opened with wcag w3c/wcag#852 I think a case can be made that figcaption could be used for either a name or description, depending on circumstances. Has consideration been given to including it?

If you proceed with its incorporation, it is my intention to create a complementary technique for WCAG that helps authors appropriately use it.

[cookiecrook]

Can you link to a few of the occurrences you mentioned? If you can't link all of them, including code snippets of the markup (etc.) may help the editors ensure they account for all intended uses.

[jnurthen]

@mbgower I think this discussion belongs in HTML-AAM which defines the accessible name computation for an img element with no ARIA involved - which I believe this is.

personally (non chair hat) I don't think this is a good idea - the figcaption for a figure really acts more like a long description than a text alternative.

[mbgower]

@jnurthen

personally (non chair hat) I don't think this is a good idea - the figcaption for a figure really acts more like a long description than a text alternative.

If so, then shouldn't it be part of the accessible description calculation?

[jnurthen]

@mbgower in simple cases maybe - and HTML-AAM may make that decision.
However we should take care as IMO the figcaption may contain markup that makes it inappropriate to be converted to a flat string to fit into an accessible description.
IMO it should probably be neither and there should be an aria-details relationship between the image and the caption.

[mbgower]

@cookiecrook said

Can you link to a few of the occurrences you mentioned? If you can't link all of them, including code snippets of the markup (etc.) may help the editors ensure they account for all intended uses.

Here's an example of why I think it can get pretty redundant https://developer.mozilla.org/en-US/docs/Web/HTML/Element/figcaption

As well, some of you looked at the original ticket, which has Laura's example:
<figure>
<a href="../images/painting1x.jpg">
<img id="painting" src="../images/shalott.jpg" alt="The Lady of Shalott" title="select for a larger image" width="400" height="299"></a>
<figcaption>The Lady of Shalott by John William Waterhouse. A painting inspired by Tennyson's poem. <a href="../ld/shalott.html">A description of the painting is available.</a></figcaption>
</figure>

If there was no 'alt' specified in either of those situations, it seems hard to argue there is no information about the image.

I'm seeing conversations like this happening.

1. How does alt text apply in social (e.g., Pinterest, Instagram) when an image also has a caption? Is Alt Text needed as well?
   RESPONSE: re: 1 - alt text when an image also has a caption? Same requirement in regular web content and/or social media - do NOT make the alt text and caption redundant (repeated twice), use alt="".

I think that's a poor response (it's not mine!), as most screen readers currently don't get anything from figcaption, but that's the kind of conversation I'm seeing. My motivation for grappling with this is that a natural 'low fi' solution to this seems to be for devs to regurgitate the figcaption as the alt, which just adds verbosity. @mraccess77 made a somewhat related comment about verbosity in the WCAG thread.

Thanks for giving this your consideration, and I've understood some of the points made. I'm not fixated on 'winning' figcaptions inclusion. I'm just looking for a decision and rationale that I can easily explain to dev teams so that they can understand and execute consistently with the best outcome.

[accdc]

Hi,
In reviewing this further, it seems that we can't easily dismiss the need for this.

I recently had to identify an issue where a figure was included within a link and no accessible name was being produced for the link even though the figure was properly configured to provide one.

It seems that logic similar to the way that SVG is treated is appropriate, which is documented within the AccName spec (in a basic way) may be needed at the very least to convey the association.

I agree it is confusing, even within the ARIA and HTML spec seems to be somewhat contradictory about this.
https://www.w3.org/TR/html-aria/

Figure:
"role=figure"
"If the figure has no figcaption descendant:
Any role
If the figure has a figcaption descendant:
No role."

Figcaption:
"No corresponding role"
"Roles:
group,
presentation
or
none.
Global aria-* attributes
and any aria-* attributes applicable to the allowed roles."

Suggestions about how to address this is welcome.

[scottaohara]

i don't understand how you're interpreting ARIA in HTML to be contradictory here? It's saying nothing about how an accName is calculated, but rather providing scenarios (conditionals for `figure) on what roles could be used on these elements.

on this particular topic, I'm currently thinking that @jnurthen comment that a figure could treat a figcaption as if it has an aria-details relationship would be a good one. I've found few instances where users have actually appreciated figcaption, especially verbose and heavily structured figcaptions, as the accessible name for a figure.

I like the idea that that's how the relationship between these elements are specified, and that if authors want to provide a figure an accessible name, they would instead do so solely through aria-label, aria-labelledby, or title.

cc @cookiecrook @joanmarie @aleventhal – would appreciate your feedback on this idea. good, bad, meh? or is this potentially a "this ship has sailed" situation and the internet needs to be peppered with better author guidance on using figure and figcaption (with or without images as the primary subject of the figure_?

[accdc]

Perhaps not contradictory, but unclear. The syntax of a figure element has a specific means for assigning textual content, and it is unclear to me, and likely to many others, that you should ignore this if you want the figure to actually have an accessible name in the accessibility tree.

[mraccess77]

Captions and alternative text are two different things and serve different purposes. I think it would make sense for figcaption to either be fallback accessible name only when no other name for the image is available or otherwise figcaption could act as an accessible description.

[accdc]

Personally I like the idea of this being a fallback for figure when needed. The case I am trying to cover is when someone puts a figure inside a link.

[scottaohara]

@jnurthen let's use this as the issue to start the discussion on what to do with figure > figcaption

[scottaohara]

from the ARIA wg meeting today, remove figcaption from the accName computation for figure. instead figcaption should create an aria-details association with the figure.

i need to make this change then then file the necessary platform bugs