Update more captions and alt text

docs/run/advanced-runtime-options.mdx

@@ -8,7 +8,7 @@ description: Specify options when building with Qiskit runtime primitives
 
 When calling the primitives, you can pass in options by using the `Options` class or when using the `run` method. In the `Options` class, commonly used options, such as `resilience_level`, are at the first level. Other options are grouped into different categories:
 
-![The image shows the top level options categories: transpilation, resilience, execution, environment, and simulation.](/images/build/options.png)
+![The image shows the top level options categories: transpilation, resilience, execution, environment, and simulation.](/images/build/options.png "Option categories")
 
 <Admonition type="info" title="Attention">
     This section focuses on Qiskit Runtime primitive [Options](../api/qiskit-ibm-runtime/qiskit_ibm_runtime.options.Options) (imported from `qiskit_ibm_runtime`). While most of the `primitives` interface is common across implementations, most `Options` are not. Consult the

docs/run/configure-error-mitigation.mdx

@@ -107,7 +107,7 @@ stage). This approach tends to reduce errors in expectation values, but
 is not guaranteed to produce an unbiased result.
 
 
-![Illustration of the ZNE method](/images/optimize/resiliance-2.png "Illustration of the ZNE method")
+![This image shows a graph.  The x-axis is labeled Noise ampification factor.  The y-axis is labeled Expectation value.  An upward sloping line is labeled Mitigated value.  Points near the line are noise amplified values.  There is a horizontal line just above the X-axis labeled Exact value. ](/images/optimize/resiliance-2.png "Illustration of the ZNE method")
 
 The overhead of this method scales with the number of noise factors. The
 default settings sample the expectation value at three noise factors,
@@ -140,11 +140,11 @@ gates. Then it learns the noise model associated with each unique
 2-qubit gate layer.
 
 <figure>
-<img src="/images/optimize/stratified.png" alt="/images/optimize/stratified.png" />
+<img src="/images/optimize/stratified.png" alt="Stratified circuit illustration. There are arbitrary 1-qubit gates between each `layer`. Each layer is defined by a block that crosses multiple qubit wires." />
 <figcaption>This is an example of a <span
 class="title-ref">stratified</span> circuit, where the layers of
 two-qubit gates are labeled layer 1 through n. Note that each <span
-class="math inline"><em>U</em><sub><em>l</em></sub></span> is composed
+class="math inline"><em>U</em><sub><em>n</em></sub></span> is composed
 of two-qubit gates on the native connectivity graph of the quantum
 processor. The open boxes represent arbitrary single-qubit
 gates.</figcaption>
@@ -195,7 +195,7 @@ to scale the number of samples accordingly. The following plot
 illustrates the relationship between estimator error and number of
 circuit samples for different total sampling overheads.
 
-![](/images/optimize/sampling-overhead.png)
+![This image shows that the error decreases a the number of samples increases.  The accuracy is best with a high sampling overhead (1000) and least with a low samping overhead (1.1).](/images/optimize/sampling-overhead.png)
 
 Note that the number of samples required to deliver a desired accuracy
 is not known before the primitive query because the mitigation scaling
@@ -251,7 +251,7 @@ strings can be much smaller than the dimensionality of the full
 multi-qubit Hilbert space, the resulting linear system of equations is
 nominally much easier to solve.
 
-![Illustration of the M3 method](/images/optimize/m3.png)
+![Illustration of the M3 method](/images/optimize/m3.png "M3 method")
 
 </details>
 

docs/run/fair-share-queue.mdx

@@ -24,15 +24,15 @@ When you submit a job to a quantum system, it enters the scheduler for the speci
 
 A hub’s entitlement determines its proportional share of the IBM Quantum Premium Plan computational capacity. IBM Quantum assigns shares to hubs. Hub administrators then decide what portion of these shares to assign to each of their groups. Similarly, group administrators will decide what portion of shares to assign to each of their projects.
 
-![Administrator user interface.](/images/migration/admin-UI1.png)
+![Screenshot of the Administrator user interface.](/images/migration/admin-UI1.png "Administrator user interface")
 
 Hub administration user interface. This is used to assign shares to groups. The entire hub share pool is distributed to the underlying groups, and the hub administrator can control the percent distribution by specifying a share value for each group. In this example, Group 5 receives 2 shares of their hub share pool, over a total of 5 shares across all groups. That means that Group 5 receives 40% of the shares pool that the hub was granted.
 
 The fair-share algorithm takes into consideration how these shares are distributed across groups and projects to determine job prioritization.
 
-The scheduling algorithm combines a group’s shares with the shares of its hub, to determine the total fraction of computational power allocated to that group.
+The scheduling algorithm combines a group’s shares with the shares of its hub, to determine the total fraction of computational power allocated to that group. For example, assume you have set up the following allocations: 
 
-![Illustration of how allocation is computed.](/images/migration/allocation.png)
+![Two hubs are shown: A, and B.  Hub A has allocated 20% to Group A and 40% to group B.  Hub B has allocated 30% to group C and 10% to group D.](/images/migration/allocation.png "Allocation example")
 
 To compute the 60% for Hub-A, start with the 3 shares of Hub-A and divide between all the shares at the hub level (3 + 2 = 5 shares in total). This results in 3/5 = 0.6 = 60%. When computing the fraction per group, repeat the calculation inside each hub; the fractions for Group-A and Group-B would therefore be 33% and 67%, then apply these percentages to the Hub-A fraction, which results in 20% and 40%.
 
