So with this approach you can’t use an image directly, because then that will cause Scrivener to create the full HTML itself, instead of how we’re doing it here, creating the HTML ourselves (with styles), so that we can insert the text we want into the right places.
The examples where I show an image in the editor are either in an inline annotation (so it stripped out), or inside the text area of the section that is using a Type that will not export the text area at all. In both cases this is meant to demonstrate how we can show the image for our reference, in writing around it, but not use it.
As for us adding an alt field to the software, while that in and of itself wouldn’t be difficult, it’s the conversion that would require a different approach to how we are making ebooks (at least on Mac). Your work is converted to Markdown, and we use the MultiMarkdown engine in Scrivener to generate the HTML from that. So we don’t actually have direct control over how the image HTML is created. It would be a little easier on Windows. Overall though, I do certainly agree it would be a nice improvement to the software—but given how it would take a bit of a change in thinking, it might be better to think of for a future major upgrade.
Those who do wish to use Markdown to generate ebooks, rather than rich text conventions, could use Pandoc, which Scrivener has integration with and even has extensive front end for, in the compiler. Pandoc has a way of supplying alt text, like so:
{alt="Alt text goes here"}
So in a way it’s not too different than one of the examples I gave, but of course this method depends upon using a different ePub generator, with its own way of doing things. One is required to know CSS well enough to design a book with it, rather than use a GUI to generate that CSS for them.