search

w3c / wcag

Web Content Accessibility Guidelines
https://w3c.github.io/wcag/guidelines/22/
Other
1.09k stars 248 forks source link

No technique using figcaption to meet 1.1.1 Non-text content #852

Open mbgower opened 5 years ago

mbgower commented 5 years ago

The use of the figcaption element as a child of figure to provide non-text content for an image that is also a child, seems like, at the least, an acceptable method of providing a long text alternative technique for Sitaution B of 1.1.1. However, there do not seem to be any techniques employing figcaption. I would like to understand if this is just a gap in the tecniques guidance, or if there is a reason figcaption is being disfavoured as a means of offering non-text content text alternative.

mraccess77 commented 5 years ago

I think such a technique could pass However, we’d have to be very clear that a caption and alternative are often two distinct things Captions often describe how a figure or image relates to the content rather than being in equivalent to it

lauracarlson commented 5 years ago

Some References:

@stevefaulkner had some examples in HTML 5.1:

lauracarlson commented 5 years ago

I forgot to mention Image of a Painting Using a Link in a figcaption Element is an example that I created for the classes I teach. We could think about using or adapting it or something like it for a long text alternative technique.

alastc commented 5 years ago

I suspect that there isn't a technique with figcaption because it didn't exist when WCAG 2.0 came out?

It could be an update to G74, e.g. adding an example there?

Ryladog commented 5 years ago

Yes Alastair, and it is a gap, therefore an example should be added but will need careful wording to address Jon's point.

katie

alastc commented 5 years ago

I think Laura's example is a good one and includes the difference that Jon was talking about.

I just meant that conceptually it is very similar to G74 "Providing a long description in text near the non-text content, with a reference to the location of the long description in the short description"

Next step, include Laura's example (or one like it) in G74 and do a pass over the technique to make sure it all makes sense with that context added.

mbgower commented 5 years ago

I have a couple of comments on 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>

First, it's a complex example, and also includes the use of a (really) long description. So I'm not sure it should serve as the only example. I believe there are many situations where no additional long description affordance exists and we could get by quite well with just the figcaption.

Second, I'd like to confirm that the alt text in Laura's example can be considered redundant. Every word of it is in the figcaption (and in my opinion, the figcaption is a better text equivalent than the alt provided; it could lose the second sentence and still be better):

The image and the caption are inside the same parent figure element. Is there any reason the alt could not be "" or even left out? Would anyone fail that? There is programmatic association. Has anyone validated that current user agents and ATs fail to surface that? And if so, do we consider that an issue for the author?

Third, I think it's pretty important that we define some situations where the figcaption and the alt text DO differ in purpose and both should exist. There are a couple of obvious examples:

  1. A screenshot, where the figcaption describes the intended 'take away' for the image (the reason the screenshot was included in the first place) while the ALT text would be providing any text inside the screen shot that was relevant but wasn't called out in the figcaption, say the actual wording of an error message, whereas the figcaption just says "the error".

  2. An illustration, where the figcaption describes the function demonstrated, but the actual steps in a process are not described, yet are pictured in the image. Figcaption could be "The development lifecycle" but it doesn't state there are certain steps shown; the alt text would need to provide that, along with the labels in the diagram if they existed.

You'll note that in both these cases, the figcaption typically relies on viewer being able to visually scan the image/illustration to get some context, and is summarizing the purpose. In such cases, where there is important visual information conveyed that is not covered in the figcaption, that must be supplied by the ALT.

mraccess77 commented 5 years ago

I would discourage use of figcaption as the alternative text as captions and alternatives are two different things. In the example the alt and caption look like captions and I don't really see something that truly acts as an alternative for the image.

mbgower commented 5 years ago

I find the testing by Graham, which Laura refers to, interesting from a technical perspective, and existing implementations and capabilities may ultimately be the persuasive argument, but I do want to challenge @mraccess77's latest statement.

I would discourage use of figcaption as the alternative text, as captions and alternatives are two different things.

The fact that in Laura's example the text in the alt attribute is wholly contained within the text in the figcaption seems to me logically to indicate that the figcaption is meeting that function according to the language of 1.1.1.

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.

Given the figcaption text that exists in the Lady of Shalott example, what would be the ALT provided that would not be redundant?

JAWS-test commented 5 years ago

Just for information: figcaption is not well supported by screen readers. See e.g. https://github.com/FreedomScientific/VFO-standards-support/issues?q=is%3Aissue+figcaption

mraccess77 commented 5 years ago

In this example the linked description provides the alternative to the image that is needed -- so when viewed with the long description it meets the requirement. But I don't think we should promote a caption as an alternative as captions are supposed to be a title or explanation of the image and something used for a table of captions. Alternatives are an equivalent -- those are different.

The other thing it doesn't do which most people forget is the alt text must reference where the description can be found. So in this case the alt text must reference the longer description link below -- see the definition of "text alternative" below.

text alternative Text that is programmatically associated with non-text content or referred to from text that is programmatically associated with non-text content. Programmatically associated text is text whose location can be programmatically determined from the non-text content.

Example: An image of a chart is described in text in the paragraph after the chart. The short text alternative for the chart indicates that a description follows.

mbgower commented 3 years ago

Returning to this based on another example I've run into in real life where the figcaption is conveying more than the proposed 2-word ALT to 'fix' the failure.

@mraccess77 said:

the linked description provides the alternative to the image that is needed

Just to make clear we're comparing apples to apples here. There is an alt on this image, and it is "The Lady of Shallot".

If you were skimming a catalog for a museum program, I think you'd be quite happy to have a short ALT for each of the images, in addition to a detailed description available to you, should you wish to hear it.

So in many contexts, 'Lady of Shallot' is a perfectly 'okay' ALT, in that it identifies the image, and so meets Situation A: If a short description can serve the same purpose and present the same information as the non-text content.

Is anyone advocating that every single image on the internet have a detailed long description of exactly what is being depicted down to the use of color? It could make for some very long reading.

What I'm suggesting is the following should not fail the computation: <figure> <a href="../images/painting1x.jpg"> <img id="painting" src="../images/shalott.jpg" 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>

All I have done is remove the alt="The Lady of Shalott" You have a figcaption that is a child of the figure that gives MORE text for the figure, including every word of that alt text. You also still have the additional description offered by Laura, in fact in this scenario, notice of it is now part of the calculated alt.

However, this will fail because figcaption is not used as part of the accessible name query -- and for no other reason.

Note that the accessible name computation does not scrutinize the content of the name and description. It merely checks to ensure a value exists.

One is still going to have to consider whether there is more that necessitates an ALT or a long description. I've already addressed that in prior comments

mbgower commented 3 years ago

@JAWS-test said

Just for information: figcaption is not well supported by screen readers.

Given that is it not used in the name and description computation, that's not really surprising. But if it was brought in (if even to the description), I suspect you'd see traction more quickly.

mbgower commented 3 years ago

@alastc I'm going to put this issue 'on hold' pending a response from the accname group. If they reject using it as part of the computation, obviously I'll close this. If they incorporate, I will create a new technique that complements their decision appropriately, using all the info shared in this issue. Thanks in paricularly to @lauracarlson for all the background info! Alastair, if you'd prefer to close this now and reopen based on an accname decision, go ahead.

scottaohara commented 3 years ago

@mbgower figcaption provides the accessible name to a figure https://w3c.github.io/html-aam/#figure-and-figcaption-elements

and since a figure can contain any sort of information that needs a caption associated with it (e.g., a quote, code snippet, video, etc.) I think it'd be odd for a figcaption to provide an accessible name/desc in the instance an image is used within the figure, but perform a different function all together for other content.

as another example, what happens when there are two images included within one figure?

truly each image should be given its own alternative text to indicate what it is, and the caption should be used to provide context to all users as to how the content within the figure is related to the primary content / what specifically about the content within the figure is important for all users to understand.

mraccess77 commented 3 years ago

On a related question - to meet SC 1.1.1 or 1.3.1 do figure elements require an accessible name? Figcaption is optional - but is some other provided accessible name required?

Secondarily, if a figure element contains an img with alt could that act as the accessible name for the figure if no other one is provided?

Finally, some screen readers also seem to announce both the figure accessible name and image alt text - so accessible name for both can add verbosity. For example, JAWS announces the figure accessible name with the start, then any images with alt text and then figure accessible with element end.

mraccess77 commented 3 years ago

As an FYI - both Chrome (via accessibility inspector) and JAWS in Chrome appear to use the figure caption as the accessible name for the figure.

mbgower commented 3 years ago

as another example, what happens when there are two images included within one figure?

@scottaohara I'd say that at the least, the figcaption is describing both of them.

You understand the computation a whole lot better than me. :) I'm just hoping for some way that the effort devs put into properly using figcaption can result in a better experience.

since a figure can contain any sort of information that needs a caption associated with it

I'm wondering idly if the computation can accommodate things like 'if figure has both img and figcaption children, include the figcaption as a last resort name, or append it to the description'