Default alt text for figures

[hturner]

This is an issue raised by @ajrgodfrey after reading R Journal articles using the new R markdown template:

Figures generated by R markdown chunks that have a fig.cap but no fig.alt have the same text used for both the alt text and the caption, meaning that people using screen readers hear the same information multiple times (number of graphics in the figure plus one if they navigate through each figure once then look at the caption).

Example: Figure 1 in https://journal.r-project.org/articles/RJ-2023-001/.

It would be great if the default value for fig.alt could be changed to "graphic without alt text" so that screen reader users hear this brief message for each graphic in the figure before reading the caption.

Reproducible example (showing that current default can not only be repetitive but misleading)

reprex.Rmd

---
output: 
  html_document:
    self_contained: false
---

```{r pressure, fig.cap="Two plots using mtcars",  fig.show="hold", out.width="50%"}
par(mar = c(4, 4, .1, .1))
plot(cars)
plot(mpg ~ hp, data = mtcars, pch = 19)

`reprex.html` (shortened)

Two plots using mtcars

Session info:

xfun::session_info("knitr") R version 4.3.1 (2023-06-16) Platform: aarch64-apple-darwin20 (64-bit) Running under: macOS Ventura 13.5, RStudio 2023.6.0.421

Locale: en_US.UTF-8 / en_US.UTF-8 / en_US.UTF-8 / C / en_US.UTF-8 / en_US.UTF-8

time zone: Europe/London tzcode source: internal

Package version: evaluate_0.21 graphics_4.3.1 grDevices_4.3.1 highr_0.10 knitr_1.43.17
methods_4.3.1 stats_4.3.1 tools_4.3.1 utils_4.3.1 xfun_0.40
yaml_2.3.7

<!--
Please keep the below portion in your issue. Your issue will be closed if any of the boxes is not checked (i.e., replace `[ ]` by `[x]`). In certain (rare) cases, you may be exempted if you give a brief explanation (e.g., you are only making a suggestion for improvement). Thanks!
-->

---

By filing an issue to this repo, I promise that

- [x] I have fully read the issue guide at https://yihui.org/issue/.
- [x] I have provided the necessary information about my issue.
    - If I'm asking a question, I have already asked it on Stack Overflow or RStudio Community, waited for at least 24 hours, and included a link to my question there.
    - If I'm filing a bug report, I have included a minimal, self-contained, and reproducible example, and have also included `xfun::session_info('knitr')`. I have upgraded all my packages to their latest versions (e.g., R, RStudio, and R packages), and also tried the development version: `remotes::install_github('yihui/knitr')`.
    - If I have posted the same issue elsewhere, I have also mentioned it in this issue.
- [x] I have learned the Github Markdown syntax, and formatted my issue correctly.

I understand that my issue may be closed if I don't fulfill my promises.

[yihui]

Good idea. I'll make this change. Thanks!

[jooyoungseo]

I respectfully disagree on this point, both as a user of screen readers and as someone who frequently works with R Markdown and Quarto. In the absence of alternative text, having the figure caption serve as a fallback is a more reliable option, in my view. While repetitive information between alt text and figure captions isn't ideal, it's not detrimental, especially in STEM content where figures play an indispensable role. As I skim through articles, I utilize my screen reader's single-letter "G" navigation feature to swiftly jump to subsequent graphical elements. At that moment, the alt text is read aloud to me. Encountering a graphic labeled as "without alt text" during this quick navigation process would be far more disruptive than hearing repeated information.

[yihui]

Encountering a graphic labeled as "without alt text" during this quick navigation process would be far more disruptive than hearing repeated information.

Okay, that argument sounds more compelling to me, so I'll probably not make this change... Thanks for your input!

[ajrgodfrey]

In general this is right. I stand by the very first time I said to use fig.cap as the alt text. Back then, the world didn't have a great attitude to adding alt text; things have changed a lot, but we still do not have the ideal happening all the time. I welcomed the arrival of fig.alt especially because it didn't come from me, but it is not always done well even when it is done at all.

My initial comment that started this relates to legacy content being converted to HTML. There can be multiple images imported into one LaTeX figure float. Some of the captions were also extremely verbose. In that context, having a short effective note is effective. JYS and I may well have to get used to using more than on key to jump around an article. (g then down arrow in a 1-2 step)

There were also images that do not have an immediately obvious fig.cap to call on. A consistent style for a page/site is also crucial.

My conclusion: knitr should stick with fig.alt=fig.cap and specific situations should formulate their own plans. In my own work, I set fig.alt ="to fix" so that I can catch the things that need fixing. I must override the default and do so willingly.

[yihui]

In my own work, I set fig.alt ="to fix" so that I can catch the things that need fixing. I must override the default and do so willingly.

@ajrgodfrey It can be much easier to override the default in your .Rprofile with options(knitr.chunk.fig.alt = "to fix"). This will apply to any document you knit, and you don't need to call knitr::opts_chunk$set(fig.alt = "to fix") in individual documents.

[ajrgodfrey]

Yes. I tend to do this per folder not per machine though

[hturner]

Thanks everyone for the discussion. It seems I was over zealous in adding this as an issue for knitr as @jooyoungseo and @ajrgodfrey are happy with the current default in general. So I will close the issue here and open the issue elsewhere for us to follow up in the specific context of The R Journal.

Good to know about the knitr.chunk.fig.alt option as that may be useful for changing the default in this context.

[github-actions[bot]]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary.