Screen readers use an image's alt text (the alt attribute of an <img>) for the text equivalent of the image. Specifying the alt text in RST is done via :alt: on an .. image:: directive, like we do here: https://github.com/NREL/rdtools/blame/a5eeffbe719cab808b85e360c8d4eaa6322e3cea/docs/sphinx/source/index.rst#L48-L49

However, our current descriptions are very basic (e.g. RdTools workflow diagram). Penn State suggests "a good rule of thumb to consider is to include what you might relay over the phone". So the first point of this issue is to consider beefing up our current set of :alt: descriptions.

Additionally, the images in our example pages don't come from an .. image:: RST directive but instead from an image embedded in a jupyter notebook. I've looked into this and as far as I can tell there is currently no way to specify alt text in the notebook and have it end up as the alt image attribute in the built HTML, at least with our current strategy using nbsphinx. See spatialaudio/nbsphinx#241. I believe it would be possible to get this working with two changes:

1. A small modification to nbsphinx so that alt is a recognized metadata entry like height and width. I think this part is straightforward, but would require a PR to (and new release of) nbsphinx.
2. Some way of specifying the alt text in the notebook cells. There are a few possibilities here:
   a. Using Ipython.display.display instead of plt.show(), e.g.:

   display(fig, metadata={"image/png": {"alt": "this is my alt text"}})

   This is straightforward, but maybe adds a bit of clutter to the notebooks. It also needs a tweak so that figures don't get displayed twice (once from creating the figure, once from calling display() on it).
   b. Using custom markup and an nbformat PreProcessor. For example we could write our plotting cells like this:

   ...
   plt.show()  # this is my alt text

   and have a notebook preprocessor that extracts the comment text and inserts it into the cell metadata the same way the ipython display function does. I think the best way to integrate such a preprocessor with the docs build would be to house it in a custom sphinx extension. So this is certainly more complex than option a, but would keep the notebooks looking normal.