4 ms·

> Hiding the image in this way because it has been fully described is thus perfectly reasonable. I disagree as a screen reader user. To be clear, I completely

> Hiding the image in this way because it has been fully described is thus perfectly reasonable. 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.

chrismorgan 6y ago
OK, thanks—checking it with real users is the main thing I still wanted to do with this, and I was hoping someone in the know would respond! (I was going to have to find someone to ask if I went ahead with the mentioned article, definitely couldn’t publish without that.) But my problem is this: I see no reasonable value for the alt text; every option available to me is claimed to be wrong for at least one reason: you shouldn’t duplicate the figcaption, and you shouldn’t omit alt, and you shouldn’t have a blank alt, and you shouldn’t just say “photo” or even “the photo described by the caption”, so… what’s left? I can think of no other reasonable alternatives. So blank alt was feeling the least bad to me. 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>?
- jscholes 6y ago
  > 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>? 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.
  - chrismorgan 6y ago
    But I’m going to put that link to the full diagram in the figcaption, because I want it to be there for sighted users also. Now what? 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.
    - jscholes 6y ago
      > But I’m going to put that link to the full diagram in the figcaption, because I want it to be there for sighted users also. Now what? 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.
- PeterisP 6y ago
  I'd argue that the figcaption can't contain an adequate description in pretty much every case. "Figure 3: results of Benchmark Q, showing X to be 40% faster than Y." is appropriate only for the minimalistic bar chart with only two bars, and already there it's pushing the limits - it would often be appropriate to just say "Figure 3: speed of X and Y in benchmark Q" as the interpretation and conclusions from the two bars is a separate, different thing which could be in the text. Perhaps to the reader it's not relevant that X is 40% faster than Y, but rather that X can do the thing in 5.6 seconds - which is clear from the bar chart, but not from that proposed figcaption. 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.
  - chrismorgan 6y ago
    This style of caption I’m describing is regularly only very broadly describing the figure and picking what the author thinks is the most relevant detail. It’s typically not describing everything—nor would alt text, because that’s too long for alt text, which needs to be fairly short.
  - jscholes 6y ago
    > I'd argue that the figcaption can't contain an adequate description in pretty much every case. 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.

chrismorgan 6y ago

OK, thanks—checking it with real users is the main thing I still wanted to do with this, and I was hoping someone in the know would respond! (I was going to have to find someone to ask if I went ahead with the mentioned article, definitely couldn’t publish without that.) But my problem is this: I see no reasonable value for the alt text; every option available to me is claimed to be wrong for at least one reason: you shouldn’t duplicate the figcaption, and you shouldn’t omit alt, and you shouldn’t have a blank alt, and you shouldn’t just say “photo” or even “the photo described by the caption”, so… what’s left? I can think of no other reasonable alternatives. So blank alt was feeling the least bad to me. 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>?

jscholes 6y ago
> 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>? 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.
- chrismorgan 6y ago
  But I’m going to put that link to the full diagram in the figcaption, because I want it to be there for sighted users also. Now what? 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.
  - jscholes 6y ago
    > But I’m going to put that link to the full diagram in the figcaption, because I want it to be there for sighted users also. Now what? 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.
PeterisP 6y ago
I'd argue that the figcaption can't contain an adequate description in pretty much every case. "Figure 3: results of Benchmark Q, showing X to be 40% faster than Y." is appropriate only for the minimalistic bar chart with only two bars, and already there it's pushing the limits - it would often be appropriate to just say "Figure 3: speed of X and Y in benchmark Q" as the interpretation and conclusions from the two bars is a separate, different thing which could be in the text. Perhaps to the reader it's not relevant that X is 40% faster than Y, but rather that X can do the thing in 5.6 seconds - which is clear from the bar chart, but not from that proposed figcaption. 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.
- chrismorgan 6y ago
  This style of caption I’m describing is regularly only very broadly describing the figure and picking what the author thinks is the most relevant detail. It’s typically not describing everything—nor would alt text, because that’s too long for alt text, which needs to be fairly short.
- jscholes 6y ago
  > I'd argue that the figcaption can't contain an adequate description in pretty much every case. 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.