@@ -42,13 +42,13 @@ The fair-share scheduling algorithm select jobs to execute on a quantum system i
 
 In the following example, we have seven instances arranged between two different hubs. As jobs flow through the system, each group and project consumes some fraction of its effective allotted share. The first image below describes the state at time t1. In between brackets we report the consumption as a fraction of the allotted shares. The fair-share algorithm first identifies the group with the smallest number in between brackets, then the project with the least number in the brackets, and finally it selects the oldest job submitted by that project.
 
-![Fair-share queue example.](/images/migration/fairshare3.png)
+![This image shows how a job might flow through the queue. It shows Group A from Hub A being selected because it has (0.0), then Project B, which is part of Group A is selected because it also has (0.0), then the first job for that project is run. ](/images/migration/fairshare3.png "Fair share queue example")
 
 A snapshot view of consumption (in brackets) relative to the assigned shares. This scenario has seven different H/G/Ps arranged into hubs, groups, and projects. The next selected group and or project is the one with the smallest consumed fraction of the assigned shares. In this example, the Hub-A/Group-1/Project-Y is selected, and the oldest job (first submitted) in the project is executed.
 
 When the system is ready for an additional job, it repeats the selection. In the following image we represent the state of the queue at time t2. Notice that Group A and Project B consumption were updated to account for the previous consumption accrued between t1 and t2.
 
-![Fair-share queue example two.](/images/migration/fairshare4.png)
+![This image shows how a job might flow through the queue. It shows Group D from Hub D being selected because it has (0.1), which is now the smallest value for the groups, then Project F, which is part of Group D is selected because it has (0.0), then the first job for that project is run.](/images/migration/fairshare4.png "Fair share queue example 2")
 
 Recomputed fair-share priorities reflecting the previous job execution. A new H/G/P (Hub-B/Group-2/Project-N) is selected based on these updated values.
 

docs/transpile/custom-transpiler-pass.ipynb

@@ -46,7 +46,7 @@
     "  qc.draw(output='mpl', style='iqp')\n",
     "\n",
     "```\n",
-    "![](/images/transpile/custom-transpiler-pass/DAG_circ.png)\n",
+    "![The circuit's DAG consists of nodes that are connected by directional edges. It is a visual way to represent qubits or classical bits, the operations, and the way that data flows. ](/images/transpile/custom-transpiler-pass/DAG_circ.png \"DAG\")\n",
     "\n",
     "Use the `qiskit.tools.visualization.dag_drawer()` function to view this circuit's DAG.  There are three kinds of graph nodes: qubit/clbit nodes (green), operation nodes (blue), and output nodes (red).  Each edge indicates data flow (or dependency) between two nodes.\n",
     "\n",

docs/transpile/transpiler-stages.ipynb

@@ -39,7 +39,7 @@
     "The next stage involves the layout or connectivity of the backend a circuit will be sent to.  In general, quantum circuits are abstract entities whose qubits are \"virtual\" or \"logical\" representations of actual qubits used in computations.  To execute a sequence of gates, a one-to-one mapping from the \"virtual\" qubits to the \"physical\" qubits in an actual quantum device is necesary.  This mapping is stored as a `Layout` object.\n",
     "\n",
     "\n",
-    "![Qubit mapping](/images/transpile/layout-mapping.png)\n",
+    "![This image illustrates qubits being mapped from the wire representation to a diagram that represents how the qubits are connected on the system.](/images/transpile/layout-mapping.png \"Qubit mapping\")\n",
     "\n",
     "The choice of mapping is extremely important for minimizing the number of SWAP operations needed to map the input circuit onto the device topology and ensure the most well-calibrated qubits are used.  Due to the importance of this stage, the preset pass managers try a few different methods to find the best layout.  Typically this involves two steps: first, try to find a \"perfect\" layout (a layout that does not require any SWAP operations), and then, a heuristic pass that tries to find the best layout to use if a perfect layout cannot be found.  There are two `Passes` typically used for this first step:\n",
     "\n",
@@ -63,7 +63,7 @@
     "However, finding the optimal SWAP mapping is hard.  In fact, it is an NP-hard problem, and is thus prohibitively expensive to compute for all but the smallest quantum devices and input circuits.  To work around this, Qiskit uses a stochastic heuristic algorithm called `SabreSwap` to compute a good, but not necessarily optimal, SWAP mapping. The use of a stochastic method means that the circuits generated are not guaranteed to be the same over repeated runs.  Indeed, running the same circuit repeatedly results in a distribution of circuit depths and gate counts at the output.  It is for this reason that many users choose to run the routing function (or the entire `StagedPassManager`) many times and select the lowest-depth circuits from the distribution of outputs.\n",
     "\n",
     "For example, this is a GHZ circuit executed 100 times, using a “bad” (disconnected) `initial_layout`:\n",
-    "![/images/api/transpiler-11.png](/images/transpile/transpiler-11.png)\n"
+    "![This image shows a circuit with 14 qubits.](/images/transpile/transpiler-11.png \"Result from a disconnected initial layout\")\n"
    ]
   },
   {