style(accessibility): finish adding alt text (#186)

amyheather · amyheather · commit 6e8b4e399fdd · 2026-02-04T14:20:19.000Z
diff --git a/pages/example_models/example_models.qmd b/pages/example_models/example_models.qmd
@@ -31,7 +31,7 @@ This model simulates a clinic where patients arrive randomly, wait to see a nurs
 
 <br>
 
-![](examples_resources/nurse_des.drawio.png)
+![](examples_resources/nurse_des.drawio.png){fig-alt="DAG for nurse visit simulation"}
 
 #### Model summary
 
@@ -116,7 +116,7 @@ In this book, based on the published description of the model's logic and parame
 
 <br>
 
-![](examples_resources/stroke_rehab_design.png)
+![](examples_resources/stroke_rehab_design.png){fig-alt="DAG for stroke pathway simulation."}
 
 #### Model summary
 
diff --git a/pages/guide/inputs/input_data.qmd b/pages/guide/inputs/input_data.qmd
@@ -29,7 +29,7 @@ When managing input data in your RAP, there are three key files:
 * **Input modelling code:** Code/scripts used to estimate parameters or fit distributions.
 * **Parameters:** Numerical values used by your model (e.g., arrival rates, service times).
 
-![](input_data_resources/input_files.png)
+![](input_data_resources/input_files.png){fig-alt="Illustration of raw data, which is fed to input modelling code, which is the basis of the chosen parameters."}
 
 ## What is included in a RAP?
 
@@ -42,7 +42,7 @@ In other words, a complete RAP covers the journey from version-controlled input
 
 Keep in mind that, especially in sensitive areas like healthcare, you may not be able to share your full RAP outside your team or organisation. Even so, it's crucial to **maintain a complete RAP internally** so your work remains fully reproducible. For example:
 
-![](input_data_resources/input_rap.png)
+![](input_data_resources/input_rap.png){fig-alt="Illustration showing that full internal RAP starts from raw data, but that RAP components shared publicly may start from later point (e.g., parameters)."}
 
 > **Why is this important?** By starting at the source, you make your work transparent and easy to repeat. For instance, if new raw data becomes available, it's important you have your input modelling code so that you can check your distributions are still appropriate, re-estimate your model parameters, and re-run your analysis.
 
@@ -80,7 +80,7 @@ The way you might set up private and public repositories depends on whether you
   2. Copy the resulting real parameter files to the public repository.
   3. Run your model and share code/results publicly - users can fully reproduce your analysis using the real parameters.
 
-![](input_modelling_resources/scenario1.drawio.png)
+![](input_modelling_resources/scenario1.drawio.png){fig-alt="Flow diagram for scenario 1."}
 
 ### Scenario 2: Only sharing fake/synthetic parameters
 
@@ -96,7 +96,7 @@ The way you might set up private and public repositories depends on whether you
   3. Use the shared simulation package in both repositories.
   4. Run and share the full workflow in public with synthetic parameters; run the actual analysis in private with the real parameters.
 
-![](input_modelling_resources/scenario2.drawio.png)
+![](input_modelling_resources/scenario2.drawio.png){fig-alt="Flow diagram for scenario 2."}
 
 :::
 
diff --git a/pages/guide/output_analysis/length_warmup.qmd b/pages/guide/output_analysis/length_warmup.qmd
@@ -82,7 +82,7 @@ Many different methods have been proposed for **determining a suitable length of
 
 We could plot mean results over time, but this would fluctuate too much. Instead, we plot the **cumulative mean** of the performance measures over time. We then look for the point where this **smoothes out and stabilises** - this indicates where your warm-up period should end (@Robinson2007).
 
-![](length_warmup_resources/warmup.png){width=75% fig-align="center"}
+![](length_warmup_resources/warmup.png){width=75% fig-align="center" fig-alt="Illustrative graph of steady-state behaviour."}
 
 When determining your warm-up period, you should:
 
diff --git a/pages/guide/output_analysis/n_reps.qmd b/pages/guide/output_analysis/n_reps.qmd
@@ -91,7 +91,7 @@ Then, run your simulation for an **increasing number of replications**. At first
 
 <br>
 
-![](n_reps_resources/nreps_graph.png){fig-align="center"}
+![](n_reps_resources/nreps_graph.png){fig-align="center" fig-alt="Illustrative graph showing confidence interval becoming stable and narrow."}
 
 When selecting the number of replications you should **repeat the analysis for all performance measures** and select the highest value as your number of replications.
 
diff --git a/pages/guide/output_analysis/parallel.qmd b/pages/guide/output_analysis/parallel.qmd
@@ -87,7 +87,7 @@ Normally, when you run a program, it only uses one core, so only one worker is d
 
 **Parallel processing** means telling the computer to use more than one core at the same time. With more workers sharing the tasks, the work can be done **faster**.
 
-![](parallel_resources/parallel.drawio.png){fig-align="center" width=75%}
+![](parallel_resources/parallel.drawio.png){fig-align="center" width=75% fig-alt="Illustration of sequential v.s. parallel runs."}
 
 ## How to add parallel processing
 
diff --git a/pages/guide/output_analysis/warmup.qmd b/pages/guide/output_analysis/warmup.qmd
@@ -54,7 +54,7 @@ library(simmer)
 
 For systems that naturally begin empty (like a clinic opening each morning), this is fine. However, for many systems that are usually already busy, such as an Accident and Emergency (A&E) department (also known as just an Emergency Department (ED)), starting empty skews the results at the beginning of a run. For example, making waiting times, queue lengths or resource use look lower than they would be in reality.
 
-![](warmup_resources/initialisation_bias.png)
+![](warmup_resources/initialisation_bias.png){fig-alt="Illustration showing an empty hospital simulation model v.s. busy hospital in reality."}
 
 It is important to address this bias as part of your model experimentation validation (see [verification and validation](../verification_validation/verification_validation.qmd#experimentation-validation) page). There are two main strategies for addressing initialisation bias:
 
diff --git a/pages/guide/sharing/archive.qmd b/pages/guide/sharing/archive.qmd
@@ -159,13 +159,13 @@ This tutorial shows how to archive a GitHub repository using Zenodo, chosen for
 
 **1. Login to Zenodo**. Go to <https://zenodo.org/login/>, and login or sign-up to Zenodo with your **GitHub account**.
 
-![](archive_resources/zenodo_login.png){fig-align="center"}
+![](archive_resources/zenodo_login.png){fig-align="center" fig-alt="Screenshot of Zenodo login page."}
 
 <br>
 
 **2. Go to Zenodo GitHub page**. Click on the arrow in the top right corner, and select "GitHub".
 
-![](archive_resources/zenodo_menu.png){fig-align="center"}
+![](archive_resources/zenodo_menu.png){fig-align="center" fig-alt="Screenshot of Zenodo menu."}
 
 <br>
 
@@ -198,13 +198,13 @@ This tutorial shows how to archive a GitHub repository using Zenodo, chosen for
 
 **6. View your Zenodo entry.** Click the repository name in Zenodo to view its releases, metadata, and related issues. If all goes well, you should see a new release and DOI listed - for example:
 
-![](archive_resources/book_zenodo_releases.png){fig-align="center"}
+![](archive_resources/book_zenodo_releases.png){fig-align="center" fig-alt="Screenshot of Zenodo entry linked to GitHub release."}
 
 <br>
 
 Clicking the DOI (for example: [10.5281/zenodo.17094156](https://doi.org/10.5281/zenodo.17094156)) opens the permanent archived version of our repository in Zenodo:
 
-![](archive_resources/book_zenodo_page.png){fig-align="center"}
+![](archive_resources/book_zenodo_page.png){fig-align="center" fig-alt="Screenshot of Zenodo entry."}
 
 ### Zenodo communities
 
@@ -214,19 +214,19 @@ To set-up a community, visit <https://zenodo.org/communities> and select &nbsp;[
 
 Once your community is set up, go to your Zenodo record/s and scroll down to "Communities", then click "+ Submit to community".
 
-![](archive_resources/zenodo_submit_community.png){fig-align="center"}
+![](archive_resources/zenodo_submit_community.png){fig-align="center" fig-alt="Screenshot of Zenodo 'Submit to community' button."}
 
 <br>
 
 Search for your community, give appropriate permissions, and submit.
 
-![](archive_resources/zenodo_submit_community_2.png){fig-align="center"}
+![](archive_resources/zenodo_submit_community_2.png){fig-align="center" fig-alt="Screenshot of Zenodo 'Submit to community' pop-up."}
 
 <br>
 
 From the "Requests" tab of your community dashboard, you can then accept this submission to add it to the community.
 
-![](archive_resources/zenodo_community_requests.png){fig-align="center"}
+![](archive_resources/zenodo_community_requests.png){fig-align="center" fig-alt="Screenshot of Zenodo community requests page."}
 
 ## Explore the example models
 
diff --git a/pages/guide/sharing/changelog.qmd b/pages/guide/sharing/changelog.qmd
@@ -185,19 +185,19 @@ GitHub releases can be used to easily archive work to Zenodo - see the [Sharing
 
 3. In the right sidebar under "Releases", click **Create a new release**
 
-![](changelog_resources/create_release.png)
+![](changelog_resources/create_release.png){fig-alt="Screenshot of GitHub repository with cursor hovering over 'Create a new release'."}
 
 On the new release page, enter a version tag (e.g., `v0.1.0`), copy in your release title and entry from the changelog, then click &nbsp;[Publish release]{style="background: #597341; color: #fff; border-radius:4px; padding:2px 8px; font-family:monospace; font-weight:bold; font-size:90%;"}&nbsp;. For example:
 
-![](changelog_resources/release.png)
+![](changelog_resources/release.png){fig-alt="Screenshot of GitHub new release page."}
 
 ## Using GitHub commits when writing a changelog
 
 When writing a changelog, it is helpful to **look over your GitHub commits** to remember recent changes.
 
 If you have already created some releases, click on your latest release on GitHub and then **X commits to main since this release** to see all recent commits:
 
-![](changelog_resources/changes_since_release.png)
+![](changelog_resources/changes_since_release.png){fig-alt="Screenshot of GitHub release with cursor hovering over 'X commits to main since this release'."}
 
 You should aim to summarise the main updates in a human-readable way. While tiny details/tweaks don't need to be listed, **all notable changes** should be included in the changelog so it can serve as a reliable and comprehensive summary.
 
diff --git a/pages/guide/sharing/citation.qmd b/pages/guide/sharing/citation.qmd
@@ -25,7 +25,7 @@ This page explains why and how to provide citation instructions in your simulati
 
 :::
 
-![](citation_resources/citation.png)
+![](citation_resources/citation.png){fig-alt="Illustration representing citation and ORCID."}
 
 ## Why provide citation information?
 
@@ -69,7 +69,7 @@ A `CITATION.cff` file is a plain text file with a standard structure to share ci
 
 The easiest way to create this file is using the [cffinit](https://citation-file-format.github.io/cff-initializer-javascript/#/) web application. It will guide you through the required information, and generate a `CITATION.cff` file at the end.
 
-![](citation_resources/cffinit.png)
+![](citation_resources/cffinit.png){fig-alt="Screenshot of cffinit."}
 
 As an example, the `CITATION.cff` from the repository for this book:
 
@@ -87,7 +87,7 @@ As an example, the `CITATION.cff` from the repository for this book:
 
 * **GitHub:** Adds a "Cite this repository" button to the sidebar, which provides APA and BibTeX citations (based on the `CITATION.cff` file), and links to the file. For example:
 
-![](citation_resources/cff_github.png)
+![](citation_resources/cff_github.png){fig-alt="Screenshot of GitHub 'Cite this repository'."}
 
 ### `README.md`
 
@@ -219,7 +219,7 @@ The [cffr](https://github.com/ropensci/cffr) package can be handy if you are mai
 
 An ORCID iD (Open Researcher and Contributor ID) is a unique persistent identifier for researchers and contributors. It **distinguishes** you from others with similar names and ensures your work is **correctly attributed** to you, even with name changes, different name formats, or moves between institutions. You can register for an iD at <https://orcid.org/>.
 
-![Example: ORCID profile for Amy Heather](citation_resources/orcid_profile.png)
+![Example: ORCID profile for Amy Heather](citation_resources/orcid_profile.png){fig-alt="Screenshot of example ORCID profile."}
 
 You can then include the ORCID iDs of contributors to your project within your citation files (e.g. `CITATION.cff`) - and within your `README.md`. This ensures all contributors are uniquely and accurately identified, and links to their scholarly profiles.
 
diff --git a/pages/guide/sharing/licence.qmd b/pages/guide/sharing/licence.qmd
@@ -87,7 +87,7 @@ For helping choosing an appropriate licence:
 
 The easiest way to add a license is during GitHub repository set-up. Just use the **Add license** option, and Github will add the right `LICENSE` file for you.
 
-![](licence_resources/github_licence.png)
+![](licence_resources/github_licence.png){fig-alt="Screenshot of GitHub 'Add license' option."}
 
 If you didn't add it then though, it's still very simple to add a license at any time. You just need to copy the license text from sites like <https://choosealicense.com/licenses/> or <https://opensource.org/licenses>, paste it into a new file called `LICENSE`, and commit it to your project.
 
diff --git a/pages/guide/sharing/peer_review.qmd b/pages/guide/sharing/peer_review.qmd
@@ -50,17 +50,17 @@ This is a natural point for peer review, and platforms like GitHub make it easy
 
 It's also a good point to run automated tests with GitHub Actions, checking your code before it's merged (see the [GitHub actions](../style_docs/github_actions.qmd) page for details).
 
-![Screenshot of requesting a reviewer in a GitHub pull request](peer_review_resources/pull_request_reviewer.png)
+![Screenshot of requesting a reviewer in a GitHub pull request](peer_review_resources/pull_request_reviewer.png)\
 
 <br>
 
 You can use pull requests with just main and dev branches, but that approach often means either not reviewing every merge, or letting branches grow large and unwieldy over time.
 
-![](peer_review_resources/git_branch_review.drawio.png){width="80%" fig-align="center"}
+![](peer_review_resources/git_branch_review.drawio.png){width="80%" fig-align="center" fig-alt="Diagram showing review of changes in dev branch before merge into main."}
 
 A more flexible and common setup, inspired by **"Gitflow"**, uses main, dev, and feature branches. Team members work on feature branches that merge into dev, with reviews at merge points, or as changes are merged into main. This keeps branches focused and helps avoid accumulating too many changes in one place.
 
-![](peer_review_resources/git_branch_feature.drawio.png)
+![](peer_review_resources/git_branch_feature.drawio.png){fig-alt="Diagram showing review of changes in feature branch before merge into dev."}
 
 <br>
 
@@ -77,23 +77,23 @@ When reviews are less frequent, more informal methods like GitHub issues can als
 
 To start one, just click &nbsp;[New issue]{style="background: #597341; color: #fff; border-radius:4px; padding:2px 8px; font-family:monospace; font-weight:bold; font-size:90%;"}&nbsp; on the GitHub repository and fill in the details.
 
-![](peer_review_resources/issues.png)
+![](peer_review_resources/issues.png){fig-alt="GitHub screenshot of creating a new issue."}
 
 Issues work well for more occasional reviews, letting you track comments and discussions over time. If review happens elsewhere (like email or in person), **writing a summary in an issue** helps keep a transparent record in one place, making it easy to refer back later.
 
 You can also create **templates** for GitHub issues. A template provides a pre-set structure, making reviews more consistent and easier to follow. You can set them up by going to the repository **⚙ Settings**, then scrolling down to **Features** and selecting &nbsp;[Set up templates]{style="background: #597341; color: #fff; border-radius:4px; padding:2px 8px; font-family:monospace; font-weight:bold; font-size:90%;"}&nbsp;.
 
-![](peer_review_resources/set_up_template.png)
+![](peer_review_resources/set_up_template.png){fig-alt="Screenshot of GitHub settings 'Set up templates'."}
 
 You can then select **Custom template**, then **Preview and edit**, and the pencil symbol ✎ to edit the template. When you're ready, you can propose and commit changes to add the template to the repository.
 
-![](peer_review_resources/review_template.png)
+![](peer_review_resources/review_template.png){fig-alt="Screenshot of GitHub template draft example."}
 
 Now, when reviewers select &nbsp;[New issue]{style="background: #597341; color: #fff; border-radius:4px; padding:2px 8px; font-family:monospace; font-weight:bold; font-size:90%;"}&nbsp;, they are prompted to choose between starting a blank issue or using a template. Selecting the template will open a draft issue with the template questions/structure you created.
 
-![](peer_review_resources/new_issue_options.png)
+![](peer_review_resources/new_issue_options.png){fig-alt="Screenshot of GitHub issues showing new template in list of options."}
 
-![](peer_review_resources/new_issue_edit.png)
+![](peer_review_resources/new_issue_edit.png){fig-alt="Screenshot of GitHub creating an issue using the template."}
 
 <br>
 
@@ -121,7 +121,7 @@ Sub-issues are great for more detailed actions.
 
 You can create sub-issues from existing checklist items, or by scrolling to the bottom of an existing issue and clicking **Create sub-issue**:
 
-![](peer_review_resources/subissue.png)
+![](peer_review_resources/subissue.png){fig-alt="GitHub screenshot of 'Create sub-issue' button."}
 
 The new sub-issue will be nested as part of the larger task.
 
@@ -133,11 +133,11 @@ The new sub-issue will be nested as part of the larger task.
 
 GitHub Projects help organize issues, pull requests, checklists, and sub-issues visually. You can set-up a project using the **Project** tab:
 
-![](peer_review_resources/projects.png)
+![](peer_review_resources/projects.png){fig-alt="Screenshot of GitHub Projects tab."}
 
 GitHub provide several templates for projects. A common example is a board with columns like "To review", "In progress", or "Done".
 
-![](peer_review_resources/project_templates.png)
+![](peer_review_resources/project_templates.png){fig-alt="Screenshot of GitHub project templates page."}
 
 [→ Find out more about GitHub Projects.](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects)
 
diff --git a/pages/guide/style_docs/documentation.qmd b/pages/guide/style_docs/documentation.qmd
@@ -111,11 +111,11 @@ Examples:
 
 You can also add "workflow status" badges which show the status of your [GitHub actions](github_actions.qmd). You can create these by going to your repository actions, choosing a workflow, then selecting the "..." button in the top right and clicking "Create a status badge".
 
-![](documentation_resources/github_actions_badge.png)
+![](documentation_resources/github_actions_badge.png){fig-alt="Screenshot of GitHub actions page, with cursor over 'Create status badge'."}
 
 It will then provide you with the required markdown for your badge.
 
-![](documentation_resources/github_actions_badge2.png)
+![](documentation_resources/github_actions_badge2.png){fig-alt="Screenshot of GitHub providing markdown for status badge."}
 
 <br>
 
@@ -161,9 +161,9 @@ If you are using GitHub, everyone who has made commits will be listed as a contr
 
 You can list contributors manually in Markdown, but a fun way to enhance this is to use [All Contributors](https://allcontributors.org/). This GitHub bot adds a grid of contributors and their roles at the end of your README. For set-up and usage instructions, check out their documentation: <https://allcontributors.org/docs/en/bot/overview>.
 
-Example from [this book's README](https://github.com/pythonhealthdatascience/des_rap_book) (as of October 2025):
+Example from [this book's README](https://github.com/pythonhealthdatascience/des_rap_book) (as of January 2026):
 
-![](documentation_resources/allcontributors.png)
+![](documentation_resources/allcontributors.png){fig-alt="Screenshot of all-contributors table."}
 
 ## CONTRIBUTING guide
 
diff --git a/pages/guide/verification_validation/quality_assurance.qmd b/pages/guide/verification_validation/quality_assurance.qmd
@@ -25,7 +25,7 @@ date: "2025-11-25T14:57:15+00:00"
 
 * **How does QA relate to verification and validation?** Verification and validation are specific checks within QA that focus on whether the analysis has been built correctly and answers the right question; QA is broader and also covers how the work is planned, documented, reviewed, and signed off.
 
-![](quality_assurance_resources/qa.png)
+![](quality_assurance_resources/qa.png){fig-alt="Illustration representing quality assurance."}
 
 In the UK, one of the main sources of guidance on QA is the [AQuA Book](https://www.gov.uk/guidance/the-aqua-book), developed by the Government Analysis Function. This page is based on the guidance in the AQuA Book and introduces some of the QA activities it describes, but you should go to the AQuA Book for the complete guidance.
 
diff --git a/pages/guide/verification_validation/verification_validation.qmd b/pages/guide/verification_validation/verification_validation.qmd
