I disagree as a screen reader user. To be clear, I completely support your assertions around describing complex imagery, e.g. the alt text is a completely inappropriate place to describe a graph, chart, etc. But a figcaption with no accompanying figure content is semantically wrong. If you have a figure with a textual description or semantic representation of the data displayed in an image, e.g. a table behind a disclosure button, then fine: the figure body is meaningful, as is the caption. But if I'm testing a site and find cases of figures where the only screen-reader-accessible element is the figcaption, that is an antipattern that I will insist be addressed.
What would you do? For a concrete case, let’s say you have a bar chart in a <figure> with the figcaption “Figure 3: results of Benchmark Q, showing X to be 40% faster than Y.” What alt attribute would you give the <img src=benchmark-results.svg>?
Let's imagine a more realistic bar chart with the results of benchmark Q, showing the speed difference of X and Y in four different [resolutions/tasks/memory limits/processors/whatever], so 4x2 bars. Should the advantage of X over Y and all the other patterns visible in the chart be described in the figtext? IMHO not. In such a case, a reasonable alternative for that content would be not a sentence but a data table, providing all the information but leaving the interpretation up to the reader - just as for the visual chart.
Completely agree with this (and your other comments re: interpretation). In the real world, it's rare for content and data to be as simplistic as the example described here, and presenting it in an inclusive fashion which allows all users to make their own conclusions is the key.
In this case, the bar chart most likely should be accompanied by an accessible textual alternative. For example, a link to a textual version/download of the results, a disclosure button you can hit to view a textual description, a table, whatever. If that is included, the img itself can be marked decorative, because the figure contains an accessible body element as well as the caption. For me, that would most likely be enough to pass my semantic and accessibility requirements.
On the other hand, if you're not going to provide that or feel that the caption already sufficiently describes the data, you could provide a straight visual description of the image for the img's alt. For example, which data is shown on which axis? Not all screen reader users will find that helpful, but there are two things to keep in mind:
1. If a screen reader user moves into the figure with certain keystrokes, the text of the figcaption will be announced as the figure's accessible name or description. So the presence of alt text need not in any way block them from getting to the data.
2. Are you catering for all possible screen-reader-using audiences? Okay, if I'm reading an article about the benchmarks between two databases or something on a blog, it's more personal/for work and I just want the data. But what if I'm in a classroom setting and need to tell my students how to read this chart? If I don't know anything about the layout of the data, I can't do it.
A straight visual description of the diagram is probably inappropriate for alt text: too long, too wordy; it’s the longdesc problem again.
I’m not convinced that there is a properly correct solution here.
We're now entering the realm of what represents a caption and what doesn't. Given my earlier point that the figcaption text is mapped as the accessible name or description for screen reader users, interactive elements inside the caption should be avoided because they don't make sense when spoken inside a flattened, plain text string. So to answer the specific question, "now what?" Don't put the link inside the figcaption, put it inside the <figure> as a sibling of the image (or inside a container which is a sibling of the image).
To look at it another way: I might be inclined to say that caption text should make sense when presented with the accompanying image in a non-web context (e.g. a printout). This is why captions are often used for credit lines, attribution info, etc.
> I’m not convinced that there is a properly correct solution here.
Without a more specific use case, it's difficult to make a recommendation. However, I will say one thing that I've found to be universally true: the power of the image description is often underrated. I've had many conversations with designers, developers, content editors et al, where the assertion has been made that there's not much to describe in a particular image. And then as a blind user, I have multiple questions about what it shows, the answers to which can make it into the descriptive text.
This is often a lightbulb moment for many, as they realise that actually, all those details I asked about were subconsciously filled in/processed, and they just didn't think about them. Data is the same.
Is a bridge too far. Sure you should summarize the key takeway of a chart, but a chart has a lot of detail that sighted users don't need to reread in a worse layout, but blind users need a way to access.
There’s no good way of exposing lengthy information about a chart to screen readers. Don’t try doing it via alt, it’s a bad experience; and don’t try doing it by screen-reader-only text, that just gets confusing. The longdesc attribute was an attempt to do this, but it failed to gain traction among users or assistance tech. Consensus now is that you should instead include in the caption a link to a page that focuses just on the chart, which can then include more detail for the screen readers.
The primary categories of images that exist are:
• Decorative or ornamental imagery. Part of art direction; typically implemented with CSS (commonly background images) rather than <img> these days.
• Stock imagery. Part of art direction. An annoying waste of time, space and bandwidth that is unfortunately valuable because of human psychology.
• Meaningful figures: photos, diagrams and other images that are actually related to the content.
Art direction <img> tags should always have an empty alt attribute, even stock imagery: because it’s not adding anything to the content. (I hear someone crying, “but I put that stock image there for a reason!” Sure, you put it there to manipulate a particular facet of human psychology, but it’s purely a visual phenomenon, and it doesn’t transfer to other media at all. In fact, rendered to speech it’ll have the opposite effect, so drop it like a hot potato. There are equivalent phenomena for other senses, e.g. there’s a reason audiobooks, podcasts, &c. add music; but you can’t do that in this place.)
What remains, then, is the meaningful figures; and for that, I hold that images should basically always be described in the visible text anyway, typically as a <figure> with a <figcaption>. And if you have a <figcaption> describing the image sufficiently, I see no cause for any image tag to have anything but empty alt text, because you shouldn’t be writing the same thing again, and there’s no other useful value. Some decry this, and insist figcaption and alt serve different purposes and you should have both, e.g. https://www.scottohara.me/blog/2019/01/21/how-do-you-figure...., part of an article which another decent resource https://webaim.org/techniques/alttext/#figure cites, but I disagree with the argument and its conclusions—especially its “if you empty the alt then the figcaption is not describing anything”, because the figcaption was never describing the image in the first place, but rather the figure, which is still there. Hiding the image in this way because it has been fully described is thus perfectly reasonable.
(Related: avatar images that are paired with the user name in text should have empty alt text. Otherwise you get the name twice in a row. In this case, the image is effectively ornamental, just like icons on buttons that also have labels are ornamental. I receive emails from multiple systems and interact with multiple web apps that commit this sin. It’s annoying, especially when they style things in such a way that the visual presentation of alt text when the image is not loaded is broken anyway.)
So the main case that people might think is left is diagrams where a figcaption would say “the results of such-and-such a benchmark” or similar. But even then the alt text should quite probably be empty: remember also that alt text shouldn’t be too long; the picture may be worth a thousand words, but alt text should not be even a tenth of that length, so you probably shouldn’t list all the values of a bar chart in alt text. Rather, any details that matter, draw attention to them in the caption or the prose surrounding the image! Also most diagrams would be better done as SVG, and if you do that you have much finer control over accessibility presentation than alt text, as well. Though you still have to be careful about pushing too much information to the screen reader.
To be clear, I’m not saying that everyone should take their documents and document.querySelectorAll('img').forEach(e => e.alt = ''), but rather that they should strongly consider designing their documents and massaging their content to the point where that is reasonable, with writing good captions and the likes.